Apologies - I have probably switched the role of primary and secondary client in my explanation, but the idea should remain the same.
.....
Sent: Thursday, October 04, 2012 6:53 AM
Subject: RE: Support question.
Hello,
Your understanding of what is happening is correct, but here is some additional information that may help:
The OPC specification does not require the cookies for the same transition sent to different clients be the same – or different; this is left up to the OPC server. I would actually think that most servers would send the same cookie to the clients, and those e.g. that we have implemented do behave that way, but there is no such requirement or guarantee.
Unfortunately that’s the way the OPC works and we cannot influence it.
Even if the above has worked, there is one more thing: The full identification of the alarm being acknowledged is done by a combination of the cookie, and the time of the alarm. The OPC Server should expect those two being precisely equal to those that it had sent with the alarm. The time of the alarm in OPC is internally a FILETIME, but because that’s not the usual format in the apps and for the developers, the component converts it to a VARIANT with VT_DATE (in QuickOPC-COM) or a DateTime (in .NET). This conversion is not lossless, however; these formats can have less precision. So, when you then pass the time back (together with the cookie) for the acknowledgement, in order to assure that the OPC server receives precisely the same time, we look up the value in the list of alarms that we have seen, and this way it can be converted back to precisely the same FILETIME as before. This, however, only give a guaranteed “round-trip” of the alarm time value within a single application; if the times are passed to a different application, they may not convert precisely.
Note that there is a situation where this may become a problem even with a single client: If, for whatever reason, the client was not “listening” when the condition became Active (e.g. because it was disconnected by a network problem, or simply not started yet), how does the client get the cookie to acknowledge the pending alarms? The OPC call GetConditionState (and or corresponding method) does return the timestamp of active transition, but not the cookie. So one piece is missing.
There is, however, one way the missing cookie (together with the active transition timestamp) can be obtained: By a “Refresh” call. In our component, the Refresh is done either automatically when we connect, or explicitly by the RefreshEventSubscription method. Note that there are flags in the event notifications that allow you to recognize a) when the notification comes from Refresh and is not a regular one, and b) when the Refresh has completed. There is a discussion about the meaning of these flags in the Concepts document.
You should therefore be able to pass the event source (e.g. its qualified name) and the condition name to the secondary client, and the secondary client will then obtain the cookie(s) by Refresh. The refresh can either be done on an area (or the whole server – the root), and you can “pick up” the condition states that you need, or you can invoke a Refresh on a narrower piece of the event space.
I hope this helps,