Setting publishing interval of subscription doesn't change behaviour about opcua-asyncio HOT 11 CLOSED

The value 0 indicates that the Server should use the fastest practical rate.

The value -1 indicates that the default sampling interval defined by the publishing interval of the Subscription is requested.

Thanks for this explanation. As described in my last comment, this was the workaround.
Setting it to 0 doesn't use the fastest rate, so I assume thats a server issue.
Setting it to -1 works as described and will be my solution.

from opcua-asyncio.

revised values come from server!

from opcua-asyncio.

Expected behaviour:
The python client gets a new value every ~50ms

You create a MonitoredItem and tell him Sample every 50ms -> so every 50ms a Notification will be Queued, thats the Samplinginterval.

The PublishingInterval is how often the Subscriptions Queue gets delivered to the Client.

So you will have values each PublishingInterval (e.g. 1s) -> which should contain 1000ms/50ms notifications (+/- 1 or 2 depends on the timing and latency)

from opcua-asyncio.

As shown above, the RevisedPublishingInterval and the RequestedPublishingInterval are 50ms.

The exact same code works as expected, if I change the default timer serverside. Other Clients work as expected even without changing the default timer.

Therefore I assume a client issue.
Or can you tell me what change I have to make to get a sample every ~50ms with default timer 1000ms and tag timer 50ms like with UaExpert?

from opcua-asyncio.

what do you mean with default timer?

the client just asks the server to send him the queued changes like letters in a mailbox. the transport interval is the publishing interval the sample rate is just the rate of how many messages are in the mailbox!

i dont think uaexpert shows all values tbh 50ms is kind of hard to see... guess they skip some while rendering.

from opcua-asyncio.

OPC UA Subscription = Long polling

edit:
https://documentation.unified-automation.com/uasdkhp/1.4.1/html/_l2_ua_subscription.html

from opcua-asyncio.

what do you mean with default timer?

If I have multiple tags on the PLC, they all have the default sampling interval. In my case it's set to 1 second.
I can change each tag to a different interval, though. For example if I want to have 99 tags at the default 1 second interval and one tag at 50ms.

i dont think uaexpert shows all values tbh 50ms is kind of hard to see... guess they skip some while rendering.

Correct, the limit of UaExpert is 200ms. That is part of what I'm trying to explain. Sorry if it's a little confusing.

UaExpert tells me 3 values:

• When i click on the tag, it shows me the MinimumSamplingInterval in the attributes.
  This is the value (50ms) I set in the server.
• When rightclicking and going into the subscription settings, I can change the publishing interval. To 100ms for example.
• In the logs of UaExpert, it also tells me the Sampling Interval of 200ms. And this is the limit in the case of UaExpert.

So even if the tag updates every 50ms on the server and the publishing interval is 100ms, I still get the value every 200ms in UaExpert. (Makes sense)

We don't have this second sampling interval in the python library, right? So I'd expect to get a value every 100ms in the same scenario. And the weird thing is, that it actually does that, if I change the default value to 50ms on the server.
But the drawback is, that that setting changes all my tags to 50ms... That default setting shouldn't do anything else. Just saves me from changing the settings for every Tag individually.

Since UaExpert recieves values at 200ms and the python client at 1s with the same server setup, I assume it's a client issue.

from opcua-asyncio.

But the drawback is, that that setting changes all my tags to 50ms...

in the Server?

from opcua-asyncio.

in the Server?

Yes, the default timer changes the sampling intervals of all tags on the server that don't have this value overwritten.

from opcua-asyncio.

I found a workaround. I looked into the code and noticed that the subscribe_data_change function has a parameter sampling_interval that is set to ua.Duration(0.0).
If I set this manually to 50ms, I get the desired behaviour.

Still doesn't explain why setting it to 0 uses the default server interval instead of the correct tag interval, though.
Didn't check the exact reason. Maybe a server issue after all, maybe fixable in the client.

Feel free to close this issue if it's not client related.

from opcua-asyncio.

cannot really help you on the B&R stuff... but i can tell you that the client-subscription is kind of the dump side and the smart logic belongs to the server...

if you do:
subscription = await client.create_subscription(handler=handler, period=0)
the server revises the 0.0 to whatever he can do as fast as possible according to spec:
https://reference.opcfoundation.org/Core/Part4/v104/docs/5.13.1
https://reference.opcfoundation.org/Core/Part4/v104/docs/5.13.2

requestedPublishingInterval:
If the requested value is 0 or negative, the Server shall revise with the fastest supported publishing interval.

revisedPublishingInterval:
The actual publishing interval that the Server will use, expressed in milliseconds. The Server should attempt to honour the Client request for this parameter, but may negotiate this value up or down to meet its own constraints.

if you do:
await subscription.subscribe_data_change(node)

        nodes: Union[Node, Iterable[Node]],
        attr: ua.AttributeIds = ua.AttributeIds.Value,
        queuesize: int = 0,
        monitoring=ua.MonitoringMode.Reporting,
        sampling_interval: ua.Duration = 0.0
    ) -> Union[int, List[Union[int, ua.StatusCode]]]:

you request to create the monitored item with samplinginterval of 0.0 means

according to spec:
https://reference.opcfoundation.org/Core/Part4/v104/docs/5.12.1.2
and
https://reference.opcfoundation.org/Core/Part4/v104/docs/5.12.2
https://reference.opcfoundation.org/Core/Part4/v104/docs/7.16

samplingInterval:
The interval that defines the fastest rate at which the MonitoredItem(s) should be accessed and evaluated. This interval is defined in milliseconds.

The value 0 indicates that the Server should use the fastest practical rate.

The value -1 indicates that the default sampling interval defined by the publishing interval of the Subscription is requested. A different sampling interval is used if the publishing interval is not a supported sampling interval. Any negative number is interpreted as -1. The sampling interval is not changed if the publishing interval is changed by a subsequent call to the ModifySubscription Service.

The Server uses this parameter to assign the MonitoredItems to a sampling interval that it supports.

The assigned interval is provided in the revisedSamplingInterval parameter. The Server shall always return a revisedSamplingInterval that is equal or higher than the requested samplingInterval. If the requested samplingInterval is higher than the maximum sampling interval supported by the Server, the maximum sampling interval is returned.

from opcua-asyncio.