UI race condition in nested subpanels

[JohnZ]

I am considering using nested subpanels to display processing results for multiple subsystems, but the value of controls passed into the lower levels are not displayed correctly.  I have attached a simple set of VIs which demonstrate the issue.  Parent.vi invokes two instances of Child.vi using different values for the subsystem control. Each instance is inserted into its own subpanel on a tab control.  The process is repeated at the child level, which invokes two instances of Grandchild.vi and inserts them into separate subpanels on a tab control.  The UI for the child and grandchild VIs are similar; Subsystem is the control value from the calling VI, Subsystem 2 is an indicator wired directly to the control, and Subsystem 3 is an indicator wired to the control but located inside a while loop.  At the child level, the control and both indicators are correct.  At the grandchild level, the indicator inside the while loop is correct, but the control and indicator outside the loop are incorrect.

This appears to be a race condition where the subVI begins executing before the subpanel UI is available.  Any controls or indicators which have already fired when the subpanel UI becomes active are displayed with their default values.  In fact, the loop counter and the subsystem indicator inside the loop are not updated until the second iteration of the loop.

Adding an initial delay in the grandchild subVI allows both subsystem indicators to be displayed correctly, but the control is still shown with the default value.  

Is there a way to get controls to display correctly for subVIs inserted into nested subpanels?

I appreciate any suggestions,

John

[Whit-E_Wall-E]

Hello John,

I was able to produce the same misbehavior as you are seeing.  The main reason is because the subVI goes into a loop does not exit until the stop button is clicked.  With the Subsystem controls outside of the while loop the indicators inside will never be updated as there is no method to exit the loop and re-enter with the new data.  Without restructuring the architecture of the program the easiest method to update the indicators inside the loops would be to use local variables.

[James_R]

I would abandon the idea of using nested subpanels

I have found they cause major problems even if you structure the code correctly

[JohnZ]

The problem is with the controls outside the loop, not the ones inside the loop.  The actual value of the controls outside the loop are correct, but they are displayed incorrectly.  Here's my best guess at what's happening:

1. The asynchronous call starts the subVI running with the proper control values supplied by the calling VI.

2. When the subVI is inserted into the subpanel, the front panel is initially displayed with the default value for each control and indicator, regardless of its actual current value.

3. Any controls or indicators which change after the subVI is inserted into the subpanel get updated to their current value.  

So, since the controls outside the loop do not change while the subVI is running, they are never updated to show the true value passed in by the calling VI ("Alpha" or "Bravo" in the example) rather than the default value ("Undefined" in the example).

I have found that by reversing the order of operations, i.e. loading the subVI into the subpanel beforestarting the asynchronous call, all the controls and indicators display properly, at least in the simplified example code.  This seems to fit my theory outlined above.  However, this is the opposite of all the examples I have seen from NI. Is there a reason that the subVI should not be inserted into the subpanel before it is run?

John

[JohnZ]

James,

I have seen a similar comment elsewhere, but neither instance gave any examples.  If you could describe some of the more significant problems you've encountered with nested subpanels, it would help in evaluating whether this approach is worth pursuing.

Thanks,

John

[Whit-E_Wall-E]

Hello,

The way the application appears to be set up the Subsystem data that is passed into the calling VI will only be updated once when it initially is called.  The reasoning for this is you only call the Grandchild VI once therefore the input will only be updated initially.  The Subsystem control in the Child will not be represented in the Grandchild VI unless you incorporate a way to send the updated information to the subVI.  You can do that by rearchitecting the application to send another input into the subVI or you can create a variable to communicate between the two VIs.

[JohnZ]

M.

I think you're misunderstanding the issue.  I do not want to change the subsystem control after the subVI has been called.  I merely want each control displayed in a subpanel to show the actual value that the subVI was called with.  With the original example code I attached, the subsystem control in the Child subpanel displays correctly, but the subsystem control in the Grandchild subpanel displays "Undefined" (which is the default value of the control) rather than the "Alpha", "Bravo", or "Charlie" value supplied by the calling VI.  I have resolved this by changing the order of operations: I insert the VI into the subpanel BEFORE I make the asynchronous call.  That lets the controls display properly on all subpanels.

The behavior I'm seeing indicates that when a VI is inserted into a subpanel, it is initially rendered for display with the default value for all controls.  Controls are not updated to reflect their current value until they change. Therefore, controls wired to the connector pane do not reflect the actual value of the calling argument if the VI is already running when it is inserted into the subpanel.  This confusion appears to be avoided by inserting the VI into the subpanel BEFORE it is run.

My only reservation with this solution is that all of the NI examples I have seen insert the VI into the subpanel AFTER the asynchronous call.  Is there any technical reason for this ordering?  

Thanks,

John

[Intaris]

Hmm this sounds familiar.

I think changing the values of FP controls and indicators of VIs whose panels are not open are "lost" regardless whether they are in a sub-panel or not.  I remember vaguely running into exactly this behaviour before.

You can try opening the FP of the VI as "Hidden" via VI Server (FP.Open with "State" set to "Hidden") immediately after loading the sub-vi and certainly before doing any changes to it. That, I believe, will solve the problem.

Shane.

PS I think you can open the FP this way BEFORE the asynchronous call, I'm not sure.

[drjdpowell]

---

@Intaris wrote:

I think changing the values of FP controls and indicators of VIs whose panels are not open are "lost" regardless whether they are in a sub-panel or not.  I remember vaguely running into exactly this behavior before.

---

That's how I understand it also.  I believe its because, for performance reasons, a data copy for the Front Panel control is not made if the FP isn't open, so when the FP is later opened, the only value is the default.  If they didn't have it this way, then every subVI would be making unnecessary data copies.