Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

EasyUAClient event when all relevant subscribed values is updated

More
23 Jan 2019 08:46 #7026 by support
You are right. There actually is a bug in current QuickOPC, the first of code should work as well. It will be fixed in the upcoming QuickOPC version (2019.1). Thank you for reporting it.

Just for clarity, the expected behavior does not *directly* set the PublishingInterval in UASubscriptionParameters to half of the SamplingInterval in UAMonitoringParameters. It should set it to zero. The zero has a special meaning, and at the moment QuickOPC actually creates the subscription, it will interpret the zero and use the half of SamplingInterval instead. This is done so that the parameters do not have to modify themselves mutually.

Best regards

Please Log in or Create an account to join the conversation.

More
22 Jan 2019 11:28 - 22 Jan 2019 19:46 #7016 by veda
Ok, that makes sense. As indicated this should probably be highlighted in the documentation. In all examples I have located only the SamplingInterval is set and not PublishingInterval. I was under the impression that PublishingInterval was automatically set to half the SamplingInterval by default.

Non working code:
_subscribeItems.Add(
                new EasyUAMonitoredItemArguments(
                    dataChangeCallback: null,
                    endpointDescriptor: _endpointDescriptor,
                    nodeDescriptor: nodeId,
                    monitoringParameters: new UAMonitoringParameters(UpdateInterval),
                    state: identifier));

Working Code:
_subscribeItems.Add(
                new EasyUAMonitoredItemArguments(
                    dataChangeCallback: null,
                    endpointDescriptor: _endpointDescriptor,
                    nodeDescriptor: nodeId,
                    monitoringParameters: new UAMonitoringParameters(UpdateInterval),
                    state: identifier,
                    subscriptionParameters: new UASubscriptionParameters(UpdateInterval/2)));
Last edit: 22 Jan 2019 19:46 by support.

Please Log in or Create an account to join the conversation.

More
22 Jan 2019 06:37 #7014 by support
I probably know what has happened. It is not that the rate was revised by the server. The issue was likely in the parameters passed in from your code. The PublishingInterval is set to 0 in the parameters (and then automatically determined by QuickOPC from the SamplingInterval) only in certain overloads of the constructors used to make the EasyUAMonitoredArguments. In other cases, the PublishingInterval has the default of 1000 ms. I would have to see the precise code to determine what has happened, but this is the likely cause.

I admit that this may not be quite clear to the developer from the current documentation.

Best regards

Please Log in or Create an account to join the conversation.

More
21 Jan 2019 09:58 #7010 by veda
Update...

Added UASubscriptionParameters argument to EasyUAMonitoredItemArguments constructor with PublishingInterval set to half the SamplingInterval and the update from the server worked at the correct SamplingInterval (200ms). Is this the correct approach? Based on earlier post I thought this should be automatically set.

Please Log in or Create an account to join the conversation.

More
21 Jan 2019 08:14 #7008 by veda
Below is output from Client when subscribing to one variable. Seems like the publishing interval is revised to 1000.

Information(2171): The OPC-UA server on endpoint URL "opc.tcp://192.168.23.61:55101" returned an empty list of software certificates.
Warning(2181): The OPC-UA server on endpoint URL "opc.tcp://192.168.23.61:55101" returned an empty server signature.
Information(2191): The maximum request message size 41943040 returned by the OPC-UA server on endpoint URL "opc.tcp://192.168.23.61:55101" appears unusually long relatively to maximum response message size of 4194304.
Information(2023): The OPC-UA client session with connect sequence number 1 has successfully connected to endpoint URL "opc.tcp://192.168.23.61:55101". The server-assigned session Id is "ns=1;g=4588e09b-b9c3-4fe5-9b93-e3d995cc6a12".
Information(3002): The OPC-UA subscription on client session with connect sequence number 1 to endpoint URL "opc.tcp://192.168.23.61:55101" has been successfully created and checked, and given subscription ID 2608252001. Revised publishing interval is 7500, keep-alive count is 11520 and lifetime count is 34560.
Information(3002): The OPC-UA subscription on client session with connect sequence number 1 to endpoint URL "opc.tcp://192.168.23.61:55101" has been successfully created and checked, and given subscription ID 2608252002. Revised publishing interval is 1000, keep-alive count is 86400 and lifetime count is 259200.

Please Log in or Create an account to join the conversation.

More
19 Jan 2019 14:45 #7005 by support
I understand that sometimes there might be a need for "seeing" the physical grouping of the values, but hiding them is a deliberate design decision that has to do with the very principles of QuickOPC, and it is not going to change. Different toolkits will work differently in this respect.

