Hide disabled executions in Teststand 4 Operator interface?

[dseel]

Hi:

I'm customizing the Teststand 4 Full Featured CVI Operator interface.
When running in the Batch model, we often run on less then the full number of test sockets indicated in our model options.
In this case, the unused test sockets show up as disabled executions in the operator interface.
Is it possible to hide the disabled executions?

Thanks,
Dave

[AEDavid]

Hi Dave,

This would be possible, but would be a non-trivial task.  TestStand does not have this pre-configured as an option, and the executions populate the ExecutionList before the dialog appears that allow you to disable executions.  To do this, you would not connect the ExecutionList to the ExecutionViewMgr.  Instead, you would have to manually monitor the UI messages, update the icons, captions, and all other displays in the ExecutionList.  Then, you would have control over whether the execution is displayed if it is disabled. 

[dseel]

Hi:

Thanks for your reply.
I'm currently trying to hide the executions based on the Tile Windows call from the Batch model. I'm capturing the Tile Windows UI message. From there, I'm planning on hiding any executions not in this list.

So are you saying it isn't possible to hide the executions at this point? (Using TSUISUPP_ExecutionViewConnectionsRemove or something similar?).

It sounds like this would be a major change. Would it instead be easier to make one of the running socket executions display in the execution viewer by default? At the moment, it defaults to the highest number socket, which is usually disabled, so I don't see the steps being executed until I switch back to the socket 0 execution. How would I automatically switch which execution is currently visible?

Thanks,
Dave

[dseel]

Hi:

I was able to modify things so that the last active socket is displayed in the execution view. Here is what I did:

* modified BatchModel.seq (and parallelmodel.seq) to send a UI message once I know test socket is active
* once the UI message is received by the operator interface:
    TS_UIMessageGetExecution (uiMsg, NULL,&execution);
    TSUI_ExecutionViewMgrSetByRefExecution (gMainWindow.executionViewMgr, NULL,execution );

This works great for both the batch and parallel models.

Thanks,
Dave
   

[dug9000]

In TestStand 4.0 there is an easier way to do this. The UIMessage UIMsg_CloseWindows can be used to hide execution windows that have already been displayed. Rather than modify the UserInterface you can just modify the process model to post this UI Message for all executions that are disabled. A convenient place to do this in the process model would be the "Tile Execution Windows" sequence. You can create an array of disabled testsockect execution references exactly like this sequence already creates an array of executions to tile and instead of posting the tile UI message you can post the close windows one on the executions that are disabled. NOTE: you will also have to post an OpenWindows UI message just before tiling on the executions that you are going to tile incase they were previously hidden because they were disabled.

Hope this helps,
-Doug

[dug9000]

Here's a version of the 4.0 batchmodel.seq with the changes to the "Tile Execution Windows" sequence that I discussed. I also had to make one additional change to make sure tracing was turned back on for executions that were previously disabled. The CloseWindows uimessage will disable tracing on the executions whose windows you close, so when you reopen the window for the execution you will need to turn tracing back on using the Execution.TracingDisabled property. You can set this in an expression in TestStand 4.0 and that is what I did in the attached sequence file.

Let me know if you have any questions,
-Doug

[dseel]

Hi:

I was working on the batch model TileWindows changes in parallel and had noticed the tracing problem as well. The TileWindows subsequence from your BatchModel fixes this problem - thanks.

However, I'm able to reproduce a run time error through a sequence of (perhaps unlikely) events:
* start a test sequence with 4 test sockets using the batch model
* run the first socket, terminate in PreUUT, don't restart the first socket
(only the initial TestUUTs execution plus socket 0 will be visible in the operator interface, as expected)
* run the second socket, terminate in PreUUT, don't restart the second socket
(only the initial TestUUTs execution is visible in the operator interface)
* run the third socket, terminate in PreUUT: run time error popup:
Execution is already closed. Not found in list of executions
Operation Failed. [Error Code: -17500]

I'm assuming this has to do with the PreUUT call being before the TileWindows call. Suggestions on how to get around this error? Do I need to force all socket windows back open before the TileWindows call to catch this condition?

Thanks,
Dave

[dseel]

Hi:

I was able to fix the problem by forcing all socket windows open at the start of each batch loop. I added a ShowExecutionWindows call to your BatchModel.seq and attached it.

Thanks,
Dave

[Mr._Jim]

 Hi Doug,

I know this is an old post but this was still very much applicable and super helpful in reducing interface clutter - thank you!

For what it's worth to someone reading this in the future, I am doing this from a model plugin in TestStand 2017 using the "Model Plugin - Pre Batch" entry point. All of our model customizations (of which there are many) are now in our plugin and we are using the stock NI batch model.

In our case, from the "Model Plugin - Pre Batch" entry point I'm using the following:

RunState.Thread.PostUIMessageEx(UIMsg_CloseWindows,0,"",Parameters.ModelPluginConfiguration.RuntimeVariables.PerSocket[Locals.i].Execution,True)

Where locals.i is the test socket index.

To determine if a socket is disabled...

Parameters.ModelData.TestSockets[Locals.i].Disabled

To re-enable tracing...

Parameters.ModelPluginConfiguration.RuntimeVariables.PerSocket[Locals.i].Execution.AsExecution.TracingDisabled = False

Maybe someone will find this useful someday.