Author Topic: Delays between Touch Screen HMI and PLC  (Read 13361 times)

Ben_Whitworth

  • Guest
Delays between Touch Screen HMI and PLC
« on: September 29, 2003, 07:16:42 AM »
We are using a Matsushita/Nais GT01 HMI with an MD 888+.  It communicates via Modbus RTU.  They work well together part of the time, then the HMI develops a large lag and has been kbown to throw up an error sayong that is has lost communications.  They are connecting through COM1 which has no other devices on it.  Can you suggest any reasons why the HMI seems to lag behind the PLC and pause??  Is the protocol scanning to vblame?

Yours

Ben Whitworth
« Last Edit: December 31, 1969, 04:00:00 PM by 1076562000 »

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re: Delays between Touch Screen HMI and PLC
« Reply #1 on: September 29, 2003, 10:33:09 PM »
There can be many possible reasons that lead to communication error.  First of all, make sure that nothing in your program code is writing to the COMM1 port (using statement such as PRINT, OUTCOMM, NETCMD$, READMODBUS or WRITEMODBUS, etc).

Are you using a lot of interrupt based functions in the PLC such as Stepper motor or  high speed counters. When generating high stepping rate or receiving high frequency signal the CPU spend most of its time servicing such task and less time in servicing the RTU. The RTU master may consider that the comm has failed if it did not receive a response within a short period of time. Try to change the timeout value in the HMI if possible. Also try to add time delay between each communication message exchange between the HMI and the PLC.  Also if there is a COMM error, set the HMI to automatically back off for a while before attempting  to communicate again.  Usually the HMI can recover from an occasional COMM error without breaking up with a COMM error message.

You may also want to use the SETPROTOCOL command to set the COMM1 to permanent RTU protocol so that it always respond to MODBUS RTU only.  This may help. However, note that if you use the SETPROTOCOL command then the COMM1 port will not respond to TLServer and you will not be able to use it for programming or on-line monitoring anymore. It will be good to use a special input to SETPROTOCOL the COMM1 back to native mode in order to do programming.
« Last Edit: December 31, 1969, 04:00:00 PM by 1076562000 »
Email: support@triplc.com
Tel: 1-877-TRI-PLCS