Sub-Panel with Run async or Run VI invoke node?

[VinnyAstro]

Hi!

Currently starting a new application that will command and control a motor via a USB to CAN device, the app will have in the end a lot of "modules":

Control module and display module (typically set and display speed and acceleration; Display temperature and a lot of other telemetry data) ; A communication module (where the USB2CAN interface is configured) and then other future modules that are "testbench-related" (typically a test bed recording vibrations, another for vacuum testing etc.)

Because I don't want to have a pop-up window showing for every modules (my application will most likely be run on a laptop and the screen will quickly be un-readable) I would like to use a sub-panel.

When the user click on the "Motor control" button, then the motor interface shows-up on the sub, then switches to the CAN interface when the button is pushed etc.

My question is: 

Should I start these modules via the "Run asynchronously" method or by using the "Run VI" method?
I am using the NI QMH template for now (I really want to start using the DQMH one day, but I still need to learn labview OOP first...), so I don't need to "wait on async data" from these modules at any time (except maybe when closing the app) as they will communicate with each others via messages.

What would you do in term of performances and easiness of integration?

I actually have previously tried the async+sub-panel on my previous project, it was working ok, but I was not convinced with the performances: I actually did a mix between using the subpanel and a tab control, where my main interface (data display) was on tab1 and the sub was on tab2. But when I wanted to introduce some dynamic in my interface like in this thread (point 4) everything started to lag while the processor was absolutely fine...

I'm thinking that my knowledge of how Labview handles the interface and the background code isn't developped enough to manage this properly (I believe it has to do with the UI thread vs the code threads or somehting like this?)

I don't have much code to share right now as I am still thinking of how my arrchitecture should look like, but if necessary I can probably start coding some stuff to help explaining my point.

Thank you in advance for your help.

Best,

Vinny.

[James_W]

I've got a VERY intensive program with 75+ modules all launched with "start asynchronous call" - each VI is then told to close at the end.
UIs are shown to the user as and when required (using Invoke nodes).
The User Interface thread will always lag every time you update it. Keep updates to a minimum and you will not have as much of an issue.

(*aware that anything I get wrong here is going to get slammed😉)

1) Move as much as you can into other execution systems - and let LabVIEW do the heavy lifting (search execution systems)
2) Only keep the UIs in the user interface thread.
3) Minimise Property node use in VIs not in the UIs - causes thread switching 
4) use the defer FP updates property node to prevent FP redraw until a big chunk is ready to redraw

5) Graphs and charts force a redraw when updated

6) Search the forum on how to improve UI performance
7) tabs not shown don't get redrawn (so FP updates faster), subpanels take extra time to redraw (so slower)

😎 The biggest gotcha with subpanels is that they show the VI FP in the state it was saved - so you MUST make sure that it is always saved in the same size and position (consider scripting a VI to do this for multiple VIs if you are going to show them in the same subpanel

Hope this helps
James

[rwunderl]

Like James_W, I also manage an application with 80+ modules that are dynamically loaded into a mix of Tabs and SubPanel controls. In my case, there is a common "shell" module that is nothing but a Tab control with one (or more*) SubPanels on each page. The shell is responsible for reading a config file, opening a reference to each module's top-level VI, sending the VI its own unique configuration file path using the Ctrl Val.Set Invoke Node, and using the Run VI method (Wait Until Done is of course False). The VI is then inserted into the SubPanel and the original VI reference is closed. The modules are re-entrant, can be called multiple times with different config files, and are pre-compiled into PPLs. Only the module's top-level VI is "Public" scope, so it is the only VI that can be externally accessed. There's nothing OO or AF about it.

*Since LabVIEW cannot create controls dynamically at run-time, a pre-determined number of tab pages are pre-filled with some number of SubPanel controls, which limits the flexibility of the shell module. But each SubPanel can be resized and arranged in a configurable way.

The entire thing runs as a LabVIEW executable (using the Run-Time Engine); that is, the "launcher" is an executable (that has no knowledge of what it is executing, by the way). This frees the Development Environment up to do online bug fixes and re-builds if necessary without tanking the whole thing (LabVIEW IDE pauses everything, or at least the UI thread, to build a Build Specification).

The modules do everything from serial comms to providing operator HMIs. Communication is done through Shared Variables, which has been OK but I wouldn't recommend it for a new design. The modules don't strictly speak directly to one another, but rather share information and commands using the variables.

This architecture has worked well for 10+ years, and generally hums along on a modern computer at 1~5% CPU.

[VinnyAstro]

Hi James, thank for your prompt answer.

A few questions and remarks based on your inputs:

1. I believe you are referring to this?
   
   The labview help page mentions:
   Preferred Execution System—Sets the preferred execution system. LabVIEW supports multiple simultaneous execution systems. On some platforms, a VI running in one execution system also can run in the middle of a VI running in another execution system. This allows higher priority tasks, such as data acquisition loops, to interrupt long operations, such as slow calculations.
   Normally, you set all VIs to run in the same execution system as the caller. To use an alternate execution system for a set of VIs, set the top-level VI to that execution system. All its subVIs also run in that execution system.
   So does it mean that in my Coms module (for instance), which basically will be one big VI, can be set up as a User Interface (as it will require some interactions with the User) and some sub-vis, like the read and write VIs can be set as Data Acquisition and then it won't be under the same threads? (Still trying to figure out exactly what are those threads)
2. So that means no controls/indicators other that inputs/outputs of the VI?
3. Can you elaborate? Because what I meant earlier (having a dynamic main interface, check the VI attached, I find it pretty cool 🙂 ) would call the property nodes of buttons positions in a loop (to create a smooth movement) until it reaches a certain position. Is even this too much?
4. Never used it before, I'll check it out!
5. 6. and 7. Noted. I will try and find some more info online. But the fact that a tab isn't updated when not shown then doesn't explain much why my app was so laggy...

For the sub-panel catch: yeah I actually had this issue already during my previous app, especially with having a module requiring a significant amount of screen space and another one not that much. Also not really possible at the time to properly center/resize everything based on the displayed sub-vi which isn't very aesthetic... See the discussion here.

Best,

Vinny.

[James_W]

Hi Vinny,

1) Yes - that's the execution bit.
Only VIs that are User interfaces should be UI thread, you free up threading if you set UI subVIs to other threads 
Coms should not be UI thread - use Instrument I/O 
Realtime module threading is described here:
Understand the Priority-Based Scheduling Model (Real-Time Module) - LabVIEW Real-Time Module Help - ...
For Normal LabVIEW
LabVIEW Threading Model - LabVIEW Help - National Instruments (ni.com)
How Many Threads Does LabVIEW Allocate? - National Instruments (ni.com)
(basically you get more threads assigned to your program if you utilise more execution systems; however using more threads doesn't necessarily gain performance improvements if you end up chopping up large datasets)

2) Nope - just means VI not being used to show data to the user (not got FP displayed forcing display redraw)

