Losing .net references after an error

[enzofurlan]

Hi,

I would like to know if it s possible to keep a .net reference opened after occurring an error in Labview. Or, how to make labview not delete them all after an error. Or even so, maybe I am not understanding the "lifetime" of a .net reference in labview. But the problem is that I am not being able to use the same reference after an error.

Thanks in advance.

[aputman]

Can you share the code snippet?  It will be hard to help you without it. 

[enzofurlan]

hi aputman, thanks for your response,

my code is based on several VIs being called in TestStand with the aim of communicating with a device. So I have a vi to connect, then I save its reference and pass it to a "get.vi" to get information from the device, then its reference is passed to another "get.vi" to get another information, and finally its reference is passed to a disconnection vi to end the program. If I get no error, the program works flawlessly. The problem is that if I get an error such as timeout or a bad connection (they can occur) in the first "get.vi", it seems that Labview simply "erase" all my references and the next "get.vi" wont work obviously. So I just wondered if it's possible to make this work as a "Try Catch" in C#, or I am open to new solutions.

[aputman]

Well, if there is a bad connection or a timeout, the reference was never created and the subsequent VIs are going to fail without it.  That's the purpose of error handling routines.  There is a template in the "New..." menu for creating a subVI with Error Handling.  I would recommend using it for your subVIs so that they gracefully exit upon receiving an incoming error.  

For your connection code, try putting it in a while loop.  If you get a timeout or a "no connection" error, repeat the loop.  Check the number of times that the loop repeats and after a pre-determined number of retries (stored as an INI setting??), flash an error message to the user and exit.  

There are lots of ways to handle these scenarios but it all depends on your preference as the developer or your customer's preference, if you are developing a solution for their business.  

[tyk007]

To add to aputman's reply - make sure your VIs transfer the reference to the output terminal on all conditions, even on error.

Many people on the forums have gotten what you are describing to work. If you are still having trouble post your TestStand sequence file and your VIs (zip it) so that we can help you find the problem. 

[enzofurlan]

Hey,

1. The timeout can be thrown getting the data, so it s not always a connection fault. Well, I am not quite sure if I know how to use this "error case" structure, do you have a simple example? I mean, if I get the error, could I just pass it away, keep my references and properly keep my code running?

2. Yes, I got a loop for the connection vi, the problem is, after connected, if I get a new error getting the data, I cant get my references, cause they are all gone. I cant even close its COM port, to retry connecting again.

I appreciate your help!

[enzofurlan]

Hey tyk007, great to see you again! Thanks!

Mate, I guess it s not an input/output terminal problem, but just guessing. What do you mean by passing even on error? Is there a labview configuration that disable passing my reference when an error occur? Because I am assuming that Labview is erasing my references, but if it isn t that changes all. Could you explain?

Also, could you point me some of these topics describing the same problem? I searched a lot before posting here. And I really cant post my code here, maybe I can figure out a similar example.

[tyk007]

The reference, as far as the majority of LabVIEW is concerned, is just a number (32-bit or 64-bit depending on your environment and some other factors). It only has meaning when its used. So, as far as your VIs are concerned, you need to pass that "number" through all of your VIs by way of a wire . If, at any point, that number is the default value (aka 0) then this is an invalid reference (I assume that this is the error you are receiving). LabVIEW will automatically release your references when the top-level VI goes idle - you can control this by calling the Close Reference node yourself (as you should be doing in your close/dispose VI). In your case I assume you are using a local variable in your TestStand sequence (Object Reference type) as storage to pass data between your VIs.

I suggest following the standard format for writing VIs that work on references:

• Connector Pane: Input control and output terminal for the Reference (eg. "Reference in", "Reference out")
• Connector Pane: Input control and output terminal for Error clusters (eg. "Error in", "Error out")
• Block Diagram: An Error Case. In the case of No incoming error then perform the operations you want on the reference, passing the wire back out of the case when you re done. In the case of an incoming error then simply pass the error and reference wires back out again to the output terminals

Note that VIs that must execute even on error (such as Close, Dispose etc. style VIs) should follow a different form to ensure that references are always closed even on error.

Otherwise we really need to see some code! Even a subset that demonstrates your issue would help.

[gabrielhabib]

Guys, in his case, the problem is because the .NET resource we uses into his VI are returning .NET exceptions.

SerialPortException

TimeoutException

and so on, as a result, the labview just crashes at all.

[tyk007]

OK, thanks for the information. Catching exceptions and wrapping them into an error cluster with code 1172 is perfectly normal LabVIEW behavior. Can you describe in more detail how this relates to the OP's original question "Lose .Net references after an error"? Are .NET references actually "lost" and what is meant by that?

And to re-iterate - we're shooting in the dark without something (code) to go on. Perhaps you can replicate an example - if you control the contents of the assembly perhaps a method call that always throws an exception to simulate the condition.