Panel in Panel in asynch vi doesn't work?

[Nils_Thomsen]

Hi @all,

i try to build a program, that is dynamically load subpanels. within those sub-panels is another subpanel. All subpanels have to run independently.

I started loading the subpanels asynchronously (with param 0x80) and use two notifiers to handle the IPC. It worked, but it unloading the subpanels was painfully slow. Closing a subpanel took almost 20 seconds. If the user wanted to close the application, all subpanels had to unload (max. 10) what took around 200 seconds.

After a lot of research I found a solution using VIT instead of dynamically instantiated VIs, as all the non-reentrant handling will be done by the runtime. Closing times for the subpanel decreased to only half a second per panel.

But what's not working is the instantiation of the sub-sub-panel (the panel inside the panel). It will always fail on "run" with the red marked box saying the VI cannot run in it's current state and a NULL-Pointer was passed. 

Bottom is the main vi referencing the subpanel, top is code within this subpanel trying to load the sub-sub-panel.

Can you give me a hint, why this is not working? The "create vi reference" works and it returns a "name_number.vi" from the name property node.

[Nils_Thomsen]

While debugging, i found the reason but no explaination:

If i open the vi reference when it only has one sub panel, then the vi state is "idle". But when I run the parent vi (where it has the panel in panel) than the same state is "running", hence it cannot run it again.

Why does it auto-start the vi in the stacked form while it does not auto-run in the flat form?

[thomas-allibe]

Hi,

First, I never encountered this issue, so it's difficult to tell what's exactly going wrong without being able to see the code.

But, here's a few things:

You can (should?) use "Start Asynchronous Call" function instead of "Run VI" method.

Why?

• It seems to be NI intended way to start asynchronous VIs
• The interface is cleaner / easier to use, no "Ctrl Val.Set" property nodes
• It avoids the "Root Loop" issue (not the case here)
  • The Root Loop - LabVIEW Craft 
  • Calling A VI Asynchronously To Avoid The "Root Loop" Issue - NI

The only reason I'd use "Run VI" method is if I don't know the interface of the VI (not the case here).

Regarding the VIs you insert in your subpanels. If you want to instantiate them multiple times, they need to be set to "Shared clone reentrant execution" or "Preallocated clone reentrant execution". And you need to use the flags 0x80 | 0x40 = 0xC0 when opening the reference. I don't know much about VIT but I think they act like reentrant VI. Maybe the "20 seconds" delay was caused by a(several) timeout(s) because of reentrancy issues. But then, if I'm not mistaken, the reference outside "Start Asynchrounous Call" will not point to the actual VI instance. So you'll need either to send the sub panel VI reference up to the "caller" VI OR set the subpanel control reference to the subpanel VI.

If you plan to use subpanels, you can give MGI Panel Manager a try. It's a very good tool, I use it a lot with Actors, but it's totally usable without actors like in your case. It'll abstract the SubPanel Ctrl "Set VI Ref" for you and provide much more.

• MGI Panel Manager Toolkit for LabVIEW - Download - VIPM by JKI
• Panel Manager | Moore Good Ideas - LabVIEW Consulting Services

After installing it, you can give a look at their example in LabVIEW Example Finder. Alternatively, if you don't want to use it, you can take a look at how they developed it.

[thomas-allibe]

Hi

I don't know why, I wrote and sent a message but it disappeared... So, I'll only write a summary.

You can give MGI Panel Manager a try. This toolkit will helps you handling Sub Panels and more. They ship an examples with it you can find in LabVIEW Example Finder.

Also, I never used "Run VI" node and VIT. Instead, I use "Start Asynchronous Call" (easier to use, faster and intended way of doing async calls) and set the subpanel VIs to "Shared clone reentrant execution" to prevent stalling issues. But, you won't have access to the actual clone VI reference from "Start Asynchronous Call". So, to set the subpanel control VI reference, you'll need to do one of those:

• send the subpanel ctrl reference to the subpanel VI
• send the subpanel vi reference to the "caller" VI

Again, MGI Panel Manager handle this for you in a way.

My theory is that VIT behave like a reentrant VI, that's why the delay dropped significantly. I guess, before using VIT, you faced timeouts resulting in 20 seconds delay. Also, (like with "Start Asynchronous Call") the reference you have out of "Run VI" node is not the actual clone reference, resulting in an error.

Links:

MGI Panel Manager Toolkit for LabVIEW - Download - VIPM by JKI

Panel Manager | Moore Good Ideas - LabVIEW Consulting Services

https://www.ni.com/docs/en-US/bundle/labview/page/asynchronously-calling-vis.html

The Root Loop - LabVIEW Craft

Calling A VI Asynchronously To Avoid The "Root Loop" Issue - NI

[thomas-allibe]

Hi

You can give MGI Panel Manager on VIPM a try. This toolkit will helps you handling Sub Panels and more. They ship an examples with it you can find in LabVIEW Example Finder.

Also, I never used "Run VI" node and VIT. Instead, I use "Start Asynchronous Call" (easier to use, faster and intended way of doing async calls) and set the subpanel VIs to "Shared clone reentrant execution" to prevent stalling issues. But, you won't have access to the actual clone VI reference from "Start Asynchronous Call". So, to set the subpanel control VI reference, you'll need to do one of those:

• send the subpanel ctrl reference to the subpanel VI
• send the subpanel vi reference to the "caller" VI

Again, MGI Panel Manager handle this for you in a way.

My theory is that VIT behave like a reentrant VI, that's why the delay dropped significantly. I guess, before using VIT, you faced timeouts resulting in 20 seconds delay. Also, (like with "Start Asynchronous Call") the reference you have out of "Run VI" node is not the actual clone reference, resulting in an error.

That's the third time I send this message, this time without links hoping it helps..........

[thomas-allibe]

Oh so we're not allowed to use link, even though there's a feature for it....

Here's non clickable links...

https://www.vipm.io/package/mgi_lib_mgi_panel_manager/

https://www.mooregoodideas.com/products/panel-manager/index.html

https://www.ni.com/docs/en-US/bundle/labview/page/asynchronously-calling-vis.html

http://www.labviewcraftsmen.com/blog/the-root-loop

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kGHeSAM&l=fr-FR

[thomas-allibe]

Ah yes, including links (clickable or not) will delete the message....

WITHOUT WARNING!!!!!!!!!!!!!!!!!!

[thomas-allibe]

Smells like something analyzes the message AFTER the send button being clicked.

Decides links are bad.

Deletes the message.

Tells nothing to the user.

[Nils_Thomsen]

Erratic behavior and useless functions with stone-age optics and features is the core qualification of NI 🤣

[Nils_Thomsen · Accepted solution]

So finally (sorry to say so) ChatGPT gave me the best hint to what's wrong.

1) The path "NULL" is just a labview "feature" because the VIT copy is only in memory hance has no path.

2) The state "running" can either mean "is really running" or "reserved for execution". In both states calling the "vi.run" method will fail.

3) While running the sub-vi with the panel, due to the strict type definition labview knows there is a VIT that has to be cloned before starting it. So the VI state is "idle" after Open VI reference. Running the Main-VI with it's sub-panel it doesn't know about the sub-sub-panel with a strict type definition so the state is already running when labview sees, there's some work to do. Hence the state is "running", not "idle" and a vi.run will fail.

So the simple fix for two days of troubleshooting was: Remove the check at "strict type-definition" of the .vit constant.