R.,

in general, it can be any exception (System.Exception or anything derived from it) – the user’s code shouldn’t rely on it much. Internally, it is a COM (or OPC, or our own) error code (HRESULT) transformed to .NET exception using Marshal.GetExceptionForHR method (<a href="msdn.microsoft.com/en-us/library/3xade62s(v=VS.90).aspx?appI...(TargetOS-WINDOWS)&rd=true ). Typically (for most errors), this will be System.Runtime.InteropServices.COMException, but some specific error codes will be transformed by .NET to different exception classes.


Just for information, there may be roughly three sources of these errors:
- The target OPC server may report an error in the method call or callback. In this case, the code in the exception will contain the HRESULT returned by the OPC server, without any change; and it will be one of the errors documented in the OPC specification, or vendor-specific error.
- We may encounter an error while calling some of the support COM functions, such as trying to convert the received VARIANT value. In this case, whatever HRESULT the Windows API function returns, will be contained in the exception.
- Or, we may detect a problem that does not have a precise error code anywhere else: In such cases, we have own HRESULTs for these. For example, if the target OPC server is going through orderly shutdown, we will return 0xC0049006 inside the exception, but there are many other codes likes this.

Best regards,
Zbynek Zahradnik

From: R.
Sent: Tuesday, January 25, 2011 6:29 PM
To: Zbynek Zahradnik
Subject: RE: x64 .dll issues

Zbynek,

Thanks for this information. That is what I assumed was the issue after you asked about whether he was checking the exception. I’ve explained that to him, so I think he has adjusted his code accordingly. Are these COM exceptions that are being returned? Or OPC exceptions?

R.

R.,

....., all that is observed is expected behavior. The code in properly written event handler should have the logic similar to this (taken from ConsoleEvents example):

static void client_ItemChanged(object sender, EasyDAItemChangedEventArgs e)
{
if (e.Exception != null)
Console.WriteLine(e.Exception);
else
Console.WriteLine(e.Vtq.ToString());
}

The rules are:

· When e.Exception is not null, it contains the information about problem encountered with that item – which may, among many other things, be that the target server was shut down. The exception information is directly in the object (e.Exception) – there is no need for try/catch. VTQ is not valid and is actually null, when e.Exception is not null; this is why the customer his getting the exception he doesn’t want, because he is accessing the VTQ without checking e.Exception first.

· When e.Exception is null, VTQ is always present (is never null), and accessing its properties should give no exceptions, so yet again, try/catch is not needed.

The user’s guide (Concepts) contains following text which says basically the same:

For further processing, your code should always inspect the value of Exception property of the event arguments. If this property is set to a null reference, the notification carries an actual change in item’s data, and the Vtq property has the new value, timestamp and quality of the item, in form of DAVtq object. If the Exception property is not a null reference, there has been an error related to the item, and the Vtq property is not valid. In such case, the Exception property contains information about the problem.
Other documentation related to this is here:
- www.opclabs.com/onlinedocs/Qui...
- www.opclabs.com/onlinedocs/Qui...

The try/catch is only needed around method calls to the EasyDAClient – and even then, only around those that do not have the word “Multiple” in their names, because those return exceptions in a result array.

The bottom line is that the event handles the customer has should be rewritten to follow these rules. I can help with it if needed.

Best regards,
Zbynek Zahradnik

From: R.
Sent: Monday, January 24, 2011 8:36 PM
To: Zbynek Zahradnik
Subject: RE: x64 .dll issues
Zbynek,
....


He is not checking the exception. I explained to him that he needs to check this before checking the VTQ. He does not have the PLC anymore to test with to see what the exception is, but he thinks he can simulate it by shutting down the TOP Server (this at least gives the same null reference in his code- but it doesn’t guarantee the Exception or the cause is the same). I have attached a .txt file with his callback routine. Also below is a sample of the debugging log he is creating. You can see that at 9:38 everything works fine (he gets his “About to test tag” and “Attempt to read ItemID” debug messages) but when he tries again later at 10:44 he gets the error.

1/23/2011 9:24:13 AM, USPLATCONV01/iccs1, Assigned, Container = ?, Route = (NO READ), Lane Assigned = 2, Reason = Only Lane for Route ID
1/23/2011 9:24:13 AM, USPLATCONV01/iccs1, Weight Check, Container = ?, Actual = 1.98, Lower Limit = 0, Upper Limit = 10, Pass or Fail = P
1/23/2011 9:24:13 AM, USPLATCONV01/iccs1, Scan, Container = ?, Psuedo ID = 6004, Sequence Number = 4
1/23/2011 9:24:13 AM, USPLATCONV01/iccs1, Assigned, Container = ?, Route = (NO READ)(NO LANE ASSIGNED), Lane Assigned = 0, Reason = No Lane Assigned for Destination
1/23/2011 9:38:23 AM, USPLATCONV01/iccs1, In OPC Change
1/23/2011 9:38:23 AM, USPLATCONV01/iccs1, About to test tag
1/23/2011 9:38:23 AM, USPLATCONV01/iccs1, Attempt to read ItemID
1/23/2011 9:38:23 AM, USPLATCONV01/iccs1, tag = CPA.CPA.DataSeq05
1/23/2011 9:38:23 AM, USPLATCONV01/iccs1, Attempt to read Value
1/23/2011 9:38:23 AM, USPLATCONV01/iccs1, seq = 10
1/23/2011 9:38:24 AM, USPLATCONV01/iccs1, Scan, Container = C34498080, Psuedo ID = 5010, Sequence Number = 10
1/23/2011 9:38:24 AM, USPLATCONV01/iccs1, Assigned, Container = C34498080, Route = ROUND ROBIN 1, Lane Assigned = 3, Reason = Round Robin Lane for Route ID
1/23/2011 9:38:24 AM, USPLATCONV01/iccs1, Weight Check, Container = C34498080, Actual = 7.28, Lower Limit = 0, Upper Limit = 10, Pass or Fail = P
1/23/2011 10:44:52 AM, USPLATCONV01/iccs1, In OPC Change
1/23/2011 10:44:52 AM, USPLATCONV01/iccs1, About to test tag
1/23/2011 10:44:52 AM, USPLATCONV01/iccs1, OPC_Tag_Subscription_Changed - Error reading tag information - Part 1
1/23/2011 10:44:52 AM, USPLATCONV01/iccs1, System.NullReferenceException: Object reference not set to an instance of an object.
at MDCSTaperSortationService.MDCSSortationControl.OPC_Tag_Subscription_Changed(Object sender, EasyDAItemChangedEventArgs updatedItem)

R.

R.,
to the second problem, can you give me some more information?

- Is it possible to reference the VTQ itself, or its other parts? I.e. is it really just the Quality piece of it?
- Is the code inside ItemChanged event handler (I think that’s what you mean by “on the ValueChanged event”) checking the Exception property of the received “event arguments”? If the Exception is non-null, VTQ is null then. Can he send us that piece of code?

MaxTopicAge default value is 1 second, ServerShutdownReconnectDelay default value is 1 minute.

I do not fully understand that part of your question, though. MaxTopicAge really comes to effect only if the app code reads OPC item values but does not subscribe. If you subscribe, then until you unsubscribe, the component does not disconnect from that item on its own, no matter what’s in MaxTopicAge. Of course if the server goes down or even asks the clients to disconnect (which is when the ServerShutdownReconnectDelay comes to effect), then a disconnection from that item does occur – but is later automatically reconnected “behind the scenes”. In case of problems like this, ItemChanged is called with Exception set non-null (and VTQ to null). We never “stuff in” any Quality (good or bad) of our own into a VTQ; if a VTQ is not available, the indication of the problem is in the Exception.

One final note: Referencing x64 assemblies should work, but you won’t be able to use them from the toolbox – that’s Visual Studio limitation.

Zbynek Zahradnik

From: R.
Sent: Monday, January 24, 2011 5:33 PM
To: Zbynek Zahradnik
Subject: x64 .dll issues

Hello Zbynek,

[...the customer is using the x64 .dlls]

.....

What are the default values of the MaxTopicAge and the ServerShutdownReconnect Delay? If we hit the MaxTopicAge and we release a connection to an item that is subscribed, do we have to subscribe to that item again to start receiving callback again?
a. The problem the customer is seeing is that he is getting a null reference exception that is being caught by the general try…catch, ( and not by the Data.NET) on the ValueChanged event after a period of inactivity (the subscribed value does not change for 20 minutes or so).
b. We seem to have narrowed it down to the Quality of the VTQ. He has tracing implemented after every line and he gets to:
If VTQ.quality.isgood then....
, but he never gets passed that and it goes into the exception routine. It doesn’t seem to go into the else statement either.

I was going to try to reproduce this issue, but my VS keeps crashing on me whenever I try to add a reference or add something to the toolbox (I have to get that figured out first).
.....

Thanks in advance,
R.