LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Subpanel DO work on RT

Solved!
Go to solution

From all of the documentation I have seen, subpanels should not work on RT. So I was quite surprised when I ran a subpanel VI on a cRIO with embedded UI, and found that the subpanel did in fact seem to work exactly as I'd expect. I reached out to NI technical support, and they confirmed that subpanels can actually work on RT, but that this is an unsupported feature and they do not guarantee reliability.

 

Does anybody have any experience with using subpanels on RT? Just how "unreliable" are they? I would really love to have this feature, and may be willing to put up with little problems with it.

 

For reference, I was using LabVIEW 2017 and a cRIO-9035.

0 Kudos
Message 1 of 6
(812 Views)

Using the User Interface on an RT system sort of "wipes out" the Real-Time performance and ability of the RT system.  Running an RT System is similar, in some ways, to running a "multiple-parallel-loop" design, such as a Queued Message Handler with an Event Loop, several Producer/Consumer Loops, etc., but here you have two completely independent Processors, one optimized for Front Panel Interactions (the Host, on a PC), the other optimized for Real-Time, fast, time-reproducible actions (the RIO running the RT Target RTOS).  Communication between the two is via TCP/IP, perfectly fast enough for User Interactions ...

 

Bob Schor

0 Kudos
Message 2 of 6
(806 Views)

@Bob_Schor wrote:

Using the User Interface on an RT system sort of "wipes out" the Real-Time performance and ability of the RT system. 


I understand this limitation, and in our situation we do not need the RT performance of the cRIO. We're using the cRIO for its convenient packaging, not because we need RT. Using embedded UI will simplify our system, so I'd like to go this route if possible.

0 Kudos
Message 3 of 6
(793 Views)
Solution
Accepted by topic author buttersworth

I got some clarification from NI support. I'll copy what they wrote here. The gist is that subpanels do work in embedded UI, but can cause problems with RT performance. 


"1. Everytime there is a UI update, there is an interrupt on the UI thread and the UI update is processed and then the original process continues. This, as you can see, is not good if you have a big update to the UI and important loop that gets interrupted. This is why we provided content around best practices and UI benchmarks so you can start within "safe spaces" of performance.

2. Also, a SubPanel is just another front panel. With that in mind, that means two interrupts for every UI since LabVIEW treats them as separate front panels. This will double the impact of the previous point (1).

As I mentioned previously, "unsupported" doesn't necessarily mean it won't work. However, our recommendation is to avoid it, mainly due to the points described above."

 

Message 4 of 6
(700 Views)

Does this assume your UI is in the same Loop as your time critical/deterministic loop ? Do sub panels effect performance when used in a seperate, parallel loop (non-time critical) used only for managing the GUI?

0 Kudos
Message 5 of 6
(668 Views)

@srs14 wrote:

Does this assume your UI is in the same Loop as your time critical/deterministic loop ? Do sub panels effect performance when used in a seperate, parallel loop (non-time critical) used only for managing the GUI?


It certainly does although to a lesser degree. GUI updates are non-deterministic and do consume CPU performance. Even if they run in a different loop they still can and will grab CPU resources to do their work, and this CPU resources consequently won't be available to your time critical loop. This can and absolutely will be a problem if your time critical loop is already running near the limit of what your hardware can handle.

Rolf Kalbermatter
Averna BV
Message 6 of 6
(647 Views)