LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

should a dot net Invoke node fill the error cluster?

Solved!
Go to solution

Situation, a dll called by LabVIEW attempts to communicate with an instrument and can not because the instrument is not present.  The DLL returns a standard LabVIEW error cluster with no error.

Person A says this is wrong : it must return an error.  Further modules in the chain can not succeed with no communication. And that it is possible to return an error by throwing an exception.

Person B says : The program ran and did not die.  This is our module not a LabView function.  The error cluster should return no error.  And that it can not return an error either,

The questions are Who is right A or B? And , since is has already gotten to a ‘is to, is not’ kind of disagreement, Where is any supporting documentation to reference that will authoritatively resolve the issue?

0 Kudos
Message 1 of 5
(2,624 Views)
Solution
Accepted by topic author Chas2003

In order for the dll to produce an error in LabVIEW, it must be programmed to throw an exception if no instrument is available.  LabVIEW will then convert this exception into a generic error with code 1172 (see attached article.)  LabVIEW can be programmed to give a custom error message using the attached example.  In this case, it should be possible to have the .NET dll throw an exception, and then have LabVIEW generate a custom error message to display to the user.  In this instance, it appears that Person A is correct.  Hope this helps resolve the issue.  

LabVIEW and .NET Exceptions

http://digital.ni.com/public.nsf/allkb/B15CE9F2715434C386256D3500601878

 

Programmatically Generate Custom Error Codes/Messages

https://decibel.ni.com/content/docs/DOC-9557

Regards,

Chris L
Applications Engineer
National Instruments

Certified LabVIEW Associate Developer
Message 2 of 5
(2,610 Views)

Thanks , That makes me happy since I am person A .  I didn't want to predjudice you <G>.

0 Kudos
Message 3 of 5
(2,604 Views)

If the exception code for DLL errors is always 1172, how do you determine what error occured (and thus how to handle it)? I understand how to create handling for specific codes, but what do you do when the error code is always 1172? Is there a way for the DLL to give specific codes for various exceptions? This would be ideal, since I could then just key off of those codes. I do get different string outputs from the different exceptions, but those are a little cumbersome to try and create error handling around.

 

For example, one error output message I get from the exception (from the DLL) with error code 1172 is the following:

Error calling method CPS.Engines.LoCom.LoComEngine.ExecuteNVR, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 Inner Exception: CPS.Engines.CPSProtocolTimeoutException: Exception of type 'CPS.Engines.CPSProtocolTimeoutException' was thrown.) <append><b>CPS.Engines.CPSProtocolTimeoutException</b> in SendReceiveLoCom.vi->LoComMsg.vi

 

Obviously this has a lot of stuff specific to the DLL, but it would be a little ugly to try and create error handling based on those messages. Is there a simpler way?

0 Kudos
Message 4 of 5
(2,562 Views)

No there isn't a way for the Invoke node to return a different error code when an exception occurres. For one exceptions are not some standard entity that LabVIEW could fully decode as every programmer is free to subclass the generic exception and create as many application specific exception types as he likes. And I believe the error text in the returned error string does actually include the exception cause, albeit in a textual form of course.

 

Prefered way for a .Net node would be to use one of its parameters to indicate an error and possibly the exact error cause. If it howerver only does so by throwing an exception, all LabVIEW can do is return a specific error code for the fact that the call resulted in an exception and also add the exception cause text to the error string. Of course this assumes that the function added some useful cause to the exception. Failing both, LabVIEW can't perform magic. In that case you have to simply take the 1172 error and deduce yourself from the location (node) where it happened, what went wrong.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(2,557 Views)