From: Zbynek Zahradnik
Sent: Wednesday, March 21, 2012 11:58 AM
To: .....
Subject: RE: CS713A - OPC Code Check

Hello,

Please see my answers below interspersed in your email text. In addition, please read the excerpt below from the “Concepts” document.





Error Handling


Various kinds of errors may be returned by QuickOPC, e.g.:

· Errors returned by system calls when performing OPC-related operations.

· Errors returned by COM/DCOM infrastructure, including RPC and network-related errors.

· Errors reported by the OPC server you are connecting to.

· Errors detected by the QuickOPC library.

In general, you cannot safely prevent these errors from happening. Many conditions external to your code can cause OPC failures, e.g. network problems, improper OPC server configuration, etc. For this reason, you should always expect than OPC operation can fail.



QuickOPC.NET defines one new type of exception, called OpcException, derived from Exception object. This exception is for all errors arising from OPC operations.

More details about the cause of the problem can be found by interrogating the InnerException property of OpcException, or by examining the ErrorCode property. In most scenarios, however, your code will be handling all OpcException-s in the same way.



If you need to display a meaningful error message to the user, or log it for further diagnostics, it is best to take the OpcException instance, obtain its base exception using GetBaseException method, and retrieve its Message property. The error message obtained in this way is closest to the actual cause of the problem. QuickOPC.NET even tries to fill in the error text in cases when the system or OPC server has not provided it.

It should be noted that for QuickOPC.NET operations, OpcException is the ONLY exception class that your code should be explicitly catching when calling QuickOPC methods or getting properties. This is because you cannot safely influence or predict whether the exception will or will not be thrown. Other kinds of exception, such as those related to argument checking, should NOT be caught by typical application code, because they either indicate a programming bug in your code, or an irrecoverable system problem.


Errors and Multiple-Element Operations


Some methods on the main EasyDAClient object operate on multiple elements (such as OPC items) at once, and they also return results individually for each of the input elements. Such methods cannot simply throw an exception when there is a problem with processing one of the elements, because throwing an exception would make it impossible to further process other elements that are not causing errors. In addition, exception handling is very slow, and we need some efficient mechanism for dealing with situations when there may be multiple errors occurring at once.

For this reason, methods that work on multiple elements return an array of results, and each result may have an Exception associated with it. If this exception is a null reference, then there has been no error processing the operation on the element, and other data contained in the result object is valid. When the exception is not a null reference, it contains the actual error.

For multiple-element operations, the element-level exceptions are not wrapped in OpcException, because there is no need for you to distinguish them from other exception types in the catch statement. If there is an exception inside a multiple-level operation, it is always an exception related to OPC operations. The Exception property of the result object in a multiple-element operation therefore contains what would be the InnerException of the OpcException thrown for a single-element operation.

Exceptions that are not related to OPC operations, such as argument-checking exceptions, are still thrown directly from the multiple-element operations, i.e. they are not returned in the OperationResult object.


Errors in Subscriptions


Similarly as with multiple-element operations (above), errors in subscriptions are reported to your code by means of an Exception property in the event arguments passed to your event handler or callback method. If this exception is a null reference, then there has been no error related to the event notification, and other data contained in the event arguments object is valid. When the exception is not a null reference, it contains the actual error.

In event notifications, the exceptions are not wrapped in OpcException, because there is no need for you to distinguish them from other exception types in the catch statement. If there is an exception related to the event notification, it is always an exception related to OPC operations.






VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV – see more info further below -- VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV



Best regards,

Zbynek Zahradnik, OPC Labs



From: .....
Sent: Tuesday, March 20, 2012 8:05 PM
To: Zbynek Zahradnik
Subject: RE: CS713A - OPC Code Check



Zbynek



In your reply to my email you added two points under “Other Observations”. I have a few questions …



1. Currently, when I am writing multiple values, I am using a try – catch approach with the catch reporting exceptions using



catch (OpcException opcError).





a) You are suggesting that I should be texting for exceptions on each result array. Can you give me an example or point me to an existing one?



I do not have a precise example available at the moment, but you can kind of get the idea from the example listed here: www.opclabs.com/onlinedocs/QuickOpcClassic/5.12/Reference/Qu...ba1-3a7e-4b61-5ae487b6816c.htm (same approach work for reading or writing).




// Perform the OPC read

87 DAVtqResult[] vtqResults = easyDAClient.ReadMultipleItems("OPCLabs.KitServer.2", itemDescriptors);

88

89 // Count successful results

90 int successCount = 0;

91 for (int iItem = 0; iItem < TotalItems; iItem++)

92 if (vtqResults[iItem].Succeeded) successCount++;




Here is tests the .Succeeded property, which is just a shortcut for testing whether Exception == null.

If you need better example, let me know and I’ll create one.



b) What is the difference between doing this and the way I am doing it now?



The way you are doing it now will not catch anything, because methods that work with multiple items do not throw OpcException.





2. When I am reading values using the item_changed event I am using the catch (OpcException opcError) approach.



a)You seem to be suggesting that I should be using the Exception Property of EasyDAItemChangedEventArgs object instead. What is the syntax for implementing that in a try-catch pair?



You do not catch it. Simply test whether it contains null. If it does, there was no error. If it is non-null, it then contains the actual error.



b) What is the difference between OpcException and the Exception property of the EasyDAItemChangedEventArgs property?



I think this is again explained above in the text from “Concepts”, under “Errors in Subscriptions”. OpcException is a class of exceptions; it is used in QuickOPC when exception are thrown, because at in such situations there may be other classes of exceptions thrown as well, so it is a good practice to reserve a class of exceptions for a particular purpose so that a “catch” clause can distinguish them. On the other hand, Exception property of EasyDAItemChangedEventsArgs contains either null (a success), or whatever error has happened related to the item the notification is about.





Regards



P.


From: Zbynek Zahradnik
Sent: 20 March 2012 08:17
To: .....
Subject: RE: CS713A - OPC Code Check



Hello.



1. Is this a good / safe way of coding things?



Yes in general. I suppose that MessageBox will not be used in your final code however, because that may cause the incoming notification to block for long time, until the user exits the dialog.



2. How can I read the 3-digit quality number without the text?



Get the InternalValue property of the DAQuality (www.opclabs.com/onlinedocs/QuickOpcClassic/5.12/Reference/Qu...f17-7241-c9ae-2f6d915a53d7.htm ). Also, have a look at other members of DAQuality (www.opclabs.com/onlinedocs/QuickOpcClassic/5.12/Reference/Qu...46b-3ac3-6283-a703012de6ac.htm ), there are useful methods such as IsBad(), IsGood() and others.



3. I am considering subscribing to the items at the start of the application, is this a problem / bad practice?



I think this is fine.





Other observations:





A. Error handling for WriteMultipleItemValues in lotData(): You should rather test for Exception property in each resultArray[] element.

B. Error handling in opcDAClient_ItemChanged: You should rather test for Exception property in EasyDAItemChangedEventArgsobject.





Regards

Zbynek Zahradnik, OPC Labs



From: .....
Sent: Monday, March 19, 2012 6:22 PM
To: Zbynek Zahradnik
Subject: CS713A - OPC Code Check



Zbynek



Could you have a quick look at the attached test code which is working. It consists of three methods, one to send 3 items to a local opc server (initiated from a form button click event), one to subscribe to those items (initiated from a form button click event) and a third to display a MessageBox when an item changes. I have a couple of questions:-



1. Is this a good / safe way of coding things?

2. How can I read the 3-digit quality number without the text?

3. I am considering subscribing to the items at the start of the application, is this a problem / bad practice?



Regards



P.