LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

multiple call library function nodes with different paths

Solved!
Go to solution

Hello out there,

I'm using a DLL to connect to a camera. Now I try to connect to two cameras simultaneously, but unfortunatly the DLL can only handle one.

 

Now I have a workaround succesfully implemented:

  • Created two copies of the DLL A and B
  • Created two Libs A and B with Wrapper VIs which call the functions of the DLL, one points to DLL A the other to DLL B
  • Created a Test.vi where I can connect to both cameras and call getImage() in a loop

Well, that is not nice. I want that to be more dynamic. I don't want to have multiple librarys which do the exact same job, but are only linked to different DLLs. So I

  • Created new Lib D
  • There the Wrapper VIs which call the functions of the DLL have a path input for the Call Library Function Nodes
  • in the CLFN there is no name or path specified
  • Created two copies of the DLL A and B in Lib D Folder
  • Created a Test.vi which crashes Labview 😕
  • Here I bundle the paths to both DLLs in an array and iterate them in a loop

 

DllPath.PNG

 

 

The first iteration of the loop is okay, but in the second LV dies, it just dissapears or hangs forever. As the paths are correct and the first approach is working, it seems to me, that it is not a DLL-Problem, but a LV one. Like caching or something...

On the other Hand: When I call a Terminate() in the first iteration, the second iteration works fine. So maybe an issue with simultaneity? But all VIs are configured to execute non-reentrant, CLFN run in UI-Thread. So everything should run sequential.

 

Any hints or suggestions?

 

Using LV 2019.0f2 (64bit)


Proud developer at Hampel Software Engineering where we turn '404 not found' into '200 OK'. Join us on Discord
0 Kudos
Message 1 of 9
(3,721 Views)

Most likely your DLL doesn't like to be unloaded while having resources opened. And there is nothing you can do about that other than making sure that every resource is properly closed before you initiate a new loop with a different DLL name. Every Call Library Node will check the incoming path and if different to the previous, free the library handle and load the new library.

Once no Call Library Node has a handle left to a library Windows will unload it and if the library is not diligent about properly cleaning up on unload it can crash.

So if this is the problem with your library you will need at some point in your program a call library node for each DLL that is holding a reference to the individual DLL.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 9
(3,690 Views)

Hello rolfk,

 

thanks for your response.

 

@rolfk wrote:

And there is nothing you can do about that other than making sure that every resource is properly closed before you initiate a new loop with a different DLL name.

 

As I need to have a connection to both cameras at the same time, I cannot close the connection with the Terminate() function call.

 


@rolfk wrote:

Every Call Library Node will check the incoming path and if different to the previous, free the library handle and load the new library.

Once no Call Library Node has a handle left to a library Windows will unload it and if the library is not diligent about properly cleaning up on unload it can crash.

So if this is the problem with your library you will need at some point in your program a call library node for each DLL that is holding a reference to the individual DLL.


I don't know if I understood that right. Is there a way of getting a reference to the library handle out of the CLFN? Then I could use it later on...

I only have the path to the DLL. The DLL itself doesn't offer me a reference to a specific camera.

 

How can I prevent the CLFN to free the library handle?


Proud developer at Hampel Software Engineering where we turn '404 not found' into '200 OK'. Join us on Discord
0 Kudos
Message 3 of 9
(3,679 Views)
Solution
Accepted by AlexElb

The reference is held by each Call Library Node instance. That is why it works in your first case since you have for each camera individual VI instances that hold onto the DLL handle.

 

Just make sure you have at some point in your program before you do any dynamic camera calls, a call to some function in your DLL with an individual VI for each DLL name.

Rolf Kalbermatter
My Blog
Message 4 of 9
(3,670 Views)

@rolfk wrote:

Just make sure you have at some point in your program before you do any dynamic camera calls, a call to some function in your DLL with an individual VI for each DLL name.


Wow, easy solution: I've build a InitLibD Vi which calls DLL A and B with two CLFN statically binded and called that at the beginning.

Thank you very much for the quick help!


Proud developer at Hampel Software Engineering where we turn '404 not found' into '200 OK'. Join us on Discord
0 Kudos
Message 5 of 9
(3,659 Views)

@rolfk wrote:

Once no Call Library Node has a handle left to a library Windows will unload it


 

Just a short update: After loading was sucessfull, I had to reread this 🙂 Since I use the same Wrapper VIs for different DLL-calls I cannot unload them individually. Because every wrapper VI could have a handle left, I must call them all with an empty path to unload the DLL.

 

UnloadUnload

 

The lower Picture shows the VI used to load and unload multiple DLLs.

With the Load Action it will pass two DLL Paths into two CLFN.

Then in my programm all wrapper VIs can be uses with one of thwose DLL Paths. LV won't unload the DLL because the two CLFN in the lower picture still hold a handle to the dll.

When my programm wants to unload all DLLs it calls that VI with the Unload Action, which first calls the VI in the upper picture:

All wrapper VIs are called with an emtpy path, so that none CLFN in them has a handle to the DLL.

Finally the two CLFN which initially loaded the DLL get called with an empty path, so no CLFN with a handle to the DLLs is left and it will be unloaded.

 

I thought I document here some more information because it was a bit tricky, at least for me. May be interesting for other users, too?

 

Other solutions welcome 🙂 It would be nice to load and unload one dll without interfering with the others, but I don't see that to be possible...?