LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL call slows down user interface

Solved!
Go to solution

Hi

 

I am working on a simple temperature DAQ application, using the pico TC-08 8-channel temperature device. Through USB.

I use the pico .dll to setup and read the channels.

This works, so far so good.

 

But when I run this in a loop, where I wait 1 second between reading the channels, the front panel controls are slowed down significantly.

All user interface seems to be ignored as long as the dll is working on the measurements.

I.e. when I click increment or decrement buttons on a numeric control, there is significant delay.

 

Screenshot of test app is attached.

 

The question is:

Why does the dll call make the user interface slow?

 

br

Kaare

0 Kudos
Message 1 of 6
(241 Views)
Solution
Accepted by KaareBK

That dark orange background of the call library function node (CLFN) says to me that the dll is running in the UI thread, which would slow down the rest of your front panel. Open the CLFN and configure it to run in any thread

 

thread_help.png

 

clfn_config.png

Message 2 of 6
(220 Views)

Brilliant DHerron !

That solved it.

 

Thanks !

Kaare

0 Kudos
Message 3 of 6
(211 Views)

@DHerron wrote:

That dark orange background of the call library function node (CLFN) says to me that the dll is running in the UI thread, which would slow down the rest of your front panel. Open the CLFN and configure it to run in any thread

 

thread_help.png

 

clfn_config.png


I feel we would be remiss if we didn't stress the caveat about being called from multiple places.  DLLs run in the UI thread by default so all calls are serialized.  Since dlls usually don't usually expect to be called from different places at the same time, you have to make sure it's okay to do so, and by running the dlls in the UI thread, this is guaranteed.

So how do you know if it's thread safe?  Usually, not even the dll provider knows, so it's usually about just doing it and watching for strange behavior or even crashes.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 4 of 6
(206 Views)

@billko wrote:

...by running the dlls in the UI thread, this is guaranteed.

So how do you know if it's thread safe?  Usually, not even the dll provider knows


It would be nice if LabVIEW supports creating a dedicated (non-UI) thread for calling a particular DLL's functions.

 

A well-designed library should document which functions are thread-safe and which aren't. (Unfortunately, not all publicly-available DLLs are well-designed)

Certified LabVIEW Developer
0 Kudos
Message 5 of 6
(113 Views)

@JKSH wrote:

It would be nice if LabVIEW supports creating a dedicated (non-UI) thread for calling a particular DLL's functions.

 

A well-designed library should document which functions are thread-safe and which aren't. (Unfortunately, not all publicly-available DLLs are well-designed)


 

Open an idea on the idea exchange.

0 Kudos
Message 6 of 6
(93 Views)