Best Practices for Calling .NET APIs from LabVIEW

[jncuevas]

Hello,

I am working with a .NET API in LabVIEW which I have done a few times, but this time I having trouble.  Specifically it seems that sometimes the Constructor Node freezes and the entire application has to be restarted.  Not only that, but the API process has to be closed in windows task manager.

So I have two questions:
1.  Is anyone aware of any best practices for calling .NET APIs from LabVIEW?  Examples, training, or documentation would all be welcome 🙂 

2.  What is a good way to put a timeout on the Constructor Node so that I can try to recover?

[Kyle97330]

Can you provide any information about what the constructor node is trying to do, and what level of control you have over it?

Specifically, do you know if the constructor node is likely trying to do one or more of the following?:

• Open a file
  • If so, is it a file on a network?
• Connect to a device
  • If so, what connection method?
• Connect to a remote server
• Interact with Windows services in some way
• Things that might require elevated permissions

And by "level of control", I mean:

• Is the constructor node one of the standard Microsoft ones?
• Is it from a DLL made by someone in your company?
• Is it from a DLL that's open source (from GitHub or similar)?
• Is it from a company that you might have some form of expectation of support (for instance, if it controls a device that costs a lot)?
• Does the node have any inputs that you can manipulate at all, or is it one of those that doesn't have any inputs?

[jncuevas]

Hello.  Thank you for the questions.

I have little to no control or influence over the API.  The device, a photometric camera, costs about $17,000, but we are a very small customer and the supplier is very large.  My experience has been that we are not a priority - to the point they didn't even know their most recent API would not work for our application and gave us a deprecated API at the eleventh hour.  

 I don't know what the constructor does other than create an instance for LabVIEW to use.  There is a separate Initialize method that connects to the device via TCP/IP and initialized the ,net object.

Considering the poor customer support from our supplier, I just want to find a way to catch it when the constructor freezes and restart things automatically.

[Kyle97330 · Accepted solution]

LabVIEW has very little agency when it comes to .NET calls if they don't behave.

First, are you using a somewhat modern version of LabVIEW?  If not, can you update to a newer one?  I don't specifically recall seeing much about .NET in patch notes, but LV 2025 introduces beta support for .NET Core (8), which might indicate potential internal changes.

Next, you could try changing the executing system the VI with the constructor node runs under.  Some .NET seems to behave differently when it's in the User Interface system:

There's a file that affects how .NET runs in an EXE, which in dev is either "LabVIEW.exe.config" if you don't have a project open or "Projectname.lvproj.config" if you do, or if you run an EXE it's "Appname.exe.config".  I don't know what exactly you might need to set in there, but there's bunches of options you could play with.  Do a few searches for the format (it's XML but needs specific nodes to do anything).  For some DLLs I have had to enable certain runtime versions or <loadFromRemoteSources enabled="true" /> or the like.

You could try to see if it's internally throwing exceptions but not exiting, by first registering for this event:

https://learn.microsoft.com/en-us/dotnet/api/system.appdomain.firstchanceexception?view=netframework...

That assumes you know how to use an event in .NET and create a callback VI that can log the exceptions.  Not super easy.  This wouldn't solve it BTW, it would just have a small chance to point you at a better definition of the problem.

Finally, the last thing I can think to try is that maybe you could run the constructor node in a reentrant VI that you run asynchronously which is set up to send the message back using a queue or something similar when it completes.  Then if you don't get a queue message within your timeout period, start up another reentrant instance to try again.  Might need to close the reference or abort the first one to get the next one to work, not sure.

[avogadro5]

---

Finally, the last thing I can think to try is that maybe you could run the constructor node in a reentrant VI that you run asynchronously which is set up to send the message back using a queue or something similar when it completes.  Then if you don't get a queue message within your timeout period, start up another reentrant instance to try again.  Might need to close the reference or abort the first one to get the next one to work, not sure.

---

You can also use "wait on asynchronous call" to get the output at the end. If you open a VI reference with "call and collect" enabled you can wait for the VI to finish with a timeout and then conveniently abort the VI by closing the reference.