Slow Front Panel update with Call Library Function Node (Pico USB TC-08) in Run in UI thread

[Magnus_C]

Hello, good people!

This is my first post on this site.

I'm using LabView 2015. I have a Pico USB TC-08 which I use in LabVIEW to get 4 thermocouple temperature readings that I use to control a system. I have provided a minimal working example (MWE) which only does the temperature reading, and a snippet of the slow part below (It is not working without a Pico USB TC-08, i guess, but i cannot make an example that runs without it without removing the relevant stuff). The code was provided by Pico but has been commented and tidied up by me. My problem is that the front panel is lagging such that when I scroll or enter values in controls, it takes about half a second before the action is registered / shown on my screen. This incidentally coincides with the time taken by one iteration of the temperature measurement loop.

From what I have found on the internet so far, my hypothesis is that the temperature reading, which is done through a Call Library Function Node and the function usbtc08.dll:usb_tc08_get_single, is using all the capacity of the UI thread. This node takes about half a second to get temperatures and then starts over, and in the transition between each acquisition, I think the UI thread is free to update the front panel (adding a 10 second wait inside the while loop makes the front panel lag for half a second every 10 seconds and responding nicely in between).

Some people online suggest changing the node properties to "Run in any thread", but then i only get 0's in all the temperature measurements. I need the temperature measurements to run as quickly as possible. My question(s) is(are) therefore:

Can I make the front panel update run in another thread?

Can I make the node work with "Run in any thread"? I have seen something about calling a VI with an "Invoke Node" vs calling a VI with a "Call by Reference Node" which might be worth checking out but I know nothing about these threads and the DLL-stuff.

Can anyone help - it would be much appreciated!

Magnus

[altenbach]

Have you tried to contact the maker of the hardware/driver/dll instead?

Was the example running any better before you "tidied it up"?

[tyk007 · Accepted solution]

To answer your questions:

• Front panel updates have to run in the UI thread. You can't change this and is in fact the standard convention in Windows (and Unix based) OS systems. Trying to run code in another thread other than the UI to not block UI updates is a extremely common practice in virtually every compiled language.
• Forcing your CLFN to run in the UI thread is normally the solution that solves multi-threading issues with libraries that were not designed to be accessed by multiple threads simultaneously (LabVIEW has only one UI thread). In your case it looks like dataflow should ensure that only one CLFN is executing at any one time so its not clear why you can't run the library in any thread as other people have commented unless the library was designed to be called by a UI thread explicitly for some reason or perhaps by teh same thread that create the initial data structures. Only the supplier can tell you more about this. You could try setting all the CLFN nodes to run in any thread, not just the 'get' function.
• Calling your VI either dynamically or in another VI hierarchy (or even another execution system) etc. will not help you here if you have the CLFN node configured to run in the UI thread as you will get the same behaviour.
• You are reading multiple measures with one 'get' call. What happens to your timing if you read only a single measurement? If this is an improvement you could read all of them in a FOR loop which would give the UI thread some breathing space between the calls.

I echo altenbach's comments here. Your first port of call should be to contact the supplier or find other examples of running this library (even if its in a different language).

[Magnus_C]

---

@altenbach wrote:

Have you tried to contact the maker of the hardware/driver/dll instead?

Was the example running any better before you "tidied it up"?

I have not tried contacting them. It did not seem to me they knew much about LabVIEW, but I will try anyway (EDIT: no I will not, because a solution was found!). Thank you for the tip!

I removed a wait function in the while loop which made the data aquisition run as fast as possible instead of every 2 seconds. Apart from that I don't recall any changes in performance after tidying up.

[Magnus_C]

---

@tyk007 wrote:

To answer your questions:

• Front panel updates have to run in the UI thread. You can't change this and is in fact the standard convention in Windows (and Unix based) OS systems. Trying to run code in another thread other than the UI to not block UI updates is a extremely common practice in virtually every compiled language.
• Forcing your CLFN to run in the UI thread is normally the solution that solves multi-threading issues with libraries that were not designed to be accessed by multiple threads simultaneously (LabVIEW has only one UI thread). In your case it looks like dataflow should ensure that only one CLFN is executing at any one time so its not clear why you can't run the library in any thread as other people have commented unless the library was designed to be called by a UI thread explicitly for some reason or perhaps by teh same thread that create the initial data structures. Only the supplier can tell you more about this. You could try setting all the CLFN nodes to run in any thread, not just the 'get' function.
• Calling your VI either dynamically or in another VI hierarchy (or even another execution system) etc. will not help you here if you have the CLFN node configured to run in the UI thread as you will get the same behaviour.
• You are reading multiple measures with one 'get' call. What happens to your timing if you read only a single measurement? If this is an improvement you could read all of them in a FOR loop which would give the UI thread some breathing space between the calls.

I echo altenbach's comments here. Your first port of call should be to contact the supplier or find other examples of running this library (even if its in a different language).

---

• Thank you for the information!
• This solved my problem! If there is any lag left, it is barely noticable!
• Thank you for the information!
• The user manual for my hardware Pico USB TC-08 specifies to use this function when several channels, but that for a single channel another, faster function can indeed be used, which can be as fast as a fifth of the time (0.1 s). I think this was a good tip!

[jseb38]

Hello Magnus,

I'm trying to use your simplified interface (MWE.vi) to display Pico USB TC-08 temperature channels on Labview interface, but I got (22) errors in the Diagram block related to the "usbtc08.dll"... The only way to get the DLL file on the computer was to install the PICOTECH software, which is working properly. But when I show the (correct) path of the DLL : C:\Program Files\Pico Technology\PicoLog 6 Beta\usbtc08.dll in the Block Diagram (for example : Call Libray Function Node), I got the same message : Invalid library , Library 64 bit for a Labview 32 bit version...

I'm using LABVIEW 2016 Version 16.0 (32bits).

How did you manage to overcome this error with your interface ? I couldn't find on the net any 32 bits version of the TC-08 Pico's driver (usbtc08.dll) ?

Additionnal question for the next step, did you solve your lagging problem by changing parametters in your VI or did you upgrade the MVE.vi to solve the issue ?

Thanks in advance

[Magnus_C]

Hello, jseb38!

Sorry for the late reply. I am currently on paternity leave and hence i both don't read my email so often and don't have my pico with me to test with. I don't remember having the same problem that you encounter, but I am using a 64-bit labView version. I dont know for sure that a 32-bit DLL exists - could you try on a 64-bit version of labVIEW?

In my current VI, I ended up with setting every CLFN (call library function node) to "Run in any thread" as suggested by tyk007. According to my previous post here (my memory today is a bit foggy), that solved the lagging issue in my user interface. Not related to this, there seems to be a second or two of measurement time when using 4 thermocouples, which i don't think can be improved. I cannot make a new MWE without my pico, but i attach my latest VI version, which was working the last time i checked (I think i was using LabVIEW 2017 SP1 64-bit). You very probably cannot run it, but you can probably open it and see the CLFNs? I can give you the sub-VIs also if you like, but it is setup for a specific NI-DAQ.

Hope this can be of some help!

[jseb38]

Hello Magnus,

Thanks for your reply and the VI sent. I'm currently running a LABVIEW2016 (32 bits) version, and so cannot open your file "furnace.vi ". I found a Labview TC-08 interface (version 2012) "PicoTech Picologger TC-08 Thermocouple USB interface 2012 NIVerified.vi", but I get an error message "TC08 Device not found". I copied the "usbtc08.dll" file in the directory : c: \window\system32 as required, but without succes. I do not know, what i'm doind wrong ... I'm still digging into the help directory.

Best Regards

Jean-Sebastien