3) shouldn't be a problem in that case, but as a subVI in a different thread would cause a thread swap. In that VI, it's a UI VI, just avoid property nodes in Coms modules etc if you can. Property nodes force a front panel update, local variables and wired terminals dont.
(and make sure you look at what spec you have on your machine).
program will always run faster as an EXE - can cause graphics/memory issues over time if you have MCLB increasing in size or charts / graphs of uninitialised size.

4) - if you haven't used this before, that's probably a big cause of lag.
controls over the top of each other take longer to redraw.
When not using actions, only updating the FP every 1sec or less give the UI time to catch up with data coming in. (free up the UI queue)
sometimes I even have a button to turn off FP updates if required to enable processing to take place if the data logging is more important and the PC spec is really poor.
(lucky now, get to play with 50+ core server grade machines 😉 - I can still kill them in 5 mins with a runaway UI with the data rates I deal with 🙄)

James

[VinnyAstro]

Hi Rwunderl,

Thanks for your answer.

This kind of application seems to be out of my league for now though ^^

However I do keep in mind the idea with multiple tabs/subs which I suppose you dynamically hide and un-hide depending on user request? I was trying to think of a way to make my code modular (for instance being able to connect multiple motors), and having these modules re-entrant, calling them multiple times and managing them through tabs sounds a good option to me 🙂

About the shared variables, I simply hate them right now 😅. I am also working with a rather (already developped) big application using a sh*t ton of those, it makes the debugging simply impossible as you don't know where they are set and where they are read easily...

[VinnyAstro]

---

@James_W  a écrit :

Hi Vinny,

1) Yes - that's the execution bit.
Only VIs that are User interfaces should be UI thread, you free up threading if you set UI subVIs to other threads 
Coms should not be UI thread - use Instrument I/O 
Realtime module threading is described here:
Understand the Priority-Based Scheduling Model (Real-Time Module) - LabVIEW Real-Time Module Help - ...
For Normal LabVIEW
LabVIEW Threading Model - LabVIEW Help - National Instruments (ni.com)
How Many Threads Does LabVIEW Allocate? - National Instruments (ni.com)
(basically you get more threads assigned to your program if you utilise more execution systems; however using more threads doesn't necessarily gain performance improvements if you end up chopping up large datasets)

---

Thanks for the links!

---

@James_W  a écrit :

3) shouldn't be a problem in that case, but as a subVI in a different thread would cause a thread swap. In that VI, it's a UI VI, just avoid property nodes in Coms modules etc if you can. Property nodes force a front panel update, local variables and wired terminals dont.
(and make sure you look at what spec you have on your machine).
program will always run faster as an EXE - can cause graphics/memory issues over time if you have MCLB increasing in size or charts / graphs of uninitialised size.

