LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Keeping a Call Library Function open that is called within SubVI's

Solved!
Go to solution

Hello --

 

I've had great success with LabView thus far for the 1/4 of a year I've been using it, up until this point.

 

What I'm trying to accomplish is communication to an external serial COM Port instrument, using DLL Call Library Function nodes, accessed through SubVI's.

 

The DLL contains many functions that facilitate ease of communication with the external instrument. A call to an initialization function is the first function call to use that loads the library into memory. Once the init function is successful, you may begin using the other functions in the library.

 

When calling the DLL initialization function and the subsequent control/comm functions work just fine when everything is called within the same VI.

 

However, when I try and call the initialize library when it's inside a SubVI, then called from a MainVI, the library is not staying in memory. The instrument's error buffer tells me the library isn't loaded when done this way.

 

I've tried making an asynchronous call to the SubVI at the start of the MainVI through static VI reference, without success.

 

I'm attaching a very simplified example of what I'm doing. Any hints or tips on this matter would be much appreciated.

 

Thanks

Regards,

Keith

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

You suspicion that LabVIEW would not keep the DLL loaded after it's called is completely unfounded. That's NOT how LabVIEW works, so there must be something else wrong. If you specify the path to the DLL in the Call Library Node itself, the DLL is loaded as soon as that VI is loaded into memory and only unloaded after the last VI containing a Call Library Node is unloaded.

 

But looking at pictures for debugging Call Library Node problems really is not a good way. So next time add a ZIP file with your VIs instead, preferably backsaved to LabVIEW 2016 or earlier.

Rolf Kalbermatter
My Blog
Message 2 of 5
(2,149 Views)

I can confirm that what you show in your images should work. I have done it several times.

 

One possible issue might occur when you call the DLL using "run in any thread" instead of "run in UI thread" but your images show that you make the call using the UI thread.

 

One issue that occur when running in the UI thread is that this thread get interrupted all the time. It might be an issue with video transmission for example.

 

Are you sure that you have the same problem with the code of the images you provided?

Marc Dubois
0 Kudos
Message 3 of 5
(2,131 Views)

Well, I 100% expected some abrasiveness.. Didn't expect to have my issue solved by the first person to reply. 🙂

 

Anyway your mention of "specify the path" made me try the "Specify path on block diagram" option, and tie in all the paths in and paths out inside the Main VI. Voila.. it works now.

 

I had incorrectly assumed it would just work by specifying the path only in the node configuration. Passing the path along down the line seems to keep my library open.

 

Thanks for pointing me in the right direction! In the future, if I need further assistance, I'll be sure to follow your advice on what to include in my post and how to include it.

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

This may seem like the solution but there must be something else going on. While specifying the path like that willl make a small difference it will not unload the DLL at anytime just like the other one. The only difference will be that the DLL is loaded at the first call to a Call Library Node referencing it, instead of as soon as the first VI is loaded.

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