LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to manage the Preferred Execution System to optimize threads?

Solved!
Go to solution

Hi !

 

I am trying to understand how the "Preferred Execution System" works and how to use it correctly (mainly between "User Interface" and "Standard" or "Data Acq")

 

I have my main VI that also serves me as the main user interface and so it is doing "a lot" of calculations (parsing, calculation on arrays etc.) but also displaying "a lot" of information (graphs and numerics) and has some interactions based on user activities (tab control, renaming/moving some numerics using prop nodes etc.)

 

I would like to train a bit on using the Preferred Execution System by creating a sub-vi doing all (or almost) my calculation and setting it on ... Standard (?) and setting my main vi on User Interface.

I am aware that Labview uses threads differentiating User Interface and "calculation" (whatever that means) but I'm just not sure how that works.

I'm already using Queues and passing data and references would be Too difficult to adapt on my current software, but I would like to know if that would be a good thing to do (and potentially increase performances) or not.

I am also thinking of using the property "Defer panel updates" but I'm not sure that this would be suited for me as it slows down the interactions with the user too (buttons are less reactive)

 

Thank you for your feedback.

 

Best,

Vinny

0 Kudos
Message 1 of 9
(2,134 Views)

Hi Vinny,

If you search the web, you will easily find the whitepapers explaining the Preferred Execution Systems...
basically what is boils down to is that LabVIEW will allocate a certain number of threads per execution system and then a few more for the user interface.
Each execution system has thread priorities that can be set (again t in the white papers) and the threads are subdivided by prority and more are assigned to the tasks with the highest proritiy if needed (That's not actually what it says nor am I going to say that is how it works, but it is a good way to start thinking about breaking down your code into modular chunks to run.

Graphs and charts always force a UI redraw on update (which takes time).
Property nodes always execute in the UI thread (so avoid where possible)
Anything that can be run in a subVI and potentially moved into another execttion system will possibly make your program faster.
More data copies will make your program slower - try not to copy data between exection systems.
If you can have one execution system for the Data acquisiton, and one for control, one for logging and 1-2 for processing you generally do nicely.

(I'm dealing with big data streaming at 200MB/s+ so I've pretty much optimised my system now for the execution systems as that was the first easy win, there's still loads of legacy UI work to update and Property nodes to slash out though)

Do as little as possible in the UI thread - you will find some DLLs must run in that thread and Windows has a habit of hammering that harder than most. (but do keep your dialog updates in that thread - just use subVIs where possible to process arrays etc instead of doing it in the UI thread.
Local variable updates don't force a FP redraw, so defer FP updates and only updating every 1-2 secs of when you know you need to can drop CPU usage quite a lot.

(Haven't searched for or provided the links as I know you're more than capable of finding them - I've seen your other posts 😉)

Hope this helps

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
Message 2 of 9
(2,106 Views)

Hi James,

 

Thanks for your answer.

Yes I can imagine that I can find such white papers, but given that I technically have no SW background + english not being my first language, white papers are rather difficult to understand and I was looking for a diluted version of it 😄

 


@James_W wrote:

Graphs and charts always force a UI redraw on update (which takes time).
Property nodes always execute in the UI thread (so avoid where possible)


Until now I was using charts and update as soon as I have data, but now I'm trying to move on to graphs. That way I can build up arrays and periodically send these into my charts at regular times (I have a separate while loop sending periodically a "Display data" message in the queue that is receiving the data and building up the arrays..... Or at least that's the idea, working on it currently)
This display timing can be managed by the user (from 50ms to 2s) depending on how much data is requested to ease the software

 

In term of P.Nodes, I use them extensively at SW startup to initialize all of my controls/graphs etc. but then it is mostly just to update two numeric controls to either enable/disable or change their caption based on the control type I do on my device

VinnyLaTaupe_0-1646146761233.png

 

 


@James_W wrote:


(I'm dealing with big data streaming at 200MB/s+ so I've pretty much optimised my system now for the execution systems as that was the first easy win, there's still loads of legacy UI work to update and Property nodes to slash out though)


That's a good point actually, how do you calculate your data streaming? I can roughly calculate what I have on my CAN bus (about 800kB/s at max) but the actual data stream withing my software, I'm not sure how to estimate it (like how big is the data display on my graphs etc)

I have about 40 telemetry data to automatically request over the CAN bus 

It doesn't feel like a lot tbh, but it looks enough for my interface to be buggy whenever any user action happens...

 

 


@James_W wrote:

Local variable updates don't force a FP redraw, so defer FP updates and only updating every 1-2 secs of when you know you need to can drop CPU usage quite a lot.

James


So I've done some tests on a small VI with Defer FP updates, and my problem was that it actually defers everything, even the button highlights when you hover your mouse, and I wasn't fan of this... So I went with the solution I said above. According to my tests it does reduce my CPU usage significantly as well 🙂

 

Thanks again for your time.

Vinny.

 

0 Kudos
Message 3 of 9
(2,091 Views)

Hi Vinny,

 

If you have charts and you don't want a laggy UI, just put them on a Tab control and show a different tab when you don't need to see the data. (Also pre-initialing an array of chart history length will give you contiguous memory for the data points and should speed up updates whilst replacing the data points). - But graphs are often a better option for performance.

 

When I'm being really lazy and crude I do something like this (in a seperate loop from the Dequeue loop and kill it with a local when the UI closes) - it's not as clean as handling the updates correctly but you generally get a good response (100ms is a good loop time not the 250 I have here) - False case has nothing in and the bottom true case is irrelevant.

James_W_0-1646164936632.png


Data streaming is a bit below the level I work with. I get told numbers and check that they look right to me, but I'm not a bit bashing S/W programmer either, my background is Mech Eng.
Generally if you look at the LabVIEW data types you will get told a certain type takes a certain number of bytes and then you multiply it by how much you've got to get a ball park (I really need to do some more low level stuff, but I'm actually quite good in the apps layer and breaking things with testing, so I don't find the need to drop deep into bits and protocols too often.)

 

(Suspect this post will popup in the RubeGoldberg thread for some reason☹️)

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
Message 4 of 9
(2,070 Views)

@VinnyAstro wrote:

 


@James_W wrote:

Local variable updates don't force a FP redraw, so defer FP updates and only updating every 1-2 secs of when you know you need to can drop CPU usage quite a lot.

James


So I've done some tests on a small VI with Defer FP updates, and my problem was that it actually defers everything, even the button highlights when you hover your mouse, and I wasn't fan of this... So I went with the solution I said above. According to my tests it does reduce my CPU usage significantly as well 🙂

 


If I remember correctly, the defer updates property is set per-panel so by default it will defer the entire front panel but you could use subpanels or splitters to defer only one portion of your UI.

 

That being said, I usually think of this property being less helpful for performance and more helpful for preventing strange looking "UI glitches". As an example if you are adding/removing many items from a tree deferring updates will make the tree update all at once rather than quickly flashing through every single change from adding/removing items. This property can actually cause LabVIEW to redraw more of the UI in certain situations.

Matt J | National Instruments | CLA
Message 5 of 9
(2,052 Views)
Solution
Accepted by VinnyAstro

@James_W wrote:

Hi Vinny,

 

If you have charts and you don't want a laggy UI, just put them on a Tab control and show a different tab when you don't need to see the data. (Also pre-initialing an array of chart history length will give you contiguous memory for the data points and should speed up updates whilst replacing the data points). - But graphs are often a better option for performance.


James


Yes, I like using charts as I find it way easier somehow, but graphs are definitely more practical for the user (with cursors especially)

 


@James_W wrote:

 

James_W_0-1646164936632.png


James


Yeah exiting the loop was something that was bothering me (didn't to create a whole new queue, send an exit message ...

So I just used the error thread, whenever the queue is released, it will exit anyway.

VinnyLaTaupe_1-1646210930761.png

 

 

@jacobson

If I remember correctly, the defer updates property is set per-panel so by default it will defer the entire front panel but you could use subpanels or splitters to defer only one portion of your UI.

 

I don't know about that, but given that the P.Node takes in a reference from a panel, I guess it can take a ref from a sub-panel/separate pane yes, not a bad idea 🙂

 

 

This property can actually cause LabVIEW to redraw more of the UI in certain situations.

 

Do you have an example?

 

 

 

So in conclusion, in the example of a lot of graph updates, it is definitely best to:

  • Put all "calculation" in a sub-vi (for instance building a preset graph array and managing data inside)
  • Set this VI to Standard (for example)
  • Send its data out (graph data) to my graphs in my main which is set to User Interface as a Preferred Exec. System.
  • Manage the UI refresh time to free-up Processor time.

Is that it?

0 Kudos
Message 6 of 9
(2,035 Views)

Conclusion looks about right. Vinny,
last thing would be.
Split UI Module to be seperate from all other modules and run UI module in UI execution system (otherwise there will be lost of thread swapping going on)

@Jacobson
Love the idea of only updating per panel, didn't think of that and it could make the FP updated more efficient for me.

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
Message 7 of 9
(2,013 Views)

@Jacobson-ni wrote:

That being said, I usually think of this property being less helpful for performance and more helpful for preventing strange looking "UI glitches". As an example if you are adding/removing many items from a tree deferring updates will make the tree update all at once rather than quickly flashing through every single change from adding/removing items. This property can actually cause LabVIEW to redraw more of the UI in certain situations.

Defer panel updates can also cause glitches.

 

For instance, a release of a graph cursor when defer panel updates is on, will not draw the moved cursor when defer panel updates is turned off.

 

Picture controls also have issues with defer panel updates. IIRC, they are not updated when DPU is on and then turned off, unless you hide the control, update it, and show it again.

 

All of this might only happen if the controls are in a sub panel.

0 Kudos
Message 8 of 9
(1,997 Views)

Cool, thanks a lot for the help 🙂

 


@James_W wrote:

Split UI Module to be seperate from all other modules and run UI module in UI execution system (otherwise there will be lost of thread swapping going on)


Yes, this is also planned ... but for later unfortunately.

0 Kudos
Message 9 of 9
(1,959 Views)