From: Zbynek Zahradnik
Sent: Friday, March 30, 2012 9:15 AM
To: P.
Subject: RE: Actions on comms failure
P.,
There are basically two ways how “problems” can be reported in OPC specifications (and consequently, in QuickOPC): 1) By a Quality (in Value-Timestamp-Quality structure), and 2) by an error code returned by function calls and callbacks.
Typically, problems that the OPC Server has accessing its target data source (such as PLC comms) are reported by the Quality, while serious, server-related problems (such as non-existing tag names, data type conversion problems etc.) are reported by error code.
QuickOPC does *never* modify the Quality provided by the OPC server, nor does it ever “add” values with its own quality.
QuickOPC does turn error codes (from OPC Server or from the operating system – such as DCOM/RPC – remoting errors) into Exceptions, and adds some error codes of its own, for issues that are detected on the client side.
I am explaining this so that you make your code robust also with respect to Qualities (Bad Quality still means “no error” as far as Exceptions are concerned – it’s just a different “state” of an item).
Typically, if there is a communication problem to the PLC, even though the PLC might be fully inaccessible, the problem does not manifest immediately for all items at once. This is because the different items might be accessed by separate messages over the time, so only the messages that fail at the moment change the Quality to “Bad” (or cause the error). So, even in cases such as broken cable to PLC, there is no guarantee that all things will “fail” simultaneously.
Similar thing, though to a lesser degree, happens in other situations, too. It is true that when we detect a “global” OPC server failure, we send notifications (with Exception != null) about it to ALL currently subscribed items, but that’s just one case; in other cases the errors might not affect all items.
QuickOPC works on the “item” level, so accessing the “global” status of the server is not directly possible, but this is by design, because I have explained, there is a limited use to that “global” status.
I understand what you are trying to achieve. I think that if you have operation that take a set of values as an input, and require those values be available, your code can do a logical “AND” and test whether *all” inputs are in a “good shape” for the operation. If they are, that would be an equivalent of “(global) status is OK”. Otherwise, you can treat it as “(global) status is not OK”.
I hope this helps.
Zbynek Zahradnik, OPC Labs
From: P.
Sent: Thursday, March 29, 2012 4:48 PM
To: Zbynek Zahradnik
Subject: Actions on comms failure
Zbynek
As you will be aware, my application is only using 30 variables so I am able to code on a variable by variable basis for readability. Here is a section of code contained in the public void opcDAClient_PlcDataChanged(object sender, EasyDAMultipleItemsChangedEventArgs es) event handler.
This works fine if the exception is specific to the signal concerned, but if the problem is more general, i.e the PLC is turned off or there is a problem with the opc server then the if statement resolves false and none of the code runs and so I am unable to set the status false. Is there a higher-level exception I could monitor for a global comms problem, or is there a better way altogether?
if (plcDataItem.ItemDescriptor == "SIMATIC 300 Station.CPU 317-2 PNDP(1).PLC TO BCS CONTROL.readyToReceive")
{
if (plcDataItem.Exception == null)
{
readyToReceive = Convert.ToBoolean(plcDataItem.Vtq.Value);
readyToReceiveStatus = true;
OnChangeReadyToReceive(EventArgs.Empty); // Raise PLC Data Change Event to allow clients to act upon it
}
else
{
readyToReceive = false;
readyToReceiveStatus = false;
}
}
Regards
P.
