Ah-ha, I found my original post where I described the race condition, and in that version it was explicitly about read-after-write:
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 clientThe tag is now false in the PLC but true in Ignition.
from Indirect Tag Delay - #9 by Kevin.Herron
I somehow telephoned my own race condition description into something inaccurate since then.