I have split the part about A&E into a separate forum thread

From: .....
Sent: Monday, October 17, 2011 8:03 AM
To: Zbynek Zahradnik
Subject: SV: Ang.: How to check OPC Server Status?

Hi,

Thanks for the info, I have made a solution where I use the sync event from Microsoft and it works like a clock. However, the sulotion that you propose now seems to be more "efficient" and secure when it comes to large amounts of items. I will change my code to see how it wors.

I have tried to make a AE client also but i do not get any event callbacks, but it can be some error from my side I will look into it a little bit more on Wendsday. It there anything special to think about when using AE?

Best regards.
J.

Hello,
I have just realized that I have got “distracted” by the way the question was formulated, and have not explained that what you are trying to do is actually achievable in much better way.

Basically, the returned handles are only meant for changing existing subscriptions, or for unsubscribing.

For the purpose of interpreting the incoming event notifications, there is a different way: A “State” argument. This is an arbitrary value that you can pass INTO the SubscribeMultipleEvents, and then you receive it as part of every event notification. There are two main advantages of using the State inside the event handler, as compared to using the handles:

- You define the State-s BEFORE the call to SubscribeMultipleEvents. Thus, there is no need to wait until this call returns – the event handler does already have all the information, even if the component starts shipping events during the call or shortly after.
- You can define the State-s to be something that can be easily processed by your application. It can e.g. be a pointer right to the object that you have in your application for each item. In the event notification, you just need to cast it back, and no further lookup is necessary, making it much more efficient.

I hope this helps.

Hello.
You are right that you would lose the initial updates if you hook the event later.

One way to deal with this is as follows:

- define an event (a Windows synchronization object), initial state: reset
- in the beginning of the event handler, wait for the event
- set the event after you process the handles received from SubscribeMultipleEvents.

This will cause the event handler to block until it has all the data it needs. This may seem dangerous, but provided that you actually make sure that the event always gets set eventually, it is not, for following reasons:

- The SubscribeMultipleEvents call does not actually wait for anything "physical" to happen with regard to OPC communications. It is just setting things up and starting the necessary actions. So, it is just a CPU-bound task. Similarly, your processing of the received handles is just a data manipulation that should be finished quickly.
- There is a queuing mechanism inside the component, therefore any blocking inside the event handler does not block anything else.

Best regards,

From: C.
Sent: Thursday, October 13, 2011 2:08 PM
To: Zbynek Zahradnik
Subject: ....

Thanks,

Everything regarding the subscription seems to work fine. The only concern I have is that I save all the server handles for the items that I have added to the subscription, (returned as HandleResults). I use them to crossreference the correct incoming item value in ItemChange with an collection of object in my application in order to send the correct value to the correct object.

The problem is that the initial update of all values is started before I have setup my crossref table. If I make Advice on the EasyOpc pointer after the call to SubscribeMultipleItems and crossref setup I assume that I will lose some or all of initial values.

Is there any possibility to call the SubscribeMultipleItems, setup the crossref, Advice the EasyOPCpointer and then make a refresh of the subscription in order to get all the values?

Best regards