OPC subscribed tag didn't get latest value

Ignition
1

We just had an issue where Ignition didn’t show the current value of an OPC tag.

When looking in the tag browser in the designer, the string was empty. But when using the OPCUA Quick Client, we could read the string, and it contained a message.

We use this string for messaging. When the PLC has a message, it puts the message in that address. Then there’s a trigger on tag change, so Ignition can execute the message from the PLC. When done, we empty that message string from Ignition’s side as an acknowledgement, so the PLC knows it’s safe to write a new message.

In this case, the trigger wasn’t received (the string in Ignition was still empty), while the PLC was waiting for the acknowledgement. So the production eventually halted on the lack of messages (which is why we noticed it). But AFAICS, it can just as well happen on any other tag. It would just be less noticeable, as the production won’t halt on a wrong visualisation.

Here are the scan class settings we use for the messaging tags. I see anything wrong with it. The OPC connection settings are all on the default.

image.png1226×630 21.7 KB

Would there be something we can fix to avoid this in the future?
This installation is using version 7.9.4, and is running for almost a year by now.

2

Don't write from both directions. That creates rare but unfixable opportunities for data races. Have PLC write messages to one place, have Ignition write processed messages to another tag. PLC checks for equality to note success. Ignition checks for difference to act on new messages.

If messages can be identical back-to-back, use an odometer as the trigger instead, and have Ignition write the odometer to a separate PLC tag as the acknowledgement.

3

I though we were safe because only one of the two can write at a given time. When the message is empty, the PLC can write, when the message is not empty, the gateway can write.

But I guess in a rare case, the generic subscription execution can overtake the read message (coming from the Read after write) setting.

At this point, we’ll probably not get notified about the change, so the message queue keeps hanging.