How is your tag group configured? I have my 1-sec direct group as just subscribed with read after write and optimistic writes turned off (this is what my commands typically run under). Longer groups like my 5-sec group has read after write turned off, but optimistic writes turned on with a 7 second timeout.
This is a race condition that can happen if you use the "Read After Write" option in tag groups with an OPC UA subscription. Not sure about other causes.
1 Like
Maybe it's just me, but this seems like a bug. Regardless of how the tag was read (whether it's read-after-write or a poll), if the value changes it should always send a data change of the tag. In step 1 the Ignition tag is true, and in step 2, something is setting it false in the PLC supposedly, so on the next poll at step 3, if the value is now false, but it was true in step 2 even though that wasn't a polling event, the tag still was verified to have changed.
Edit: Or is this due to something related to the difference between the OPC server doing the polling and the OPC client only being subscribed to tag events on a specific periodic basis?
I explain a little further in that thread why it’s not a bug despite being pretty undesirable. No compliant OPC UA server can behave the way you want because it leads to a spurious value being sampled/reported.
1 Like
I'll have to read. I just edited my post, but I'm guessing that's along the track of what's going on.
Slightly off course, but I've also had issues with scada set/plc reset also in the past where bool tag writes from scada either haven't been written into the audit log, or its tag value change events haven't fired (I don't recall which one) and I ended up turning on "Optimistic Writes" to fix it so that the tag. Can someone explain why that would happen?
Also fwiw we did eventually implement this:
in Ignition 8.1.10.
If you really must use the "set from Ignition/reset in PLC" model, use system.opc.writeValue() instead of system.tag.write*().
1 Like
So to clarify, the read after write and optimistic writes are client side settings.
Read after write does an explicit client OPC read after it does the write, but since it's independent of the subscription, if the value is reset back to the previous value before the next scheduled poll, the OPC server doesn't send an event for the tag because from its perspective it never changed.
Optimistic writes "assume" the value was written, so the client holds the written value as the current, but if the timeout is reached without a new tag value from the server, it reverts back to the previous value to match the last known value received from the server during a regular poll. (Which is why the HMI set, PLC reset works fine because even if it happens quickly, after the timeout it gets the correct value that matches the PLC)
Edit: The manual does a good job of describing this.
+1 for this method. IMHO, this makes for the most straightforward logic for anybody that follows.
As a side note - many of A-B Logix built-in instructions (PIDE, etc.) expect to operate in a similar fashion (any OperXxxxReq is configured to auto-reset after processed). For anyone using those, adding any additional logic to change the functionality of those instructions feels like an unnecessary workaround.
For tags which are configured using a request-response device driver, I prefer to set all of my commands/setpoints (R/W device tags) to a separate tag group with Data Mode=Polled. As a starting point, I typically have these set to a Mode=Leased tag group (Rate=30,000, Leased/Driven=2000), Read After Write=True, also Optimistic Writes=True. As another aside - my leased tags are almost always accessible only from a popup.