03-12-2009 05:43 PM
03-12-2009 05:51 PM
03-12-2009 05:57 PM
03-12-2009 06:03 PM - edited 03-12-2009 06:06 PM
03-12-2009 08:12 PM - edited 03-12-2009 08:13 PM
This is a simple way to do it with a Notifier. A side benefit is that the first loop times the second.
03-13-2009 04:32 AM
Such two-loop structure is not reliable. If the upper loop reads the STOP control first, the bottom loop does not stop. To test, increase the constant in the bottom loop (f.ex. to 1000 ms).
03-13-2009 05:26 AM
03-13-2009 06:41 AM
03-13-2009 07:16 AM
_Y_ wrote:
VENKATESH… ,Such two-loop structure is not reliable. If the upper loop reads the STOP control first, the bottom loop does not stop. To test, increase the constant in the bottom loop (f.ex. to 1000 ms).
_Y_
Only if you kill the Queue <BEFORE> the bottom loop reads from the queue.
Although you click stop and it will stop the loop, it will still enqueue the True value, which is then read from the bottom loop.
A trick is to kill the queue at the exit of the bottom loop.
I like Jim's solution. It is missing the kill queue reference, which can be implemented in 2 ways. After the bottom while loop, or after the top loop if there is additional delay outside the loop to take in consideration the amount of time to guarantee that the bottom loop reads the last queue element.
OR (better yet) Jim's implementation, with the kill queue immediately after the top loop and the add an OR statement in the bottomwhile loop that connects the status of the error cluster which should return an error if it tries to read the queue after the queue has been killed.
R
03-13-2009 07:29 AM - edited 03-13-2009 07:29 AM
The design pattern templates NI provides use the error wire from the Dequeue Element function to stop the bottom loop. Doing that lets me use the Notifier to pass any data type (doesn't need to be boolean) to the bottom loop, or not pass anything at all (just use it to stop the loop). Queues would work just as well.