Siemens OPC UA Stange Behavior

Ignition
1

Hi,

We are using the Onboard OPC UA on a 1500 CPU.
To avoid the limit of it we read data in struct and use derived tags to split that data.
We see a behavior that sometime data are override to a previous state.
Have the following questions:

  1. When we write to one of those derived tag the value update into the json struct of the source tag. But is it the full struct writed to the OPC UA server or just the updated value?

  2. If we set a bit to stop a sequence (boolean tag), the state of the sequence (Integer) change into the plc to another value. If the execute another action (For example set the restart bit of the sequence) before the state value has been updated in the source tag. Could it be that the second action will reset the state value at the OPC UA by the value still in the source tag json struct ?

For information:
i'm using version 8.1.30 on a linux gateway.

The tag group of the source tag is set to 200ms, Subscribed,Read After Write=False,Optimistic Writes = False.

@Kevin.Herron have you maybe an idea or ear about that behavior?

Thanks in advance for the feedback
Arnaud

2

You must set Optimistic Writes to true if you will write to derived tags of structured data.

3

This on the tag group of the source tag ?
Does the tag group on the derived tag have any impact since the only com point with the plc is the source tag?

4

I think source and derived should be in the same group with Optimistic Writes enabled.

Maybe just source though… would need to test.

5

This didn't solved it.

We didn't see any difference when the derived tags was in the same tag group or not of the source tag

We've just split our command and status into two source tag and this seems to solve the problem. But remain very strange.

6

Hmm, the problem you are describing is exactly what Optimistic Writes is meant to solve.

When you write any member of the structure the entire structure must be written to the server.

Normally, we don't update the value of an OPC tag in Ignition until we've received explicit notification from the server that a value has changed.

This is a problem when you need to write to multiple members of a structure, though, because every subsequent write needs to see the previous write "merged in" to the structure value, immediately. So the "optimistic" part is that we immediately apply the change to the OPC tag's value on the Ignition side, and then roll it back if it ends up failing or a value update never arrives in time.

However, if you're also changing the value of one or more members of this structure at the same time on the PLC side, you are subject to an unsolvable race condition. In this case a piece of more general advice applies, which is that it's critical to avoid writing to the same tag or data point from multiple systems. A lot of people make this mistake oversimplifying a handshake, but the way OPC UA structures work, where the entire structure must be written, even two separate members of a struct end up being the "same" tag.

1 Like