Question related to stopping sub vi loop

[Gaffinator]

I have a Main Vi that calls a DAQ engine sub vi using the asynchronous start and wait methods. My main VI is going to be used to display analog in voltage to a chart as the engine is running. My issue is that I'm not sure how to go about stopping the read portion of my DAQ engine from the main vi. I see that I could use global variables, but where I work they are kind of against using globals. 

Sorry if anything i said is unclear, I am a novice in labview and just looking for some good examples or tips

[sherlockholm]

Gaffinator,

Just off the top of my head you could use a Functional Global Variable. These are similar to Global variables, but help get rid of race conditions that global variables cause.

You could also use something like an occurrence. These are similar to queues, or notifiers, but are very basic form of these. There is a LabVIEW example of this in the example finder.

Hope this helps!

[crossrulz]

In general, you should have some type of messaging system to your asynchronous processes.  I tend to use a Queue or User Event for sending messages.  In this case, one of the messages would be "Stop".  In similar situations, I often will have messages for "Start" and "Pause" as well.

[Gaffinator]

Hey thanks for the reply!

Is there any way you could show me some kind of example for using user events to pass messages to my DAQ engine?

[crossrulz]

---

@Gaffinator wrote:

Is there any way you could show me some kind of example for using user events to pass messages to my DAQ engine?

---

My recommendation is to have a good look at the Delacore Queued Message Handler.  But here is a simple demo I put together for a presentation I have done (saved in LabVIEW 2016).

[Bob_Schor]

---

@crossrulz wrote:

---

@Gaffinator wrote:

Is there any way you could show me some kind of example for using user events to pass messages to my DAQ engine?

---

My recommendation is to have a good look at the Delacore Queued Message Handler.  But here is a simple demo I put together for a presentation I have done (saved in LabVIEW 2016).

---

I was going to write "But why did you make the Event a String?  And how are you stopping all those loops?", and then I noticed the Stop Event -- very clever, and an illustration one Stop and multiple "effects", a one-to-many communication path.

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

I was going to write "But why did you make the Event a String?  And how are you stopping all those loops?", and then I noticed the Stop Event -- very clever, and an illustration one Stop and multiple "effects", a one-to-many communication path.

---

It is usually short sighted to have a Boolean for a message.  You will later find you need to send more and different messages.  Instead of adding more buses, just reuse the one we already have that I am sure is not being utilized 99% of the time.

As an aside...I often run into people who use the Producer/Consumer and stop the consumer when the queue is empty.  This is BAD because you might be stopping prematurely.  You should have some type of message in your queue to tell the consumer when to stop.  Of course, Bob doesn't have that issue because it is built into Channel Wires.

[Bob_Schor]

---

@crossrulz wrote:

As an aside...I often run into people who use the Producer/Consumer and stop the consumer when the queue is empty.  This is BAD because you might be stopping prematurely.  You should have some type of message in your queue to tell the consumer when to stop.  Of course, Bob doesn't have that issue because it is built into Channel Wires.

---

I agree!  But before there were Channel Wires, there were Queues ...  I've advocated using a Sentinel to stop the Queue, which works very well with Data Queues (where the Queues are Arrays).  When the Producer (which is "running the Show" by Producing the Data) decides to quit, it simply exits its loop and sends one last packet, the Sentinel, consisting of an Empty Array (the Sentinel only needs to be unique, but the Producer should never ordinarily send an Empty Array ...).  The Producer then stops using the Queue.  The Consumer, when it Dequeues, checks for an Empty Array -- when it sees it, it "knows" the Producer is finished and won't be sending any more data, so the Consumer can also exit, and, since the Producer has stopped and the Consumer has just decided to stop, the Consumer can Release the Queue, completely safely.  If there are only the two loops, the Sentinel is a perfectly safe way for the Producer to stop, and "send a signal" to the Consumer to stop.

[mcduff]

---

@crossrulz wrote:

---

@Gaffinator wrote:

Is there any way you could show me some kind of example for using user events to pass messages to my DAQ engine?

---

My recommendation is to have a good look at the Delacore Queued Message Handler.  But here is a simple demo I put together for a presentation I have done (saved in LabVIEW 2016).

---

+1 for User Events

1 recommendation though, you probably do it already, but when sending string commands I like Case Insensitive Match, so STOP, Stop, StOp, ... will work.

Case insensitive matchmcduff

[crossrulz]

---

@mcduff wrote:

1 recommendation though, you probably do it already, but when sending string commands I like Case Insensitive Match, so STOP, Stop, StOp, ... will work.

---

Absolutely.  I abuse that functionality.  Do note you will have a slight performance hit.  But the protection from miscapitalizations is worth it.