10-15-2021 06:39 AM - edited 10-15-2021 06:46 AM
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
Solved! Go to Solution.
10-15-2021 07:40 AM - edited 10-15-2021 07:43 AM
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
10-15-2021 07:56 AM
Brilliant DHerron !
That solved it.
Thanks !
Kaare
10-15-2021 08:00 AM
@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
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.
10-17-2021 08:43 PM
@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)
10-18-2021 02:40 AM
@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.