Getting Test Socket status in batch mode

Question

Hi!
I´m running multiple UUT´s in the standard batch model.
I need to find a way to get a teststep running in one test socket to know the current status (passed, failed, terminated etc.) for all other test sockets.
Is this possible?
One solution might be to have each test socket to store the context pointer (CAObjHandle seqContextCVI when using LabWindows) to an array at the beginning of each test socket and then access each others test socket context. This way it might be possible if there is a context value or string to look for. Is this a good idea at all or are there better solutions?
/ Roine

Answer 1

Hi,
this would in fact be better in the TestStand discussion group.
However, there are several options available to you.
The first is to use queues. They're in the synchronisation menu. That way you can make sure you don't write to the same variable from two different threads before a third one has read it.
The second option is to store the seqContext pointer, however, this pointer is only a reference to where you currently are, i.e. if you start flying around launching other threads, then your seqContext might not be correct at that time
The third option is the hardest to implement. In the batch process model, the execution handles that are involved in the launching of Test UUT -- Test Socket Entry Point, are stored in a FileGlobal to the processmodel : FileGlobals->TestSocketExecutions. However, when you're in your sequence file, and you look at Runstate.Root.FileGlobals.TestSocketExecutions, it's empty. This is because that array hasn't been set as shared. So the top level Test UUT's can see it, but since we're launching executions, we cannot see it. So in the processmodel, you have to find the fileglobals, find the TestSocketExecutions, go to it's properties, and then hit the advanced button. Go down that list, and look for the property flag for shared at run-time.
That way, Runstate.Root.FileGlobals.TestSocketExecutions will have an array of execution reference handles.
From this handle, there's a method of the execution object to get a thread. This is where it's difficult, since you might not know which thread you're trying to get hold of. Once you have one of those, you can get the seqeuence context for that thread, and then you can (get using that as a property object), the number, string etc, from the other thread.
The last option is simply to share (as in option 3, but in the client sequence file) a variable, however, you can easily run into the problem you see in option 1 since the resource is like using station globals. There's no marshalling system to make sure things are written to before they're read from.
Hope that helps
Sacha Emery
National Instruments (UK)
// it takes almost no time to rate an answer