Aborting a Timed Loop - What Happens?

[CoastalMaineBird]

LV2013, LVRT 2013

I'm not clear on what happens when you STOP a timed loop, using the STOP TIMED STRUCTURE vi.

The help says:

"If you attempt to abort a running Timed Loop, the Timed Loop immediately executes the current iteration and returns ABORTED in the REASON output of the left Data Node."

Given the following loop:

I can abort this loop, by name, from elsewhere.

That abort occurs at any time, without regard to where this loop is in its cycle.

This loop runs at 10 Hz, and takes 1-2 mSec per iteration.

1... What happens if the abort occurs during the wait?  I would assume that it wakes up, with the REASON set to ABORTED.  Does it execute the code inside, or not?

2... Suppose the loop has already executed the SAMPLE vi, but not the STORE vi, when the abort comes.  Does it ...

(  ) 2A... Abort without executing the STORE ?

(  ) 2B... Execute the STORE, iterate again with REASON=ABORTED, then executes SAMPLE and STORE again?

(  ) 2C... Execute the STORE, iterate again with REASON=ABORTED, then skip out without executing again?

3... Suppose the loop is in the middle of the SAMPLE vi.  Is that VI aborted partway thru?

What's throwing me is the help text: " immediately executes the current iteration and returns ABORTED".  

If it aborted after it's woken up normally, then the REASON is already set, so it can't tell me it's been aborted.  But if it has to set the REASON, then it has to finish executing the code, then iterate AGAIN, then execute the code AGAIN, doesn't it?

Anybody know the rules for this ?

[nathand · Accepted solution]

I haven't tested this, I'm guessing based on a combination of documentation and experience in similar situations. It should always execute once with the reason set to ABORTED to give the code inside a chance to do any cleanup. If you're in the middle of an iteration, it will finish that iteration, then execute again immediately. If the abort is received during the wait, the loop immediately executes once (stops waiting). The last execution will always have reason set to ABORTED, and you'll never have a situation where the code is unexpectedly stopped in the middle of execution.

[natasftw]

I'd have to test to be sure.  From my understanding of that documentation, it will finish the current iteration.  I can't see any other meaning for "immediately execute the current iteration" other than that.

[Norbert_B]

Tested with LV 2014 (should behave the same). Answers in the quote.

---

@CoastalMaineBird wrote:
[...]

1... What happens if the abort occurs during the wait?  I would assume that it wakes up, with the REASON set to ABORTED.  Does it execute the code inside, or not?

The code in the TL will execute, regardless of the wake up reason. To prevent code from executing in case of an abort, use a case structure selecting the wake up reason.

2... Suppose the loop has already executed the SAMPLE vi, but not the STORE vi, when the abort comes.  Does it ...

(  ) 2A... Abort without executing the STORE ?

(  ) 2B... Execute the STORE, iterate again with REASON=ABORTED, then executes SAMPLE and STORE again?

(  ) 2C... Execute the STORE, iterate again with REASON=ABORTED, then skip out without executing again?

No idea how to check this one best, but it looks like 2B... In my test, i track the Expected Start and the Actual Start of the current iteration. In case i stop the TL, there is a difference. Always. So it indicates B.

3... Suppose the loop is in the middle of the SAMPLE vi.  Is that VI aborted partway thru?

Why should it? you don't kill the thread of the TL....

What's throwing me is the help text: " immediately executes the current iteration and returns ABORTED".  

If it aborted after it's woken up normally, then the REASON is already set, so it can't tell me it's been aborted.  But if it has to set the REASON, then it has to finish executing the code, then iterate AGAIN, then execute the code AGAIN, doesn't it?

I think the option B of question 2 is reflecting what you are looking for. As the next iteration starts without the TL to wait, the text in the help seems to be accurate from the point of view "TL".

Anybody know the rules for this ?

---

[CoastalMaineBird]

The last execution will always have reason set to ABORTED, and you'll never have a situation where the code is unexpectedly stopped in the middle of execution.

Further debugging seems to corroborrate this.  I was finally able to actually abort it while the loop was already awake.

It does finish the loop it's in, and do ANOTHER iteration.

The last loop  (the one with REASON = ABORTED) is untimed - i.e. it does not start from the timer, but ASAP after the STOP signal.

Thanks, nathand.

[CoastalMaineBird]

 it will finish the current iteration.  I can't see any other meaning

Yes, but it does MORE than that.  It will finish the current iteration, and then do ANOTHER iteration.  

It does HAVE to end with a REASON = ABORTED.

[CoastalMaineBird]

Why should it? you don't kill the thread

My only reason for suggesting that was the term "ABORTED", which means in other contexts to stop RIGHT NOW, even if you're in the middle (like using the STOP sign).

It does behave like an orderly shutdown, rather than an ABORT in that sense.

Thanks for your thoughts.

[CoastalMaineBird]

 the text in the help seems to be accurate from the point of view "TL".

Well, it's not quite complete though.  It doesn't mention the fact that it will perform ANOTHER iteration if it has to, just to provide the correct REASON signal.