R.,

I have not seen in this happening, but I think it may happen if the application code is using BOTH subscriptions and on-shot reads on the same target OPC server. Here is my hypothesis – one of the possible scenarios that can cause it:

1. OPC server changes the value to 1 (and calls back to the component).
2. The component is processing value 1. Due to the asynchronous nature of it (callbacks must not block the server), the value are put into an internal queue (this is simplified but OK for this explanation)
3. OPC server changes the value to 2 (and calls back to the component).
4. The user application calls ReadItem.
5. The component decides to performs actual OPC Read in this case (depends on various conditions, but can happen).
6. The OPC server returns value 2.
7. The component returns value 2 to the user application
8. Value 1 is pulled from the internal queue and stored internally as a value of the tag.
9. Value 1 is sent to the user application in ItemChanged event, and also becomes the value that any subsequent Read will use.

I do not know how this should relate to being WinForms or a service, but that might be just coincidence having to do with different timing of things.

If this is what is happening, the solution would be to use one “client” object for subscriptions and second for “reads”, and set their Isolated property to True. I think we should make it clear in the documentation that if the value order is relevant, the user application should settle on either direct method calls, or subscriptions, but not both on the same object.

Zbynek Zahradnik

From: R.
Sent: Thursday, February 03, 2011 10:43 PM
To: Zbynek Zahradnik
Subject: RE: Topic Timeouts

Z.,

The customer [...] is seeing another problem [...].

One of his tags is a counter for a process. In TOP Server, using the Quick Client, all of the values show up fine in progression, as expected. When he runs his application as a winform application, everything is fine. When he builds it as a service, the values come back out of order. For instance, instead of 1,2,3,4 it might be 4,2,1,3, which is obviously incorrect for the counter.

The code is exactly the same, he just builds it either for an app, or a service. Any idea what could cause this? Is this a threading issue?

R.