How to add additional actions to Pause and Resume

[Dillon_G]

I would like to modify the TestStand model, or sequence file, to perform some additional actions when the executing sequence it paused and resumed.  Specifically I want to pause and resume some functionality on my communications bus.  I located the PreCommandExecute Event which I could use to capture the pause/resume from within a custom OI; however, I would like to capture the event or modify a callback from within the TestStand environment itself so that it will still occur regardless of the interface that is executing the sequence.

Any ideas on how I might implement this functionally would be appreciated.

[Josh_W]

Dillon,

Unfortunately, TestStand sequences do not have any ability to respond to events.  So there is no way that I know of to implement this functionality in a UI-agnostic manner.  Maybe someone else on this forum has had a similar issue and can provide some suggestions.

[James_Grey]

This is possible. As of 4.0. the application manager is always available via Engine.GetInternalOption. A code module you call from a sequence (tool, process model, load calback, explicitly run sequence, etc.) can then use application manager to register for its events.  Unfortunately, once you factor in the threading issues this is a somewhat advanced undertaking and I don't have an example suitable for sharing or any instructions.

[Dillon_G]

James, I think that would work.  Unfortunetly, I'm using TestStand 3.5.

I created a code module to call the "engine.getinternaloption" method and register the event from within my sequence file.  I did notice that in 3.5 the method returns a null when an operator interface is not present, but that should not be a problem.  I am having a problem with firing the event however.  Within my code module I register the "PreCommandExecute" with "Reg Event Callback", but the event never fires.  Is there another step that I will need following registering the event or a possible conflict occuring with the OI?  The OI does not register the same event.

[James_Grey]

The events are multicast, so there shouldn't be a conflict with the OI. You could post a simple example of your code for here to see if anyone can see the problem with it. If no one responds, hopefully a TS support engineer will review it. They can escalate to the PSE and then to a developer (ie. me) if they can't find the problem. You can also contact support directly.

[Dillon_G]

Attached is the sequence file I am using.  I call a VI (LV8.6) at the start of my sequence to regester the callback.  I call this VI assynchronously and leave it running after registering the PreCommandExecute Callback.  I close the VI at the end of my execution.

I am currently running this sequence using the example OI's that ship with TestStand 3.5.  However, when I break/pause the sequence the event never fires.

[Dillon_G]

I had a small misswire from my notifier in the previous attachment.  I am still having the same issue with the event not firing however.

Message Edited by Dillon G on 05-06-2009 04:08 PM

[James_Grey]

I'm disappointed that there has been no response so far.

I'm not a LabVIEW expert, but I noticed that your example does get the events if you set the VI Properties>>Execution>>Preferred Execution System to User Interface. I suspect that might be a requirement for ActiveX callbacks.

[Eric_B.]

Hi Dillon G,

Sorry about the delay.  I have run that sequence file and I made the modification that James suggested.  I added something to the default case of your PreCommandExecute Event Callback vi to print the commandkind that is being captured, and the event that gets called when I click the pause button is command 71, not 72 like you are looking for.  71 is CommandKind_Break and 72 is CommandKind_BreakResume.  However, no event seems to be captured if the execution stops at a breakpoint.  Are you looking to handle breakpoint stops as well?

[James_Grey]

Eric,

You should only get a CommandKind_Break when the USER selects the break command, like from a menu item or button that is connected to the Break command. When execution hits an existing break point, that is not a "command", but there are other non-command events for detecting changes in execution state.

Message Edited by James Grey on 05-13-2009 04:48 PM

Message Edited by James Grey on 05-13-2009 04:49 PM