If Ignition isn’t the only thing that will write to a given tag then I’d recommend not using the “Read after write” setting because there’s a somewhat dangerous race condition and it’s more likely to occur when using slow scan classes / subscriptions.
Imagine, if you will, a boolean tag in a 30 second scan class.
- driver polls value=
false, next poll in 30s - user writes value=
trueto tag, read-after-write confirms value=true, ignition tag now set to true - some seconds later, before the next poll, an external source (script, PLC logic, whatever) sets the value to
falseagain - driver eventually polls again, reads value=
false, no change since last poll, so no data change is sent to client
The tag is now false in the PLC but true in Ignition.
You can work around this by using OPC Read Mode instead of Subscribe Mode or by ensuring that multiple systems will not write to that tag. Or just simply not using Read-after-write.
Some time in the future we will introduce additional OPC UA settings Tag Groups to allow you to switch the subscription’s data change trigger from Status/Value to Status/Value/Timestamp, which would also alleviate the issue, at the cost of increased traffic and performance overhead between UA client and server.