Receiving data with constant time step and timestamp

[TE-2]

Hello everyone!

I am working on an OPC UA client using the FreeOPCUA library to regularly receive drive data with timestamp at a defined time rate from a PLC.
Using UAExpert I have already managed to retrieve the data with a defined time interval by using the DataChangeFilter settings ("Status/Value/Timestamp") and Monitoring Mode: Reporting.

here even with a sampling interval of 52ms via DataLogger:

However, I fail to implement these settings with the FreeOPCUA library.
I have managed to create a subscribe to a variable but neither a constant rate nor a timestamp to receive:

import sys
sys.path.insert(0, "..")
from asyncua.sync import Client


class SubHandler(object):

    def datachange_notification(self, node, val, data):
        print("Python: New data change event", node, val)

    def event_notification(self, event):
        print("Python: New event", event)

try:
    client = Client('opc.tcp://' + IP_Adresse + ':' + Port + '/freeopcua/server/')
    print("Connecting to: " 'opc.tcp://' + IP_Adresse + ':' + Port + '/freeopcua/server/')
    client.connect()

except:
    exit_routine("Connection has failed")

handler = SubHandler()
Subscription_mynode = client.create_subscription(200, handler)
handle = Subscription_mynode.subscribe_data_change(mynode)

etc.

The next thought was to use the Subscription.create_monitored_items() method, which I reconsider after this forum entry

Is this the right way to implement my requirements or can I adjust a timestamp and the DataChangeFilter in the client.create_subscription method somehow?

I would be very thankful for any support :)

[oroulet]

I am not sure what that timestamp option is about, I do not see it in any parameters, but it looks like you can create your subscribotion then just call sub.modify_monitored_item to chane queue size and deadband

[TE-2]

Thank you for the quick answer that helps me already further!

to be able to use the modify_monitored_item method I have to use the Subscription class and instantiate it beforehand.
is this the correct way?:

...
from asyncua.common.subscription import Subscription
...

handler = SubHandler()
Subscription_mynode = client.create_subscription(200, handler)

subscription = Subscription(server = UAClient)
subscription.modify_monitored_item(new_samp_time = 200, new_queuesize = 1, mod_filter_val =0)

handle = Subscription_PositionvMaster.subscribe_data_change(mynode) 

I am not sure if this is correct, because somewhere I would have to set the reference to the variable(mynode).

Could you please give me an example which parameters I have to pass to the constructor so that the call of the method refers to the subscription of my variable. That would be very helpful!

I have not been working with the library for very long and I am still trying to understand how it works.

[AndreasHeine]

If you need data in a fixed interval you need to poll it!
the subscription is not ment to be used for that, a subscription works like a good old mailbox which got emptied in a fixed interval and each monitored item puts a letter (datachangenotification) into the mailbox everytime the value changes (which is not automatically in a fixed interval!)

even if you use sampling instead of reporting it could be sometimes different.

edit:

if you really want to use the subscription for that you can resample the data to a fixed timeinterval with pandas!?

[mahadi]

@AndreasHeine: Yes, this is actually my main concern. So i understand that a server will typically not be able to manage different sampling rates for different monitored items (given a sampling interval greater than its minimum sampling interval). I guess this would be difficult to implement.
Using the SourceTimeStamp which cotains the sampling time on the server a resampling could be performed on the client side. But is this SourceTimeStamp available always? In the examples i see that it is None.

[AndreasHeine]

it depends...

https://reference.opcfoundation.org/Core/Part4/v104/docs/5.12.2.2
timestampsToReturn:
An enumeration that specifies the timestamp Attributes to be transmitted for each MonitoredItem. The TimestampsToReturn enumeration is defined in 7.35.

When monitoring Events, this applies only to Event fields that are of type DataValue.

https://reference.opcfoundation.org/Core/Part4/v104/docs/7.35
SOURCE_0 | Return the source timestamp.
SERVER_1 | Return the Server timestamp.
BOTH_2 | Return both the source and Server timestamps.
NEITHER_3 | Return neither timestamp. This is the default value for MonitoredItems if a Variable value is not being accessed. For HistoryRead this is not a valid setting.
INVALID_4 | No value specified.

[AndreasHeine]

if you use Both in the CreateMonitoredItems-Request it should return the timestamps!
the thing with implementation is that you usually set a nodes value with a DataValue which contains both timestamps. however i have seen some implementations where on timestamp is missing or set incorrectly... but thats not the normal case!

[mahadi]

Ok, sounds good, then i just need to make up my mind how i can handle differences in the PLC clock and my client clock. They are not guaranteed to be synchronised. Thanks a lot for the information and explanations!

[AndreasHeine]

opc ua by spec has UTC time! but changing it to local time is simple -> datetime -> tzinfo