Subscriber Publish Response not received immediatly after creating a monitoredItem

[jordi_igrid]

Hi,

I'm trying to implement an OPC server using the uaserver SDK 1.9.0 version, but I've found the following behaviour:

In the Part 4 of the standard (OPC 10000-4 5.12.1.3 Monitoring mode), it's stated that, "When a MonitoredItem is enabled (i.e. when the MonitoredItem is changed from DISABLED to SAMPLING or REPORTING) or it is created in the enabled state, the Server shall report the first sample as soon as possible".

However, what I see in both, my server implementation and in the UaAnsiCServer demo server is that, when adding a MonitoredItem, I only get the publishResponse after waiting for the Publish Interval to end.

I've also tried using other OPC UA servers and they behave the way the norm says, sending the Response immediately after the MonitoredItem is created.

I would like to know if this is the expected behavior of the UA server due to a limitation of the SDK, or if there is a way I can choose whether I want the server to send the response immediatly or after the Publish Interval completes.


Thanks for your help,
Jordi

[Support Team]

Hi,

the "as soon as possible" means: "with the next Publish", because the publish interval should under no (only very few) circumstances be shortend and generally is independent from amy item settings. The implementation in AnsiC SDK (and in many other SDK) is correct. Keep in mind that "sampling" is on the item, and "publish" is on the subscription. Modifying an individual item should not influence/change the behavior of the subscription (including not changing the interval).

See Subscription state table for possibilities (only 2 exceptions where server can fire earlier than the publish interval):
https://reference.opcfoundation.org/Core/Part4/v104/docs/5.13.1.2

In many cases the "immediate" response after creating monitored item will result in "BadWaitingForInitialData" value=null, which gives you a quick answer, but has no value. In OPC UA there is a trigger method called ResendData, which allows some "refresh" from cache, in case you havn't heard from your items since a while, or in case you come back after an interruption.

A good server would protect it's source from load created by annoying clients activating/deactivating (or even worse add/remove) individual items in a running subscription. The whole concept of subscription is to reduce load from, and allow optimized communications to, underlying source.