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,733 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,702 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,691 Views)
Solution
Accepted by topic author 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,682 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,671 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.

<