Stopping Parallel Loops...

[krwlz101]

Ok,

So I realize that this is probably one of the most common quesitons on this board, however I would like to stop parallel loops in a specific way, and am having trouble comming up with an elegant solution.

I have a VI with 4 loops, one producer, one consumer, and two other state machines.  When I press stop, I would like each of the non-producer loops to finish their tasks, return to a "null" state, then stop.  When all three are stopped, I would like the main loop to stop, and release any queues.

The way I have accomplished this so far is to send a stop notification to each of the consumer loops.  The "Wait on Notification" function is placed in the null state, so that it can not stop unless it is finished.

Each of the 3 consumer loops has it's own notifier to send a message back to the producer loop when stopped.

The producer loop is event driven, and the stop event waits for all three "True"s to come back before stopping.

This just feels cluttered and ugly to me.

[krwlz101]

Here is the project.  Main Programv 1.1 is the vi in question.  I am still refining my labview practices, so I apologize that not everything is documented correctly.  If anyone feels so inclined, I would also welcome critique on the rest of the code as well.

[WayneS1324]

Thats just a project file.

To send the whole project, zip it and post the zipped file.

[krwlz101]

Here is the zipped file.

[cirrusio]

Whoops!  The project doesn't do a lot of good without any VIs! 😉

That being said, I have a couple of comments:

1. Four loops is a lot of loops.  I am guessing that there should be some consolidation that you can do but we don't have the VIs.  Unless you have several asynchronous processes that need to run deterministically, I bet you it will be possible to cut this number down.
2. You can use the producer/consumer queue (which probably responds to a stop request) to indicate to the other loops that you are ready for shutdown. Release the queue in the consumer and then check the status of the queue in the two remaining loops.  If the "Get Queue Status" function throws an error, simply have those loops respond by wrapping up their operations and shutting down properly.  See below:

Anyway, if you need more guidance or this doesn't work for you, put your code up.

Cheers, Matt

[cirrusio]

Sooo...It's not clear to me why you need more than two loops.  Is there some deterministic aspect that I am missing that prevents you from consolidating the two bottom loops in Main Program.vi or the bottom three loops in the version 1 program?  Or, you can move all of your operations in the Operation Loop into the event handler (I am not sure why you have chosen to break them up as you have) and then consolidate the remaining bottom two loops into a single one.  Then, when you hit stop you can have the event handler use a notifier to send a single value to indicate a stop.

Cheers, Matt

[cirrusio]

Here is kind of what I mean.  I did this quick and didn't bother to clean it up, so here is the Main Programv1.vi in all it's messiness ;).

[krwlz101]

Well,

I did have everything in 2 loops at first.  The main issue I was running into was that when trying to sample the DAQ at 10000 Hz, I kept getting errors.  I seperated out the DAQ part so that nothing could slow it down.  Do I need to run it at 10000 Hz?  Probably not, but I am thinking long term with this app.

I will agree that the update screen could be part of another loop.  That said, even with two loops, my main question remains unanswered.

[cirrusio]

I think if we are talking about two loops only, then the "main question" was answered a while ago in an article discussing different standard architectures.  And whether you need to operate at 10kHz or not (although if you are only monitoring temperatures I would suggest this is unlikely), two loops should be sufficient - one to handle the user interface and another to handle data acquisition.  I am guessing based on the way the Main Programv1.vi is currently designed that you were getting DAQ errors because you were asking the system to acquire one sample per channel at 10 kHz thus requiring your data acquisition loop to run at 10 kHz to keep up.  This would be impossible on any machine that is going to service an interface as the fastest you might possibly be able to run - barring any major CPU load - is probably 1 kHz.  But this would be purely non-deterministic as jitter would be introduced by the machine as it does many of the things that it needs to do that you have no control over.  If you are going to sample at 10 kHz and need the system to respond that rapidly (say to service over pressure conditions rapidly or control a PID), then you will need either FPGA or an RT system.  Either way, two loops should still be sufficient for everything you are asking to do.  This would just be standard practice.

Cheers, Matt

[JÞB]

---

@krwlz101 wrote:

Well,

I did have everything in 2 loops at first.  The main issue I was running into was that when trying to sample the DAQ at 10000 Hz, I kept getting errors.  I seperated out the DAQ part so that nothing could slow it down.  Do I need to run it at 10000 Hz?  Probably not, but I am thinking long term with this app.

I will agree that the update screen could be part of another loop.  That said, even with two loops, my main question remains unanswered.

---

If I am understanding the question as "How Can I know that a VI is DONE if that vi is contains a queue.  In my recient Community Nugget series: Application Development- I Propossed a model with 3 queues, 1 Event Queue and 2 message queues!  It was brought up in installment 1 that it is desirable to shut down a queue with a specific "Exit" command AND to provide some means of letting the caller know that the consumer finished.

"Queue Basics.vi" from the shipping examples shows a queue example.  The "Producer-Consumer (Data)" template is even better   BUT, if you NAME the queue you can get a reference in a sub-vi,  Here is a modified PC data template---

When the consumer EXITS its Error chain becomes valid!  so, If we sent an "Exit" command to the consumer AND we set STOP we close the execution of the consumer loop and the Producer loop.  Since both (error) chains are now populated the "merge error" primative can execute. 

HOLD IT ! "Naming" the queue lets me access a reference to that named queue ANYWHERE (in the app space)  !!!

Destyoying that queue makes any consumers execute the queue "default," but, a specific "Exit" command can execute shutdown code (like "stop- while loop") and do clean-up

Two way communications ("exit done") can be done via queue BUT LabVIEW is a dataflow language!!!!!! so the caller does not need a "Exit complete
" message. just a valid Output of the consumer.  Error merge works well in this situation