08-15-2007 12:35 PM
08-16-2007 12:50 AM
Hi,
The teststand API method Engine.TerminateAll() should terminate all executions via the Clean-ups.
Regards
Ray Farmer
08-16-2007 05:47 AM
Thank you for the reply. I do have a follow up question... TerminateAll seems like a brute force way of stopping all testing on all threads, if I inderstand this function correctly. So if one thread fails and I execute a TerminateAll call via the API, will the other threads also terminate immediately or would they complete the test step (i.e VI, etc.) they are executing before terminating? Also there is a possibility that multiple threads could fail at the same time. Would all of these threads calling the TerminateAll function at the same time cause any sort of run-time error?
Thank you,
Jim
08-16-2007 09:15 AM
Hi,
Unless your steps are using the API method to monitor from termination then the current step that is executing will complete and return back to the caller sequence then will jump to the cleanup of your sequence(s) and soon on....
Answer to the final part...it shouldn't do.
Regards
Ray Farmer
08-16-2007 12:13 PM
Jim,
We had a similar need and we used flags with just the Terminate API call to get all of the sockets to exit if an error occurred in one of them. This could easily be translated to do so on failures as well. We added the Terminate Step to selected Setups and Cleanups with a Global Terminate flag as a precondition. The sockets shared the file globals, so any socket could set the flag, and the others would follow it. It allowed a little more control over when a socket would exit to cleanup. Also note that the Terminate All API call will kill every execution, even the batch, which is something we didn't want.
-Jack
08-20-2007 07:29 AM
Jack and Ray,
Thank you for your responses!
While the TerminateAll appears to be a relatively easy solution, it does kill the batch execution ( I'm running from the Test UUTs entry point), which I do not want to happen. I want to terminate all of the UUT executions, but still be in a state where I can enter in a new batch of UUTs without having to start up TestStand again.
Jack,
It sounds like your solution may better fit my needs, however I am a little confused by your statement "We added the Terminate Step to selected Setups and Cleanups...". I thought you would only add the Terminate Step in the Cleanup section. Why would you add it to the Setup section? Would it be possible for you to include a snippet of your sequence so I could see how you set this up? I appreciate your help.
Thank you,
Jim
08-20-2007 08:56 AM
Yes it would shut down the Batch execution, but it doesn't kill TestStand. The Operator Interface or Sequence Editor is still running and therefore pressing the Test UUT's button again would start new executions.
I guess Jack's covering the possibles that the other executions are in the Setup when there see the flag set.
Regards
Ray Farmer
08-20-2007 09:13 AM
Ray,
Maybe I need to clarify what I am hoping to be able to do...
If one of the UUTs failed during a batch test, all of UUTs must stop testing. Once all of the UUTs have stopped testing, I need TestStand to be in a state where I can load in a new batch and start testing (similar to as if all of the UUTs passed and you are prompted to enter the next batch). What I am trying to avoid is to press the "Test UUTs" button as this would restart the batch model from the beginning, which for my setup would reinitialize a bunch of test instruments that is way to time consuming due to the high volume testing that is being done. Ideally, once all UUTs have stopped testing, I would like to return to the PreBatch callback step (or somewhere at the start of the "batch loop") in the Test UUTs entry point of the batchmodel.seq.
Again, thank you for your assistance.
Regards,
Jim
08-20-2007 09:34 AM
Hi,
I wonder if you could modify the Monitor Batch Thread sequence.
If one of your threads terminate, this sequence would detect this, then you could then tell the others to terminate as well.
Regards
Ray Farmer
08-21-2007 08:35 AM
Jim,
Sorry for taking so long - We added Terminate calls to Setup because we had multiple threads running in the background that could generate/set a termination event/flag. Also, we set some of our tests to run sequentially within the batch, as we had shared hardware, and set the Batch steps in setup before the Terminate step so that if the first socket failed, then all of the others would see it and jump to cleanup as they took their turn in the batch. This way it is a precaution to ensure that we didn't start a socket running a test if we didn't have too. We where primarily concerned with errors being generated from instrumentation or support equipment, such as power supplies or environmental chambers.
I prefer not to post a sequence, in part for proprietary reasons, but more because it would be confusing. It literally is a Active-X step with a precondition FileGlobals.TerminateFlag. We additionally used step in the MainSequence Cleanup to set a FileGlobals.Cleanup flag that the Terminate Steps would also be preconditioned on as an "Any Of", as we expected all of the Sockets to be in the cleanup at the same time, and this would catch premature exits (out of sync) executions. Once you've created your Terminate Step for one sequence/test it can be identical for all of them.
Hope this helps.
-Jack