Solution
There are a few items that control the update rate of a node that you will want to look into to make sure none of them are acting as the bottle neck in your system:
The publishing interval input defines the rate, in milliseconds, that the OPC UA server returns data change notifications to the OPC UA client. The default is 1000.
Sampling Interval
The sampling interval input (part of the monitoring parameters input bundle) specifies the maximum rate for the OPC UA server to sample its underlying source for data changes. The default is -1, which specifies that the sampling interval is the same as the publishing interval of the subscription.
Deadband
- The deadband type input (part of monitoring parameters >> data change filter) sets the type of deadband we are implementing (none, absolute, percent)
- The deadband value input (part of monitoring parameters >> data change filter) specifies the value of the deadband. By default this value is 0. The meaning of this parameter depends on the deadband type selected.
The frequency at that Write.vi is called will also affect the rate that clients will get updates. Check for the loop rate or triggers for the write that could delay the write.
LabVIEW OPC UA Toolkit Update Scheme
LabVIEW OPC UA Toolkit will not trigger an update to subscribed clients if the node value on the server does not change. This means even if the other parameters and VIs that control the update rate are set to a value that should allow to quick updates, there will be no event triggered if the value of a given node does not change.