From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Signal Conditioning
Getting Test Socket status in batch mode
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)
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)
