Parallel loops

[VeeJay]

Please refer the attachment. Why do these parallel loops stop completely, sometimes and sometimes, only the loops with lesser wait time stop while the one with higher wait time keeps looping? Is there anyway to stop all the three loops if any event in any of the three loops occurs? By event I mean some sort of safety check or limits violation etc. I do not want to use event structure because I am not comfortable with using it.

V

[Darin.K]

Sooner or later you will need to use an Event Structure, I suggest sooner.

I often use Notifiers to stop multiple loops.

With your code, the mechanical action of the stop button is latching, so sometimes when the value is read via the property node the switch returns to False before the slow loop gets around to reading it.  Change it to Switch When Whatever and it will behave as you expect.

[tbob]

Here is a way to use Notifers as Darin suggested.  No need for an Event structure in this simple case.  Also, the stop button can be a latch type.  If things get more complex, an Event structure may become necessary.  Also, a queue can be used to send commands from one loop to other loops (master-slave architecture), with Stop being one of the commands.

[ErnieH]

The code you have should work. I can see a problem if the button is set to 'switch until released'. Local variable would work also. Of course, the solutions offered earlier are better.

[Darin.K]

Must be time for a coffee break, the fact that the OP is using a Property node with a Boolean means that the Mech. Action is set to switching so disregard my hypothesis.  Must be some double-clicking going on, and pretty fast at that.

As beaten into the ground at this point, there are much better alternatives anyways.  Local variables should be used very sparingly, and the Value property node used only when locals have been ruled out.

Message Edited by Darin.K on 05-18-2010 03:16 PM

[tbob]

---

Darin.K wrote:

... Local variables should be used very sparingly, and the Value property node used only when locals have been ruled out.

---

That is why I used Notifiers in my example.  It works very well.  And you can still have the switch mechanical action set to latch.  When the vi is done, the switch reverts back to false.  No need to re-init.

[MarcoMauri]

As already pointed out the code is not elegant but should work (provided you don't re-click the button before the loops are all stopped).

Stronger ways to stop paraller loops make use of occurences (my favourite), queues or notifier, as shown by tbob

(p.s. to see the counter going on you have to set a proper timeout to the Wait on notification vi)

Marco

[VeeJay]

Thank you all so much for your replies. I really appreciate it. I am trying to modify an existing code (more like revamping it) and it is already too complicated to begin with. I have tried my best to use state machines and parallel loops and on top of that I thought adding an event structure will delay my progress because I still don't have a grasp of that concept except when there is some mouse or keyboard click. Nonetheless: I like the notifier option and I will incorporate that in my code.

Please let me know of any good tutorials on event structures that covers many event situations. One on NI website is esoteric and until I am at the top of my game using LabVIEW, I dont seem to get the hang of it.

V

[VeeJay]

Also, I have one more question. Does it make sense to use Serial communication and Queues together? Apart from these three loops, I would have one more loop that receives Commands from Serial port and that loop has to send the commands to two (1 and 3)of these three loops  and will also receive feedback from  two (2 and 3) loops.

Should I use the VISA serial vi to receive commands and put them on a queue and then de-queue them and send to the receiver?   Also, how would I synchronize Acknowledgements for commands received back through RS232?

eg. VISA receives A0h -> queue A0h (in Serial control loop) -> De-queue A0h (at receive loop) -> A0h translates to starting the test 

      ACK for A0h is B0h 

V

[tbob]

Yes that would be good architecture, using a loop to receive responses and using a queue to send the response to another loop to be processed.  This is called a Producer-Consumer architecture. 

If you need to send acknowledgements back, you will have to modify the architecture a little.  You could probably use a second queue to send the ACK value from the consumer loop.  The producer loop would have to read the second queue and if it finds a value, then send it to the serial port.  Hence your Producer-Consumer would be a two way street as opposed to a normal one way street.  Hmmm.... so we couldn't call it a Producer-Consumer because both loops produce and both loops consume.  We could just call it parallel processes. 

If you need help to code, let us know.  I could come up with some basic code for an example.  But try it yourself first.  Thats the best way to learn.