Hello,
I am trying to understand how to set up subscription settings for my OPC UA tags in Ignition V8.0.9 and I faced some issues that I need an assistance with:
what is the relation on publishing interval and rate (when direct mode is selected). I ve read other forum topic where it was explained that rate is sample time and Publishing interval behind OPC UA tab is publish time. What happens if rate is bigger than Publishing interval? Is it so that if rate is set bigger, then it is set to publishing interval (somewhere behind the scenes). I tried to set 10 seconds rate (Driven) and 1 second Publishing interval just for testing, and it results in 5 seconds publishing interval. It is really confusing.
When driven mode is selected for OPC UA tag does it only change sampling time when condition is met? If it is like that, then it does not give much benefit, I need to make faster publishing from server to Ignition once the condition is met. Is it somehow possible? Does driven and leased modes at all make sense when using OPC UA, because they do not modify publishing time at all, only rate?
Is it somehow possible to trigger data read on demand? For example I have OPC UA tag group with publishing interval 30 seconds and I want Ignition to update all tags when for example I press some button. Is it possible to accomplish? Like in between 2 publish requests?
Last issue…sorry I just havent faced much with queue size before, so I am not sure how it works. So if I have OPC tag defined and I assign it to tag group where rate is 1 second, publishing interval is 10 seconds and queue size is 10, does it mean that every 10 seconds server will send 10 values? But then in tag value I only see one value (which I assume is the last one), not 10. Where are those other 10 values? Are they used for some historian or trend applications inside Ignition or they could be saved to SQL server?
In most cases you would want publishing interval to be equal or faster, but it doesn't matter. In OPC UA the Publishing Interval is how often the server sends accumulated changes for all items in a subscription to the client. Sampling Interval (tag group rate) is how often the underlying item is sampled (e.g. how frequently the PLC is polled).
Just use a faster publishing interval at all times then. There is not much downside to this.
Not other than doing an explicit read with system.tag.read* or system.opc.read* functions.
Yes, but only if there are 10 changes to the value that occur. You only see the latest in the UI but the other systems (history etc...) should be receiving all the value changes. Only changes to value or status (quality) are reported.
In most cases you would want publishing interval to be equal or faster, but it doesn't matter. In OPC UA the Publishing Interval is how often the server sends accumulated changes for all items in a subscription to the client. Sampling Interval (tag group rate) is how often the underlying item is sampled (e.g. how frequently the PLC is polled).
So when I used 1 second for publishing and 10 seconds for sampling and in fact server published at rate of 5 seconds, is it bug or something? That is really not logical.
Just use a faster publishing interval at all times then. There is not much downside to this.
So using driven mode does not make sense for OPC UA? But if I use faster publishing time, the downside is more traffic. And we have lots of small sites where we buy LTE with 2 GB of data only.
Maybe. The server is allowed to revise the publishing interval that is requested. Was this with Ignition's OPC UA server? And you're using Ignition 8?
I'm not sure driven mode is necessary if the sampling is occurring at the edge (i.e. the OPC UA server is running at the edge) rather than over the bandwidth constrained connection. You can just set a faster sampling interval, slower publishing interval, and optionally set a larger queue size.
If it's running on the other end of a slow connection, on the same network as the devices.
It might, if there were multiple changes to the value. If you only care about the current value and not any changes that might have occurred in between then you don't need a queue size larger than 1.