05-18-2010 02:26 PM
Since you would be calling CancelTermination() from a Post-Step engine callback, the note in the help about deadlock does not apply to this situation. You should probably be checking whether or not the execution is terminating before you acually call CancelTermination(). This can be done using Execution.GetStates().
Hope this helps.
05-18-2010 02:48 PM - edited 05-18-2010 02:50 PM
Manooch_H wrote:Since you would be calling CancelTermination() from a Post-Step engine callback, the note in the help about deadlock does not apply to this situation. You should probably be checking whether or not the execution is terminating before you acually call CancelTermination(). This can be done using Execution.GetStates().
Hope this helps.
Thank you for the assistance Manooch, you have been very helpful. I have now implemented everything technique that I require for the application in TestStand.
I have attached my testing VI which demonstrates the use of aborting a step immediately and jumping to a new step index.
Is there anything I should watch out for when using this technique?
05-18-2010 03:58 PM
Rather than using the VI Asynchronous step type, I recommend spawning a sequence in a new thread and calling your asynchronous VI from this sequence using a normal LabVIEW step. Additionally, I think that it makes more sense for you to set the next step index from within the Post-step engine callback than before you even call terminate. This will help prevent an unwanted change in the step index at an incorrect time.
I've attached your file with the few changes I've mentioned above. I think you are on the right track but at the end of the day this is a simple example. As you are implementing your actual system/solution, feel free to keep using the forums as a method of getting feedback on your architecture.