iX Talk

I´ve been using the T10A a lot against Siemens S7 and Crevis Modbus I/O and I haven’t noticed any delay when I use dynamic colors.

How do you see that you are receiving the bit?

Any communication errors popping up?

There maybe a delay between when your controller sets a bit, and when the HMI receives the updated bit value. You can set the poll rate to whatever you want. That will specify how often the HMI should query controller values.

Also, if the unit is busy doing other things you may see a delay. There is a CPU utilization system tag that you can use to check to see if the unit is busy doing other things.

Hello,

mark.monroe
As suggested, I have added a CPU utilization system tag to verify CPU usage which is (40-60% not very high). I have also verified the poll rate which was set to 100ms. I have tried changing it to 500ms (maybe 100ms was too demanding), but the delay is the same.

Edmund
How do you see that you are receiving the bit?
I am simultaneously watching the tag triggering the color change from the PLC and the HMI (I've added a value box to see the actual boolean value) I do notice that 4 to 5 seconds after the PLC tag changes values, the HMI receives the data and changes the color. Any other action requested by the HMI to the PLC is instant, on the other hand, the feedback seems to be the problem. The PLC's watchdog is set to 500ms and the normal cycle run is not exeeding 13.5ms.

Any communication errors popping up?
No

Do you have any idea what could be causing this delay ?

Thank you

Which controller are you using? For example, the Modbus Slave controller waits for the PLC to send data to the HMI. While the Modbus Master controller polls the PLC for data.

Hello

I have a Project where i use 1 display and 7 PLC's over Ethernet, using Mod-bus Master. There is almost no delay.
I have about 1800 tags, and using a lot of dynamic color effects and object moves.

I think the problem is with the controller communication.

The controller is Allan & Bradley - CompactLogix L33ER v20.

The protocol selected in the ix Developer is Ethernet ControlLogix with Allan & Bradley.

My project size is 44.4/80mB, using 30% average RAM and 957 tags.

I have tried removing all scripts and pictures to improve feedback speed without success.

Creating a brand new project seems to fix the issue (Project containing: only 1 screen, 2 boutons and 1 color change object). Unfortunately, I have not found what is exactly causing the ''slow feedback'' when my project isn't blank.

What is the poll rate on your tags? Do you have "Always Active" selected on a large number of the tags? If you set the poll rate to something very slow, like 2000 does it fix the issue?

Hello,

I have found what is causing the delay: The Alarm Server.

The number of AlarmItems in the Alarm Server Function is directly affecting the HMI delay.

After removing all Alarm Server ''AlarmItems'' my delay was gone. The HMI refresh was now Instant. Unfortunately, as I was adding back AlarmItems, my delay started ramping up.

I previously had 512 AlarmItems which was giving me a delay of 4-5 seconds on the HMI. Dropping down to 125 AlarmItems gave me a delay of 0.5-1 second.

All my AlarmItems are set as the following:
Condition (EqualTo)
Trigger value (1)
History (unchecked)
Acknowledge Required (Checked)
Remote Acknowledge (Empty)
Remote Ack Expression (Empty)
Repeat Count (Empty)
Action (Empty)

I have also put all Alarm tags in a unique pollgroup (2000ms) and all my other tags are polled at (200ms). This combination was optimizing the HMI delay (less than 2000ms on Alarm tags was increasing the HMI delay)
*Note no tags are set to ''Always Active'' (Total number of tags: 976)

The problem is: I will eventually have to increase the number of AlarmItems to 512 or more. Therefore, how can I prevent the HMI delay from jumping back to 4-5 seconds ?

Thank you for your support,

The below message I received from one of our developers.

---------------------------------------------------------------------
This is most likely due to the number of tags/requests that are needed in order to update all tags. The driver can only request a certain number of registers/bits in each request (the number of registers/bits are driver dependent, details can be found in the respective driver help). In order to improve the performance the customer will need to try minimize the number of requests and place less critical tags in another poll group (with higher poll rate).

This means:
- Use consecutive addresses
- Use bit-addressed words
- Use as few strings as possible (each string will always generate a separate read request)
-------------------------------------------------------------------------