Sent: Thursday, October 04, 2012 10:13 AM
Subject: RE: Support question.

Hi,

[...], I have tried the solution and it seems to hold. The only concern right now is memory consumption and thread security in my client when we make refresh since there are a lot of alarms active in the test system right now, several hundreds. But it seems to work……… J

Thanks,
J.

Sent: Thursday, October 04, 2012 8:06 AM
Subject: RE: Support question.

Hi,

Thanks for all the information, I have some coding to do to make this work J

The secondary client will initiate a Refresh to get hold of all the cookies and timestamps and add the correct info to the synchronized datat from the primary client.

Thanks for your time and quick answer,
Best regards
J.

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,

Sent: Wednesday, October 03, 2012 12:31 PM
Subject: RE: Support question.

Hi,

I have little question regarding the A&E functionality of the toolkit.

I have two OPC Clients that are redundant ie they receive the alarms from the OPC Server and send them to a control room application. Since the control room application only connects towards one OPC Client at a time, the OPC Clients are divided into a primary and secondary client. Both clients synchronize with each other so we do not loose any event coming into the clients (OPC is a small part of the application, it synchronizes a lot of other data too). The secondary client is “state-less” ie it sends all the events coming from the OPC Server to the primary client, as long as it has connection towards the primary client.

Everything works great except Acknowledge of alarms. The clients synchronize all data, both active timestamp and cookies for the alarm. The problem is that the primary client gets another cookie than the secondary client. If the primary client fails the secondary will take command and use the data synchronized, but it is not possible to acknowledge alarms with the primary clients cookie.

As I understand it the cookie is specific for each client and event. For the same event I receive two different cookies, one for each connected client, is this correct?

If so, why does the OPC Server has to have the correct cookie from the correct client in order to acknowledge the alarm? Is there any way around this problem. I would like to send one received cookie from one of the OPC clients in any of other clients and acknowledge the alarm.

Best regards
J.