---

I anyway have no choice than to run .exe, I have my dev machine and then we have (very old) controlling machine. Memory issues I've experienced it once not on purpose, and the played a bit with it on purpose (trying to crash my computer as fast as possible :D) to see a bit more how labview interacts with the memory. I still don't know how to play along with the gpu though.

---

@James_W  a écrit :

4) - if you haven't used this before, that's probably a big cause of lag.
controls over the top of each other take longer to redraw.
When not using actions, only updating the FP every 1sec or less give the UI time to catch up with data coming in. (free up the UI queue)
sometimes I even have a button to turn off FP updates if required to enable processing to take place if the data logging is more important and the PC spec is really poor.
(lucky now, get to play with 50+ core server grade machines 😉 - I can still kill them in 5 mins with a runaway UI with the data rates I deal with 🙄)

James

---

Thats a lot of cores haha. In comparisons, my application will have to work on machines that are at least 10 years old... And they were already not the fastest of their kind...

I will play a bit with this and see how it goes.

Actually that raises another question to my mind:

What should my main vi be set as Execution bit?
Because it technically "doesn't do much": Creates and inits queues, variables etc., and then just waits for a user interactions to display one module or another. Or does its front panel will be as busy as whatever the sub-panel will display?
Meaning should I use the Defer FP node in this higher main VI AND in my UI VIs? Or only in the UI VIs?

[rwunderl]

---

@VinnyAstro wrote:

However I do keep in mind the idea with multiple tabs/subs which I suppose you dynamically hide and un-hide depending on user request?

---

No, all of the SubPanels [that have modules loaded into them] are always Visible=True. They are only "hidden" by virtue of the Tab control itself. I have shells that include the shell module itself as a child module hosting other related modules, so the system is nestable. This does not seem to cause much heartburn in the UI thread.

---

@VinnyAstro wrote:

I was trying to think of a way to make my code modular (for instance being able to connect multiple motors), and having these modules re-entrant, calling them multiple times and managing them through tabs sounds a good option to me 🙂

---

Yes, this is exactly what this system does. When you open the VI reference, you can specify that the reference is for reentrant run. You could also just have a PPL per module (even if it's the same source code) to avoid having multiple running modules rely on the same PPL file. If there are 7 of the same power supply, you would have 7 PPL files (built from the same source code) in the deployed folder, and you'd call each individually.

---

@VinnyAstro wrote:

About the shared variables, I simply hate them right now 😅. I am also working with a rather (already developped) big application using a sh*t ton of those, it makes the debugging simply impossible as you don't know where they are set and where they are read easily...

Yeah, like I said shared variables are not ideal. I wouldn't do it like this today. However, it is an exceedingly simple way to log single-point data to a database (if you have the Datalogging and Supervisory Control toolkit). Unfortunately, NI has not invested in this product at all in a decade or so... it could have been great, especially when integrating with PLCs and their OPC servers.

I hope the comments help you in some way to decide on an architecture.

[Mark_Yedinak]

If you will be using subpanels I highly recommend that you look at the MGI Panel Manager toolkit. It takes care of all the panel management stuff for you. No need to re-invent the wheel. In our design we didn't use tab controls for our design. We mimicked them using other subpanels. Although our system is message based so it is easier to communicate between the various modules. Anyway, by loading a subpanel that replaces the tabs, we can have different number of tabs visible depending on which subpanel is loaded or what we are currently displaying. you can also use an array of picture controls which essentially gives you an infinite numbers of tabs. You simply load the correct images for your tab set and the user can scroll through them if there are more than what is visible on the screen. though I don't recommend that you have so many that scrolling is required. It just gives an option for a variable number of "tabs" at run time.

[rwunderl]

---

@Mark_Yedinak wrote:

If you will be using subpanels I highly recommend that you look at the MGI Panel Manager toolkit. It takes care of all the panel management stuff for you. No need to re-invent the wheel.

Yes, I like MGI Panel Manager very much, and agree with not re-inventing it. I would recommend it to anyone as a way of launching windows and using subpanels. As I said, this project has been running for a long time, and I don't know if that toolkit existed then. (Even if it did, the original developers likely didn't know about it.)

---

@Mark_Yedinak wrote:

In our design we didn't use tab controls for our design. We mimicked them using other subpanels.

...by loading a subpanel that replaces the tabs, we can have different number of tabs visible depending on which subpanel is loaded or what we are currently displaying. you can also use an array of picture controls which essentially gives you an infinite numbers of tabs.

---

I also have steered away from using tab controls, as they do introduce some interesting graphical glitches sometimes. This is especially true if you have graphs or charts involved. Using a single subpanel and swapping out the inserted VI with MGIPM is a very nice solution. Being able to easily pop the window out is also a very nice bonus.

I have also played with picture controls and the .NET PictureBox, but these are only good for some limited applications (IMHO).