From: R.
Sent: Tuesday, August 02, 2011 2:11 PM
To: Zbynek Zahradnik
Subject: RE: GetServerStatus Replacement

Zbynek,

Thank you for the detailed response.

I do not think there is a need for the GetServerStatus call at all. I think the way the current version of the component handles this is more than adequate. I had assumed much of what you already described in terms of using the Exception property to determine any connection errors. But, I wanted to verify this so I could be confident in my response to the customer. You have given me all the information I need.

Thanks again,
R.

R.,

I should also add that in other cases of server disconnection, the actual exception/error codes are different, but otherwise the behavior is the same. For example, if the OPC server has requested a shutdown, the error code is 0xC0049006, and the message is:

Server shut down. The OPC server indicated that it needs to shutdown. The application is releasing all connections and interfaces
for this server. The application will try to reconnect to the server after a configurable period.

Best regards,

R.,

no, there is no such method in versions 5.x.

A lot of thought had gone into this. The problem with this method was that it collided with the general design idea of the component. All remaining methods are based on the concept that what you really need to work with are OPC items, because it is them that provide read/write access to the process data. Anything else – connections to OPC servers, creation of OPC groups etc. – are just internal means of achieving that goal, and the component handles them silently in the background – the developer does not have to be aware of their existence.

The component does GetStatus on IOPCServer periodically, and the server indicates that there is a fault, the component disconnects and reconnects after a configurable delay, automatically. The result of it is also indicated to the hosting application, depending on how the application is written. We have two modes of working with OPC data:

A) “One-shot” methods such as ReadItem, WriteItemValue etc.

In this case, if the server has indicated a failure through GetStatus, the methods throw an exception (or, if they return multiple results, they have their Exception property filled). The component defines a specific error code just for this: It is 0xC0049001, and the associated message says:

Server failed. This error originates in the OPC Data Access server. A vendor specific fatal error has occurred within the server.
The server is no longer functioning. The recovery procedure from this situation is vendor specific. The application will try to
reconnect to the server after a configurable period.

Technical information: The call to IOPCServer::GetStatus on the OPCServer object has returned OPC_STATUS_FAILED in the
OPCSERVERSTATUS structure.

(There is also a specific code and similar message for OPC-A&E).

These “one-shot” methods are typically used in scenarios such as report creation, scripted tasks, and logging. The logic in the application can simply fail this particular time, and attempt to do the same next time it is scheduled. If the background reconnection succeeded by that time, the exception will no longer occur.

Problems with GetServerStatus in versions 3.x was included the fact that the server may not have been “in use” at the time of the call at all (if the application has done it BEFORE calling ReadItem etc.) – in this case, the method ended up firing up the server just to figure out its status. And, if the application got any failure status, it was not giving it additional information over what you can already have by interpreting the failures from methods calls such as ReadItem, WriteItemValue, etc. anyway.

Subscriptions.

In this case, if the server has indicated a failure through GetStatus, all subscribed items for that server will receive the ItemChanged event notification, with the EasyDAItemChangedEventArgs.Exception member filled in with the same error as described in the above case. When the connection is eventually reestablished, all subscribed items will receive the ItemChanged event notification again, this time with EasyDAItemChangedEventArgs.Exception member being a null pointer (and some data in the Vtq property).

This way, by simply writing a proper code for the ItemChanged event notification, the actually can be constantly aware of the server status for each item it has subscribed to. So, to answer your question, there is no specific event, but the ItemChanged event is used for the same purpose.

Note that I think we have touched this subject earlier, and you were OK with the fact that no replacement exists for that Extender functionality.

If you think that there is an application scenario that cannot be resolved with the existing design, I’d be interested in knowing the details. We can think of re-design for future versions, if there is truly a need for this.

Best regards,

From: R.
Sent: Monday, August 01, 2011 4:23 PM
To: Zbynek Zahradnik
Subject: GetServerStatus Replacement

Zbynek,

Do you have a method similar to the GetServerStatus method that was available in version 3.02? I was not able to find anything in the help file- I’m guessing the closest would be to check the DAQuality.StatusBitField property?

Also, you have client engine parameters for the reconnect timeout and shutdown request reconnect delay- but I don’t see any way to handle events when the client receives a shutdown notification or the connection to the server is lost.

Thanks in advance,
R.