Modbus devices showing "Connecting", Disconnected

Ignition
,
1

Device connected through modbus TCP/IP and actually connection lost between GW and device either due to communication issue between GW and device or device power off .

Problem is the tag showing the last value with quality Bad("Bad_NotConnected: The variable should receive its value from another variable.")

my problems , i have scripts and different expressions based on these tags values which in this case wrong value. I knew I could consider the tagQulaity in my script ,,

Why value stack at last value ? Any guidance .

2

What would you have it be? It is properly signalling the bad quality, and showing the last known value. Seems perfectly reasonable to me. (Expressions can check quality, too, not just scripts.)

3

it should show null as value, but last read value is bad indication if connection lost . i thought i missed something or settings in modbus configuration.

Conclusion is to consider tagQuality in all my expression and scripts not depend on tagValue Only .

4

Yes, this is actually the correct behavior for an OPC value that is accompanied by a Bad qualified, as opposed to Uncertain. Unfortunately there is an inconsistent application of this among our drivers, especially the older ones.

5

Is there any plan to be adjusted with modbus . for example now Pump showing in run status in UI while connection lost due to RunStatus value showing the last value (1)

6

Perhaps in Ignition 8.3 when such a change in behavior can be justified.

7

We have to review all project again due to this behavior .. A lot of work now

8

It didn't change, did you not notice this behavior the first time?

9

i didn't notice this before as the communication was stable .. This problem appeared this week with an issue in communication .

10

Understood. Sorry for the trouble, but this behavior is not going to change in an 8.1 point release.

If and when it does change I am certain it's going to result in a deluge of support calls. It just can't be done mid-series 8.1.

11

Note to future self: although there is an inconsistent handling in some of the drivers, the Modbus driver actually does send null value with bad quality in this case. It's the interaction between OPC UA client and tag system that is preserving the value by calling OpcSubscriptionNode::setQuality when a null value + bad quality is received from an OPC server. It seems that applying the bad quality while preserving the last tag value is intentional behavior.