Log In
Home
05/23/2014
Offline
We have a situation communicating to two well known manufacturer OPC UA Servers.
Our OPC UA client sets a digital bit in the PLC to 1. The new value is being seen by the PLC program, executes some internal logic and immediately resets this digital bit to 0 in the same PLC cycle. The OPC UA Servers do not sending us a 0 value callback and therefore our client software continues to see the digital bit still as 1
If the PLC program resets the bit in a subsequent cycle, or after a 100ms delay ... then all works as expected and our client receives a 0 value callback
We are able to resolve the issue by executing a read of the item immediately AFTER writing the item.
The problem does NOT exist when using UA Automation's OPC UA Expert client i.e. after setting the digital bit to 1, the client immediately reverts it's value back to 0 - but we do not know whether the OPC UA Expert client is doing a "read after write"
My question is … are OPC UA client applications expected to do a read after write to circumvent the above anomaly? Or are OPC UA Servers meant to deal with this condition and ensure that a 0 value is sent back to the client
05/30/2017
Offline
If you are viewing in the subscription window, UAExpert only updates after receiving an update from the Server.
If you are viewing from the attribute view then does a new read.
You need to look at the publishing interval/sampling interval you are using because they introduce lag between a change in the server and when the client sees the change. Requesting 0 for both would give you a response that is as fast as the server can provide.
05/23/2014
Offline
Thanks for the response Andy
- We are viewing the subscription window
- UAExpert has an item sampling interval of 3500ms and a publishing interval of 500ms (default UAExpert values) ... so a value of 0 for both is not used. UAExpert is seeing value of 0 immediately ... even if we put the publishing interval to 5000ms !!! Which seems to indicate that they may be doing a read after write.
- Our client is using equal publishing and sampling times of 1 second ... I cannot see that should be a problem. At worst case we might expect to see a return to 1 after 2 seconds. But our client is definitely NOT receiving callback for the value 0.
I need to re-iterate ... that if the PLC resets the bit to 0 in the NEXT cycle ... everything works as expected. This implies to me that the OPC Server software is requring to seea change in data between PLC cycles for publishing to happen. If a client sets a value to 1 and the next PLC cycle keeps it back at 0, the OPC Server software is assuming no value change and therefore NOT publishing the 0 value. If however the software compared the value at the end of the PLC cycle (0) to the last written value (1), he would see a difference and republish the value of 0.
05/30/2017
Offline
UA subscriptions are based on premise that new data is only sent if the data has changed from the last value sent to the client.
This is an important design feature that ensures predictability in behaviour from the perspective of clients. If the sampling interval is set so large that the change to 1 is missed then you would not get an update because the last value you received is the correct value (i.e. the server has no way to know that, in your case, the client wants to see a spurious update because of a write/reset during the sampling interval).
If this is a concern you can:
1) Set 0 as your SamplingInterval.
2) Set your DataChangeFillter to ValueTimestamp
2) Monitor your publish responses. If you don't get an update in the next publish response you know that the value was reset.
This may be counterintuitive, however, if you trust the subscription engine to give you an update when value changes then you can also trust that if you did NOT get an update then that means the value did NOT change. The absence of an update does not mean "subscriptions are not working".
I realize that many UIs like to update their displays after a write and depend on an update to reset their UIs but this is not the right thing to do. A display showing updates provided via subscription should only show updates provided via subscription. If the Client has any logic to update those values via other means (even a read) then there is a risk of the display getting out of sync because value displayed does not match what the server is using to determine if data changed.
1 Guest(s)
Usage Policy