LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview freezes when running subvi in an event structure

I have an event structure inside a while loop in which I talk to a camera using a few Call Library Function nodes. The  subvi examples are here: https://forums.ni.com/t5/LabVIEW/PICAM-SDK-Call-Library-Function-crashes-LV/td-p/3742188/highlight/t...

 

They call library functions inside a dll file.

 

When the subvi for talking to the camera runs, my whole Labview program freezes until the process finishes. Is this to be expected? I don't seem to be able to run two VIs concurrently in this way. I have unchecked the "lock panel" setting in the even case.

 

thanks for your help!

0 Kudos
Message 1 of 5
(1,205 Views)

Hi niforlinuc,

 


@niforlinuc wrote:

When the subvi for talking to the camera runs, my whole Labview program freezes until the process finishes.

Is this to be expected?


Yes.

When the function you call inside the DLL is busy and does not return to LabVIEW then there is no way for LabVIEW to proceed...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 5
(1,199 Views)

Thanks, your answer actually pointed me towards finding a solution

0 Kudos
Message 3 of 5
(1,174 Views)

@niforlinuc wrote:

I have an event structure inside a while loop in which I talk to a camera using a few Call Library Function nodes. The  subvi examples are here: https://forums.ni.com/t5/LabVIEW/PICAM-SDK-Call-Library-Function-crashes-LV/td-p/3742188/highlight/t...

 

They call library functions inside a dll file.

 

When the subvi for talking to the camera runs, my whole Labview program freezes until the process finishes. Is this to be expected? I don't seem to be able to run two VIs concurrently in this way. I have unchecked the "lock panel" setting in the even case.

 

thanks for your help!


This is a typical example of when you want a producer/consumer to offload the event loop or use Asynchronos call. Changing your DLLs as you did might work, assuming the DLL is thread safe ...

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 5
(1,159 Views)

@niforlinuc wrote:

Thanks, your answer actually pointed me towards finding a solution

Note that this may not be the solution but only a workaround that could break at some point! Changing the Call Library Node to run in any thread requires the DLL function that is called to be thread safe. If a function is thread safe or not can only be decided by the developer or someone with access to the DLL source code. So if your DLL Documentation doesn’t say anywhere that its functions are multithreading safe, it is a VERY safe assumption that the developer never really thought about it and that it very likely may not be safe. In that case setting the Call Library Node to call in any thread is similar to playing Russian Roulette. It may seem to go well for some time but suddenly your program crashes or starts to have strange behavior, and this usually always happens when the production system your application is used in needs to provide results yesterday and everybody is breathing down your neck to make it work now, not in a week and not tomorrow but right NOW!

Rolf Kalbermatter
My Blog
Message 5 of 5
(1,116 Views)