Ad 2) I am not sure if I understand the question, but I will try nevertheless. The first subscription arrives when the setter of the Initialize property is called. If you call that setter yourself from the application, you need to "get around" the mapped setter, e.g. by calling SetProperty(ref initialize, ...) directly, or by other means. If you map the same property for Read and for Subscription, and you wanted to distinguish those, then you need to split them: Map the same OPC node twice, to different C# members, once for Read and once for Subscription.

Ad 3) It is possible to map to timestamps etc. separately, but you are right, in this case it would make it fairly difficult to combine the pieces back together. It would therefore be better to map the whole AttributeData.

If you can guarantee precise-enough synchronization of the times used by the client and by the server (comes for free if they are on the same machine), then you can simply note the time when you have issued a Write, and discard any incoming values (from Subscription or Read) that have their timestamp earlier than the time of the Write. Note: OPC UA itself demands certain level of time synchronization (required e.g. for security reasons), but that may not be good enough.

Regards

What is happening is that the writing is independent of the subscription. You have, more or less, identified the issue in your email already. It can therefore happen that while the server is preparing values for the subscription reply (PublishResponse), or while this message is in transit or being processed on the client side, the Write occurs that sets a different value - but the client receives the old value after the Write. In the particular trace I have analyzed, the PublishResponse has actually been sent by the server shortly before the Write, but it could also be a bit later in other situations - the principle remains the same. This is not a "misbehavior" of a server or a client - that's how it is designed.

There is no specific "Subscribe with Read" - but in fact, the Subscribe tells the server to always sent the initial data, which is thus equivalent to Read; the problem is only that you do not how much time it'll take the server to send this data.

There may be more possibilities to solve the issue, and frankly, I have not tried them out or analyzed in details. They are e.g.:

1. The artificial delay after Subscribe. Not sure about the right value either.
2. Introduce a "wait", until the first subscribe arrives (that is, have a delay, but the delay would be only as long as needed).
3. Use the timestamps on the incoming values to determine the age of the value and whether or how it should be interpreted (or discarded).
4. Introduce a "high-level protocol" which would not have this kind of timing glitch; probably involving more than one tag for a "handshaking". Requires a change on the OPC server/device side, though.

Of course, all of this complicates the otherwise "nice and clean" code - but there probably isn't a way to do it otherwise.

Best regards

Dear Sir,
thank you for the files.

Unfortunately, you have not followed the instructions (kb.opclabs.com/Collecting_information_for_troubleshooting ), and therefore I cannot do meaningful analysis; assets missing are:

2. Extended tracing output (for OPC UA only).
3. EasyUAClient.LogEntry records (for OPC UA only).
4. A log of relevant occurrences in your own application.
5. OPC server log(s), if available.

All of them are important, but I am specifically missing #4: You should provide an information (with timestamps) about when your properties were set from the Live Mapping and to what values, and which Live Mapping operations (Read, Write, Subscribe( you have called and when.

Other observations and questions:
A. Have the properties been actually improperly set (with version 2017.1 = 5.50) when you took this particular trace?
B. You have included some image (without further explanation) that were supposedly meant to show differences between the two versions. If you wanted to point to the fact of different sequence of the WriteRequest/response and ReadRequest/Response, then this should not be a problem, because the "Read" is for an internal housekeeping variable used to check the status of the subscription, and not for any of your own data items.
C. Even though I have not seen it in the particular trace with version 5.50, I can imagine a situation where the client sends a PublishRequest followed by a WriteRequest, receives WriteResponse, but then receives a PublishResponse with the "old" values. Client would then issue another PublishRequest, and the server would send a PublishResponse with proper, "new" values. Whether this will happen or not depends on the server implementation, and will tend to happen mainly shortly after the subscription is created, if it is followed quickly by a Write, because at that point the server may not yet have sent the initial value. But I would have to actually see that in the traces in order to be able to identify it as a cause.

Regards

Just post the zipped file here, or, if you want to keep it confidential, send by email to sales09 (at) opclabs.com.

Best regards

How big are the trace files, after zipping?