NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Extra Window when using SubPanel

Seth_K,

If you are who I think you are, you did inherit the code from me.  This was a challenge from the beginning.  Aside from the things discussed in this thread, the way I got it to work previously required the TestStand Test Executive to be written in the same LabVIEW version as the vi's that were going to be displayed in the subpanel.  None of NI's documentation suggested that but it helped. 

 

Best,

0 Kudos
Message 21 of 36
(2,090 Views)

DJ:

When you say written in the same version, do you mean re-compiling all the VIs involved?  Specifically the UI and any widgets that the process model calls?  I'm fairly certain I updated everything up to LabVIEW 2015, but I can double check.  Either way, the execution doesn't flag any errors along those lines, but it did give me little hiccups during the initial update way back when, and I'm not seeing those.

 

Alexander:

I downloaded your code and ran it.  Here are the behaviors I saw:

  • Running the OI you sent either as an application or from the LabVIEW code had:
    the VI pop-up in a separate window with the pop-up running
    A copy of the VI was in the Subpanel which was responsive to user inputs, but not running.
  • Running the UI being developed either as an application or from the LabVIEW code had:
    The VI pop-up in a separate window with the pop-up running
    The subpanel seemed unresponsive, but after the minimize/maximize action, it was behaving the same as above: a copy was loaded, but it wasn't running.

I tried changing the process model back to the Sequential Model provided with TestStand, but the behavior did not change.  

 

I then tried going back to the original code I had (just to make sure I was able to duplicate the results from before), and yes, the running code loads into the subpanel, but doesn't update the subpanel automatically.

 

Thanks,
Seth

0 Kudos
Message 22 of 36
(2,079 Views)

Seth,

Yup, The UI and the Sequence Step that will load into the subpanel needed to be the same version ie LabVIEW 2012 SP1 etc... compiling them should work.

 

If that doesn't fix things, I would get on the phone with NI.  I used to scour the discussion forums for these types of issues, but I found in the end an hour or two on the phone with NI saved me days of searching and waiting for reply posts.

 

Regards,

0 Kudos
Message 23 of 36
(2,075 Views)

Hello Seth_K

 

i see the same you describe, if the LabVIEW adapter settings are set to development system,

if the LV adapter settings change to run-time then it works.

adapter.PNG

 

 

best regards
Alexander
Message 24 of 36
(2,054 Views)

Alexander,

 

Ok, I changed the adapter to the run-time, and it fixes the code you sent me.  However, it doesn't change the behavior of the code I wrote.  

 

I have a support ticket open and am working that channel currently.  

 

Thanks,
Seth

0 Kudos
Message 25 of 36
(2,044 Views)

Sooooo, just a quick update.  

 

Setting the Run-time Engine in Adapter settings is different than Step>Module>Advanced Settings>Always Run VI in LabVIEW Run-Time Engine.  

 

Setting the Adapter to use the runtime does get your OI to put the VI into the Subpanel correctly.  HOWEVER, if the Always Run VI in Run-Time Engine is also set, it then pops it up into its own window.  

 

I don't understand how setting it to use the Run-Time in two different ways gets two different results, as the VI should be using the same runtime in both cases, but so it goes.

0 Kudos
Message 26 of 36
(2,010 Views)

Hello Seth_K

 

i tried the settings and you are right, if the run-time checkbox in the advanced setting from the step is selected, a second window pop up is shown.

 

For me this means the step call his own run-time engine and this explain why a seond window pop up is shown, because it is a seperate instance from the LV run-time engine.

best regards
Alexander
0 Kudos
Message 27 of 36
(1,990 Views)

Hi Alexander,

 

Thanks for confirming that.  Has that been documented as a bug in TestStand?  

 

As to the original problem, I've gotten the compiled version to work.  I had the boolean logic for DeferPanelUpdates backwards.  

 

Thanks for the help,

Seth

 

 

0 Kudos
Message 28 of 36
(1,978 Views)

Hello Seth_K

 

sorry for the late reply i was OOO in the last weeks. I discussed with my colleagues the situation and it is not realy a bug, because this setting makes a new instance of the LV run time engine and this makes the effect with the separate window.

best regards
Alexander
0 Kudos
Message 29 of 36
(1,937 Views)

Welcome back from vacation.

 

Ok, if it's not a bug, can it at least be documented better, so that this confusion doesn't happen in the future?  The setting is shown as:

 

[] Always Run VI in LabVIEW Run-Time Engine

Enable this option to specifiy that TestStand always runs this VI in the LabVIEW Run-Time Engine, regardless of the server setting for the LabVIEW Adapter.  TestStand will automatically determine the correct version of the LabVIEW Run-Time Engine to use to run this VI.

 

This text doesn't communicate that it will always use a new instance of the Run-Time.  I can imagine other cases where this could lead to confusion. 

 

Maybe changing the bolded "the" to "a new instance of the" would help clear that up.  I'm open to other options, but this definitely should be clarified.

 

Thanks,
Seth

0 Kudos
Message 30 of 36
(1,925 Views)