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.

Subscriptions seems to be asynchronous ?

More
21 Mar 2017 13:24 #5019 by support
The second approach is how I would say most OPC servers actually work, and it is also closer to what the OPC spec says. But the first interpretation, I suppose, would also be considered OPC compliant.

Either way, it is the server-side that implements this, and an OPC client cannot influence how the server does it... You may want to discuss your concerns with the server vendor.

Best regards
The following user(s) said Thank You: m.baumgartner

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

  • m.baumgartner
  • Topic Author
  • Visitor
  • Visitor
21 Mar 2017 13:01 - 21 Mar 2017 13:02 #5018 by m.baumgartner
Replied by m.baumgartner on topic Subscriptions seems to be asynchronous ?
Thank you for your much detailed answer.
I can play deal with that, plus 10s was just an exaggeratedly high value for the example. We're probably going to go with 1000ms (1s) interval.

It's not quite clear to how you would want to work this differently. As you correctly expect, the RequestedUpdateRate limits the rate of changes being sent by the server to the client. Even if the *first* change was sent by the server right away what if the *next* change occurred just a second later? The server would have to wait 9 additional seconds anyway, to fulfill the rate limit - so you would be back to the same problem.


Well my understanding was like the following.
With a RequestedUpdateRate = 10s
Let's assume I start my subscription at time k.
Then my value would change at k+22seconds. I expected to get a notification at that exact time.
Then my value would change again at k+35 seconds. I expected to get a notification at that exact time.
Then my value would change again at k+37 seconds. I expected to get a notification at k+45 (previous change time + minimal interval of 10s)

Now If i understand you answer it should work as the following.
With a RequestedUpdateRate = 10s
Let's assume I start my subscription at time k.
Then my value would change at k+22seconds. I will get a notification at k+30s (k+ 3x10s)
Then my value would change again at k+35 seconds.
Then my value would change again at k+37 seconds. I will get only one notification at k+40s and only if my value differs from it's value at k+22s.
To make it shorter, it will send a notification to the next "tick" of the timer (which has a 10s interval), not "when the value change".

Am i correct?
Last edit: 21 Mar 2017 13:02 by m.baumgartner.

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

More
21 Mar 2017 12:02 #5017 by support
On the client side (with some simplification), we just pass the RequestedUpdateRate to the server, and its up to server to interpret it.

The OPC Server should conform to the OPC specification in this respect. The spec has some intentional, and some unintentional ambiguities in this area. It intentionally does not specify how the data make its way from the device to the server. The server can be polling for it, or it can be changed-based: that depends on the protocol. But once the value is in the server, the server is basically supposed to put it into its cache. And, have a periodic check whether there is a value to be sent to the OPC client in the cache.

Therefore what you are observing is not incorrect. If the update rate is 10 seconds, it can easily take up to 10 seconds before you receive the change. Make the RequestedUpdateRate lower if you want the change sooner.

It's not quite clear to how you would want to work this differently. As you correctly expect, the RequestedUpdateRate limits the rate of changes being sent by the server to the client. Even if the *first* change was sent by the server right away what if the *next* change occurred just a second later? The server would have to wait 9 additional seconds anyway, to fulfill the rate limit - so you would be back to the same problem.

Regards

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

  • m.baumgartner
  • Topic Author
  • Visitor
  • Visitor
21 Mar 2017 10:48 #5016 by m.baumgartner
Subscriptions seems to be asynchronous ? was created by m.baumgartner
Hello,

I'm new here as I'm evaluating OPCLabs to use it in my project. Looks great so far. However I have noticed a stranger behavior I'm not sur about.

I developed a simple Delphi application using TEasyDAClient to subscribe to item change thanks to SubscribeItem().
I'm not sure about the RequestedUpdateRate parameters though.
My understanding is that subscriptions are completely synchronous, meaning i'll get an event exactly when the value changes in my OPC Server. RequestedUpdateRate should serve as a limit for not getting too much notifications.
This is based on the following doc arcticle :
opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...o%20OPC%20Classic%20Items.html

However my tests shows that i'm getting the corresponding notification a bit after the change.
Example :
RequestedUpdateRate = 10000ms (10s)
- i'm manually changing the value in my OPC Server (Matrikon OPC Server)
- i'm not getting the notification in my client app right ahead but a few seconds later just like if the 10s were used as a simple synchronous update timer interval.

Am i doing something wrong here?

Here is a few lines of my code :
Client.OnItemChanged := OnItemChanged;
Client.SubscribeItem('', edServerOPC.Text ,  edTagOPC.Text , 10000);

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

Moderators: support
Time to create page: 0.047 seconds