iX Talk

I have noticed sometimes on my T7A panel that some tags don't always update to match the new value of a PLC variable when the variable changes value. I tested to see if navigating away from the screen and then back would force the update, but this didn't work. I don't want to set all the tags to "always-active" since most of them are only visible on a few screens. Is this a bug or is there another way to get the panel to update the tag?


I have found I can easily replicate this rare issue by creating a dummy variable on my PLC (GE PACSystems RX3i), setting the PLC to a constant sweep time of 40ms, then adding a single line of ladder logic to continuously set this dummy variable to zero. On the T7A, I have a screen which displays the value of this variable (which correctly displays zero when the panel is first powered). Then, on a third device, I send the value 10 to the dummy variable a few times until it is seen by the T7A. At this point in time, the T7A continues to say the variable has the value 10 even though its value has returned to 0.

Hi Adam,

In your test setup, does setting the tag to "Always Active" fix your issue? Tags are only polled when they are on the screen. If they are not on the screen, then generally iX will not poll the PLC to see if a new value is in the register. I am wondering if the issue is that iX is not polling, or that iX is polling and the value is not being updated like it should be.

If setting always active does fix the issue, then you need to find a way to trigger iX so that it polls the tags. Besides setting a tag to always active, you can force a tag to read data from the PLC by calling its Read() method like this:

Hi Mark,

No, the issue still exists even when setting the tag to "Always Active". I also tried calling the Read() method every second and that didn't fix the issue either.

The developers have tested your application and it works OK when communicating with a GE Fanuc 90-30 (with CMM321 Ethernet module). We don't have access to the CPU you are using so we can not verify that the driver works OK communicating using that CPU.

The developers suggested that one reason your application might not be working is that %R1 is typically a 16-bit device (it's configured as a float in the HMI application (which means it will read/write %R1+%R2)).

Could you be using a 16-bit device in your PLC code and trying to read it as float in the HMI?

Hi Mark,

The PLC is correctly writing to the %R1 (and thus %R2) register(s) as a 32-bit float.

Hi Adam,

Have you ever used wireshark? Captuing the Ethernet packets that are being sent between the HMI and the PLC would help us figure out what the HMI is doing.

If you could sniff the packets starting at the beginning of your test through a few iterations of when the HMI is not updating the values, we could compare the packets. This one is a hard one for us to debug unless we can recreate your problem.

Hi Mark,

I placed a HUB between the PLC and HMI to try and capture the fault. Strangely enough, I can't get the HMI to "freeze" with the hub in place. The only reason I can think of for the change is the switch normally between the HMI and PLC is full duplex while the hub is only half duplex, thus slower.

My assumption is that the HMI is still reading the value since:
1) I can move its "freeze" point by changing the dummy value I'm sending
2) If I change the reset value to any number other than zero, the HMI no longer "freezes".
my thought is that there is some switch in the HMI that rarely gets stuck and won't let the value go to zero.

Thank you.

Hi Adam,

There should be no switches like that on the tags. When you do a .Read() on a tag value it should read the tag value. There would be no reason to treat 0 different from other values.

Could you try a different switch? I know that sometimes people have trouble communicating with the HMI because the switch will not transfer some of the Ethernet packets we use to/from the controller. We use UDP a lot in the different protocols for example, and some switches do not like that packet type because of security concerns. The switch may be dropping that packet for some reason.

Hi Adam,

Did you get a chance to try a different switch yet? If we can isolate the problem, we might be able to fix it is software. Maybe the switch is blocking certain kinds of packets.

We have been using a 3COM 100 Mbit switch and can not reproduce your problem.

Thanks,

Hi Mark,

I did try another switch and once again couldn't reproduce the glitch. Strangely enough, I decided to retry the original switch and, magically, the glitch is no longer occurring. I have no idea what was causing the problem in the first place, but it somehow fixed itself ??? (which worries me). I'm thinking it may have been some sort of hardware issue (like a loose pin) that corrected itself when things were reconnected and moved around.

Thank you,