Stop parallel loops

[iozana]

Hi,

Attached herewith is my VI code (passing data through Queue- Indicator Array reacts to Control Array changes).

When I'm trying to stop the parallel loop, I think I create latch that infect the next running section (use Prob around etches "Or" in etch loop):

1. Set numbers at Control Array: 55, 66, 77, 88.
2. Press Run- see it works (Indicator Array reacts to Control Array changes) (both loops 'x', 'y' ,'x OR y'=false)
3. Press STOP-TX will stop, RX will keep running (?)-> Highlight will show nothing-> press Abort (TX loop: 'x'=false, 'y'-true ,'x OR y'=true, RX loop: 'x'=false, 'y'-true ,'x OR y'=false (?))
4. Press Run-TX will run, RX will stop-> (TX loop: 'x'=false, 'y'-false ,'x OR y'=false, RX loop: 'x'=false, 'y'-true ,'x OR y'=true (?))

How can I stop all loops simultaneous?

I addition, How can I set the "Indicator Array" to 0 at first start only (I don’t want to use any of previous running data) 

For instance, let's say: TX delay=1000, RX delay=100 => I want to see 0 until 1000msec.

Thanks a lot,

Idan

[P@Anand]

Your loop did not stop why?

You have left the timeout terminal in the De queue as -1 that will wait indefinitely since the 1st loop stops and there is no more data will be sent. so a time out value is required.

For making the indicators to be zero at initial in the VI properties>>Execution>> select Clear Indicators when called.

Try the VI attached... Good luck.

[iozana]

Hi,

You said that I must enter value into the timeout in ms but I don’t think this is quite accurate.

I think that the loop will end when the RX delay/ TX delay will finished, regardless the Timeout value.

For instance, if I'll write "RX delay"=500 and the "Timeout in ms"= 1000 the loop will still last max 500msec, am I right?

Thanks, Idan

[DianeS]

Nope.  Your assumption is incorrect.

P. Anand is correct.  After the "Enqueue Element" loop stops, your "Dequeue" function will sit patiently and wait for more data.  Your "Dequeue" loop cannot finish its current iteration until the "Dequeue" function runs.  The "Dequeue" function will never run once the "Enqueue" function stops running, because you've told it to wait indefinitely for data.  So you are incorrect in the assumption you state in your last post.  ALL of the functions inside the loop must finish execution before the loops can iterate.

Your "Dequeue Element" function will not error out when your "Enqueue Element" loop stops.  Why?  Because you are releasing the queue after the "Dequeue Element" loop.  Therefore the queue reference will remain valid until the "Dequeue Element" loop stops.  Therefore "Dequeue Element" will do exactly what it's doing...sit and wait for more data.

You do need a timeout on "Dequeue".

Finally, your bottom loop will either execute once -- if your "Obtain Queue" function returns an error -- or never stop executing, if your "Obtain Queue" function does not return an error.  The value of that error wire does not change as the loop iterates.  Use the output error wire of "Get Queue Status" to stop that loop. 

See attached.

[Mark_Yedinak]

---

@DianeS wrote:

Nope.  Your assumption is incorrect.

 

You do need a timeout on "Dequeue".

---

I generally do not like using timeouts on a dequeue because you basically turn an event driven system into a polling loop. I like to avoid the unnecessary processing involved to check for and filter phantom data. Yes, if the timeout occurs you do get a data element from the queue. It will be the default data. I prefer to have the controlling task release the queue on exit thereby causing an error to occur on the dequeue. The best method would be to have a specific Exit/Stop message that gets posted to the queue.

Timeouts result in potentially a lot of CPU usage to do no work.

[WayneS1324]

I believe that DianeS was referring to the specific problem iozana is having... Not programming practices.

[DianeS]

Wayne...you are quite right.  I was indeed.

Mark, I see where you are coming from but I'm not entirely sure I agree.  Let me think about it some more and then it would be a good discussion to have.

[Mark_Yedinak]

---

@WayneS1324 wrote:

I believe that DianeS was referring to the specific problem iozana is having... Not programming practices.

---

While I agree that adding a timeout will indeed allow the dequeue loop to detect the stop it will suffer from displaying bad data each time a timeout occurs. Code would need to be added to handle and process the timeouts so you don't act on invalid data. This is effect turns the consumer into a polling loop and you lose the benefits of an event driven system. The code Diane posted may introduce other problems for the original poster for the reasons I just stated.

[WayneS1324]

Your method works well for an event driven system. Iozana didnt mention anything about an event driven system.

He/she just couldnt figure out why the loop wouldnt stop. Dianes answer was right on.

The best programming methods are the best (preferred) methods for that person. Its all relative.

However... I do acknowledge CPU saving methods.

[Mark_Yedinak]

---

@WayneS1324 wrote:

Your method works well for an event driven system. Iozana didnt mention anything about an event driven system.

He/she just couldnt figure out why the loop wouldnt stop. Dianes answer was right on.

The best programming methods are the best (preferred) methods for that person. Its all relative.

However... I do acknowledge CPU saving methods.

---

A queue by definition is an event driven construct. By defition tasks wait on a queue until data arrives, hence the reason the default timeout is -1 (wait forever). Yes, the timeout will allow teh check for the stop. However, if the task producing the data and the processing task are not synchronized and therefore it will process arbitrary data. Without the code to check for a timeout this won't work much better than a local variable in polling loop. In fact, it would be worse since you would be working on the default value every time a timeout occurs. Part of posting to the forums is to educate new porgrammers. Polling mechanisms can be useful and have their place. I don't believe they should be implemented using queues specifically for the added code required to process the timeouts.