Is there a way to read the number of active sequence executions from the Engine?

[Joe Roberts]

Hello,

Is there a way to determine the number of active sequence executions from
the Engine or other TestStand object?

Thanks,

---
Joe

[Scott_Richardson]

Joe -
In the TestStand Engine API, there is not a way to ask it to return a collection of the executions that exist. The only way to know about visible executions is when these executions send a message to your operator interface that a window for the execution should be displayed.

In TestStand 3.0, the new UI Controls manage the list of executions that it creates and you can ask the Application Manager control for access to that collection.

Scott Richardson (NI)

[Joe Roberts]

Scott,

> In the TestStand Engine API, there is not a way to ask it to return a
> collection of the executions that exist. The only way to know about
> visible executions is when these executions send a message to your
> operator interface that a window for the execution should be
> displayed.

Thanks for teh reply. I do not need access to the collection or execution
items themselves. I was wonder if I could simply determine the number of
executions (IOW: # of times a client sequence file execution had been
started using the same base process model).

This is related to my questions under the thread 'Recommendations for
one-time HW initialization/de-initialization in multi-execution
environment'. I was hoping for a brute-force way to determine which
execu
tion was the first or last (IOW: whenever # of executions was just 1).
I could then perform one-time setup/cleanup in a multi-execution setup
without having to convert everything over to Batch Model.

> In TestStand 3.0, the new UI Controls manage the list of executions
> that it creates and you can ask the Application Manager control for
> access to that collection.

Sound interesting. Although I need to use 2.01x for current project, when
is TestStand 3.0 coming out?

---
Joe

[Scott_Richardson]

Joe -
TestStand 3.0 just released and we announced it at NIWeek conference here in Austin just this week.

One way of handling the issue of init once a set of instruments is to create a new sequence file that has a sequence to init and a sequence to close the instruments. Assuming that you always terminate a sequence and do not abort them, you could add a ProcessSetup and ProcessCleanup callback sequences to the client sequence file that using these instruments. These callbacks are automatically called by the process model in both the Single Pass and Test UUTs execution entry points. The callback sequences could call the init and close sequences for the hardware. In the hardware sequence file you could reference count the number of ex
ecution that init and close by setting the file globals in the sequence file to be shared across executions and then add a numeric value that keeps track of references for the instruments. The init sequence adds to the count, and the close sequence subtracts from the count. The init sequence inits the HW if the count is 0->1 and the close sequence closes the HW if the count is 1->0.

This is one of many ways in TestStand that this could be done, not to mention that this could also be done in a similar way in a LabVIEW VI or DLL directly.

If you abort an execution then the reference counting idea above would fail to decrement properly. That might be ok for you. The above idea could be made more robust by using the Semaphore synchronization step type to do your reference counting.

Scott Richardson (NI)

[Joe Roberts]

Scott,

> One way of handling the issue of init once a set of instruments is to
> create a new sequence file that has a sequence to init and a sequence
> to close the instruments. Assuming that you always terminate a
> sequence and do not abort them, you could add a ProcessSetup and
> ProcessCleanup callback sequences to the client sequence file that
> using these instruments. These callbacks are automatically called by
> the process model in both the Single Pass and Test UUTs execution
> entry points. The callback sequences could call the init and close
> sequences for the hardware. In the hardware sequence file you could
> reference count the number of execution that init and close by setting
> the file globals in the sequence file to be shared across executions
> and then add a numeric value that keeps track of references for the
> instruments. The init sequence adds to the count, and the close
> sequence subtracts from the count. The init sequence inits the HW if
> the count is 0->1 and the close sequence closes the HW if the count is
> 1->0.
>
> This is one of many ways in TestStand that this could be done, not to
> mention that this could also be done in a similar way in a LabVIEW VI
> or DLL directly.

That sounds like it will work. I'll try adding a client count
increment/decrement in the DLL initialize and terminate functions. This
should essentially perform the same tasks as the callback scheme you mention
above, no?


The reason I didn't think the 'client counting' scheme would work initially
was I mistakenly thought that the termination function would not get called
under Terminate conditions. Since Terminate conditions happen a LOT during
our initial debug of new UUT types, I didn't think that would be acceptable.
I forgot that lacing the terminate funciton in a cleanup step group, I can
force it to be called in Terminate conditions.

> If you abort an execution then the reference counting idea above would
> fail to decrement properly. That might be ok for you. The above idea
> could be made more robust by using the Semaphore synchronization step
> type to do your reference counting.


Since in an Abort condition no cleanup code is run anyway, I don't think
this is a critical limitation. If the counter in the DLL the user should be
able to call Unload All Modules to clear the DLL from memory after Aborting
one or more executions. That way, I think next time its run the client
counter should be reset.

Thanks for the help. I'll try this out right away.

Thank for the info on TestStand 3.0, too.

---
Joe