NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Some Executions Are Not Terminated by Using Terminate All in Parallel Process Model

Solved!
Go to solution

Hi,

 

This issue confued me recently, I'd like to use a parallel model process, and to terminate all execution at once.

If there's some action steps in the sequence, it seemed all execution will be terminated.

However, I put a wait function instead of action steps, there are some executions not terminated while I pressed the Terminate All button in the toolbar.

Hope someone can give me some help. Thanks a lot.

 

ps. the number of testsockets is set to 9 in my teststand.

0 Kudos
Message 1 of 12
(5,689 Views)

I'm sorry the attached sequence file is not good, it is eventually terminated.

The actual problem is like this attachment:

I'd like to use one of the testsocket to terminate all the other testsockets, the other testsockets are looping by the post-action before I terminate them.

When I start the termination, I'd like to do some actions in the cleanup.

There are 1~2 executions not terminated after the termination.

By the way, if I skip the wait function in the cleanup, termination all works.

I'm still really confused, could someone correct my understanding to the usage?

 

 

 

 

Download All
0 Kudos
Message 2 of 12
(5,675 Views)

Once you change the Number of Test Number to 9,

 

ModelOption.png

 

You'll found your program will terminate automatically.

 

TerminateAll.png

 

 

Ting

0 Kudos
Message 3 of 12
(5,612 Views)

William,

 

I agree with Ting that the executions will not terminate if you have less than 9 test sockets. I believe you mentioned that you had set the number of test sockets to 9, but can you confirm that this is the case?

 

I have tried to run the sequence several times, and have had all executions successfully terminate each time. How many test sockets fail to terminate on your machine each time, and is it the same sockets each time or does that vary? If the problem is inconsistent, it might indicate some type of race condition in the test sequence that we could debug further.

 

Also, I know your file is a TestStand 2010 file--are you using 2010 or 2010 SP1? You might also want to check the version in Help > About TestStand Sequence Editor so we can see if you have any of the patches installed.

0 Kudos
Message 4 of 12
(5,592 Views)

Thanks to Ting's and Daniel's reply,

It is too sad I still got some executions not terminated, like the attached image and video.

There are "usually" specified testsockets not terminated, but not always, it is clear between the attached image and video.

The version of the Sequence Editor I using is 4.5.0.310, I think it is not SP1.

 

Download All
0 Kudos
Message 5 of 12
(5,583 Views)

For TestStand 4.5, you might find it conflicts with some certain previously installed other application.

Did you install TestStand on a clean OS computer? Are you using a previously installed environment?

 

I suggest you to do the following step.

 

1. Try to run your sequence in a computer with clean installed OS and TestStand 4.5

 

2. If you still can't stop the sequence on TS 4.5, please try to run it on TS 2010 or above.

 

 

Ting 

0 Kudos
Message 6 of 12
(5,564 Views)

Hi, Ting,

 

Thanks your advice,

The problem arosed, for the first time, from the new-purchased controller, I think the OS might be clean for that time...

I tried to run the sequence via the TestStand 2012 sp1, but it still is possible to get the same problem.

I'm a little confused with the wait function in the cleanup, does it cause the termination unstable in my case?

0 Kudos
Message 7 of 12
(5,542 Views)
Solution
Accepted by William1225

I ran your sequence again and I reproduced the issue.

It seems the post action of the Pass/Fail Test polls the VI with full speed.

It will consume your CPU resource to 100%.

So I add some delay into the VI to prevent full speed polling.

Please refer to the following block diagram.

AddDelay.png

 

I tried it and it seems the problem solved.

 

Ting

0 Kudos
Message 8 of 12
(5,537 Views)

Hi, Ting,

 

Thanks for your help.

I'd like to add some additional remarks,

What I'd like to know is what cause the termination unstable in such a situation.

The timing seemed to play an important role, but it is not my orignal concern.

I used the testsocket of the last one to send the TerminateAll() command, but the choise is an accident...

Originally I take the first testsocket to send TerminateAll() command, it works "well".

I've notice the terminating action is always done in the reverse order of the testsocket(i,e, from the last testsocket to the first one),

it seemed to make each testsocket go to cleanup and then not allow the testsocket continue.

If we trace the executions more detailedly, it can be found the executions not terminated are actually received the command of the TerminateAll().

They went to cleanup, and waited for the following "not continue" procedure, but somehow it missed so that they survived to repeat the execution.

This consquence is a little like the termination is terminated...(not tongue twister...XD)

If my postulation is true, it is safe to put the TerminateAll() command to the first testsocket so that the latter executions will be terminated before the first one terminated.

If I put it to the latter testsocket or the last one, the termination will be terminated and some executions will revive.

If I skip the wait function in the cleanup, the situation is not optimistic as my thought, the last testsocket will revive itself and back to the terminate command to send it again so that it makes me feel that it is better if I skipped the wait function.

The above is my unconfirmed idea, maybe it totally wrong, if someone can correct my understanding I would be greatly appreciated.

BTW, it is really special case, so we can take it easy, hope this will not add your loading and we can discuss freely as an amateur:)

0 Kudos
Message 9 of 12
(5,488 Views)

Are you saying you want to wait in cleanup until all sockets are terminated and then do something? If so, maybe you should be using the batch model instead. The batch model is designed with the idea that all of the sockets begin executing and finish executing together. You can then use Batch synchronization to act like a rendezvous and wait for all sockets to get to certain locations in the flow of the execution. You can also use the Rendezvous step type directly with the parallel model, but if you situation better fits the batch model, batch synchronization is more automatic and easier to use then rendezvous.

 

Hope this helps,

-Doug

0 Kudos
Message 10 of 12
(5,459 Views)