TestStand 2014 - modified batch model
System controls an environmental chamber and does tests on 4 UUT's. Enviromental chamber is shared resource and is controleld by one-thread-only batch synchronization. A Labview TempMonitor UI (also batch synchronized) pops up until the target temperature is achieved and the soak time is finished (so you can monitor the feedback from the chamber and see the amount of time left. This all works great in the fielded system.
Now there is a new requirement to continuously monitor the UUT's to make sure they stay in state during the temperature ramp and soak period. The simple answer is to integrate this monitoring into the TempMonitor UI as it has access to all of the relevant data acquisition buffers. However, I would need to do an end run around the traditional return since it is only being run by one of (up to) four sockets.
My thought is that if I had access to the sequence contexts of all of the active sockets, I could query them for their index and state, do the monitoring, and write the results back out to a local variable before exiting the UI. The only thing stopping me from forging ahead is that I don't know how to get the engine to give me sequence contexts for each active socket (0-3 of which may be disabled via setting ContinueTesting to False instead of disable flag, this is a product of using a customized 3rd party batch model, so the disabled executions are marked as Terminated during execution instead of Waiting).
Or, alternately, how to inspect all executions and determine what socket it belongs to (if any, since my daq engine runs in its own, hidden, execution).
Thanks for any help,
Solved! Go to Solution.
It sounds like you're looking for the active socket. The value of the RunState.TestSockets.MyIndex variable should tell you which zero-indexed test socket is the current active socket.
I was actually looking for a way to get SequenceContext's for the other active sockets from whichever one launched the TempMonitor GUI so I could set results in those other sockets directly.
However, I've given up on this and instead I'm launching the TempMonitor GUI into its own thread and having each socket monitor the UUT state on its own with a separate VI until the temperature ramp/soak is done at which point the GUI will set a StationGlobal boolean which triggers the individual sockets to proceed. More complicated, but also more in the TestStand spirit of things, I think.