If you have set the SamplingInterval to 200 ms, QuickOPC will set the PublishingInterval to 100 ms, and request these from the server. if the server does not adjust the values, you should then be getting new values at around 100 ms rate (and their time "resolution" will be 200 ms in principle). The server can modify the requested rates. If you can get values faster with OPC Scout, it's weird. Firs thing to do is that I suggest to attach a handler to the static EasyUACLient.LogEntry event, and observe what happens when the subscription is being set up - to check whether the rates are as expected (you may post the log here).

Regards

Please Log in or Create an account to join the conversation.

More
18 Jan 2019 11:13 #7000 by veda
Thanks for the input. I see that this kind of event probably does not make sense in general (even though it might do in my special case). The reason why it would be beneficial for my API is that I would like to have som smart invalidation of subscriptions, but as you describe this can be custom made.

Could you please elaborate a bit on the last input regarding SamplingInterval and PublishingInterval. I my current client I do not get subscription update nearly as fast as defined in my EasyUAMonitoredItemArguments (200ms). I guess this is a setting in the EasyUAClient? Ideally I would like updates from the server at 100ms rate (I get this update if I connect direcly with Siemens OPC Scout).

Please Log in or Create an account to join the conversation.

More
18 Jan 2019 10:49 #6998 by support
Just to be sure: Be aware that there are two "rates" to be set/considered, between the OPC UA server and the client.

In QuickOPC, one is called SamplingInterval. That is the logical rate. And the other is PublishingInterval. That is the physical rate. The physical rate should be set to suit the needs of the logical rate, but it is the logical rate (SamplingInterval) that matters.

The PublishingInterval is typically faster than SamplingInterval (QuickOPC makes it half the SamplingInterval normally), but can also be different, you can change that from the code as well. It can even be longer than SamplingInterval, which typically only makes sense with Queuing enabled (not all servers support it), otherwise sampled data might get lost.

This does not directly concern your question, but indirectly it does.

Regards

Please Log in or Create an account to join the conversation.

More
18 Jan 2019 10:32 - 18 Jan 2019 10:33 #6997 by support
Hello.

There is no such event in QuickOPC.

With some simplification, in the situation you have described, the OPC server will send the 50 values (in one message) each 200 ms to the client.
QuickOPC will deliver this to you each 200 ms as 50 separate DataChange events or callbacks.

The fact that the 50 values come together from the server to the client is purely a physical, transport concept, that has no (= should not have) semantics/meaning to the client. You cannot rely on it anyway, as it won't always be the case. If you have written your program in such a way that it requires those 50 variables come together at the same time, you would be doing it wrong already.

The "grouping" of values makes sense between the server and the client, because the connection is, in comparison to the internal processing inside your program, uncomparably slower. The grouping achieves efficiency. On the other hand, if you were to process the incoming message "as a group", at some some early or late point you will have to write a loop inside your code to process them one by one anyway. QuickOPC does this "ungrouping" already, but as you can see, the performance impact is not big in this case, because it does not differ much from you doing it in your code.

If you need to interpret the incoming values as a group, you should have some other information that glues them together. Typically that is a timestamp. Reassembling the values using this extra information complicates the code, but is the right way to do it.

If you want to "group" values you send over your websocket API, but do no care about how precisely the values are "grouped", you can have a logic that ships out the values always after a certain number of events accumulate, or after a certain delay.

Best regards
Last edit: 18 Jan 2019 10:33 by support.

Please Log in or Create an account to join the conversation.

More
18 Jan 2019 07:45 #6995 by veda
I am currently evaluating your product to make an API for publishing OPC values over websockets. The OPC server I am connecting my client to is a Simatic NET server connecting to PLC's. The server pulls the PLC's at regular intervals (typical 100ms) to update values.

My client connect to this server and subscribes to a lot of values at 200ms refresh rate. I have registered a DataChangeNotification callback on EasyUAClient. Lets say that the OPC server updates 50 values every 200ms. To my understandting, this will lead to 50 call's to DataChangeNotification. Given an OPC server with this design I would like to have a callback from the EasyUAClient every 200ms that it has finished updating subscribed values for this iteration. In my application this would be very beneficial.

Is there souch an event? I would assume that when I register all values with SubscribeMultipleMonitoredItems with 200ms refresh rates that the EasyUAClient will call the DataChangeNotification several times each 200ms.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.057 seconds