Multi-threading with multiple while loops... trouble?

[altenbach]

Your AO depends only on a manual control. It would be sufficient to use an event structure and update the AO once at the beginning and then only whenever the value changes. Why do you feel you need to update it with the same value over and over and over again at a blazing rate???

[hecmar.arreola]

altenbach:

I understand everything up to your last paragraph.  What is a FIFO (first in first out?) and its application in LabVIEW.  Should I then pull all my DAQ in its own loop and push it into this FIFO?  Then read this FIFO in slower loops to do my file saving?  What about my data graphing?  Should my data be graphed inside the DAQ loop or inside a slower save loop?  I generally do an over-sampled averaging of all my data, hense my for loop inside my DAQ loop.  What are your thoughts on that and where it should reside?

This is all really good advice that I will take with me.

Marc A:

That is what I thought.

Thanks for the input!
-Nickerbocker

[hecmar.arreola]

Your AO depends only on a manual control. It would be sufficient to use an event structure and update the AO once at the beginning and then only whenever the value changes. Why do you feel you need to update it with the same value over and over and over again at a blazing rate???

No I don't want to do that at all.  Just have no experience w/ event structures but need to learn.  Good oportunity for me here.  Thanks!

BTW: w/ does the event structure need to be inside of a while loop?  I was looking at some examples and they have the event structure within a while loop which does not make sense to me.  Do I have to poll my AO control in order to know when to execute the event structure?

[Tom Haggerty]

The event loop will execute only once when an execution event happens.  The while loop allows the  event case to "reset" to look for another event.

Tom

[altenbach]

---

@Nickerbocker wrote:
BTW: w/ does the event structure need to be inside of a while loop?  I was looking at some examples and they have the event structure within a while loop which does not make sense to me.  Do I have to poll my AO control in order to know when to execute the event structure?

---

No, an event structure does not need to be in a loop, but it would make little sense not to place it in a loop because it would only execute once per run. 😉

Create a while loop, place an event structure. Right-click on the event structure and select "edit events..." Select "AO setpoint...value changed". Now place your AO update inside that case. Use the event terminal to get the new value. Wire the error boolean output directly to the stop terminal of the loop.

(You should update AO once before the loop with the current setpoint, because the even will not run until the first time the value changes. Since you use the event terminal inside the loop, you can use the control terminal here. No locals needed).

Now right-click on the event and "create new event". Select "stop...value changed". Wire the new value to the existing output  tunnel (from the error out n the other event) going to the loop stop terminal. (Look Ma, no local variables!).

Whenever the setpoint changes, the event fires and the AO updates. If the operation ends in an error, the loop stops. If stop is pressed in the other loop, the stop event fires and the loop stops. If none of these events happen, the loop is resting and you keep the same voltage on AO.

(You can also even remove all local variables and set the stop button to latch action!)

[hecmar.arreola]

Ok I get it and will try these things out.  Still not sure about FIFO and am searching LabVIEW help on it.

So the loop around the event structure is just to reset the "wait for the event" but it is not actually itterating the loop over and over again.  It executes once and hangs at the event structure until something happens...right?  This is starting to become clear to me now.  When I was first looking at the event structure examples I was thinking:

*now why would I loop around that? 
*How is that suppose to save me CPU cycles if I'm still polling my variable that initiates the loop? 
*How would that be different than a conditional structure that only fires when my AO setpoint changes?

Sometimes it would be helpful if the examples included in LabVIEW contained a little more explainatory text as what is going on.  That makes sense now.

[hecmar.arreola]

Can a FIFO only be used if I have the real-time module and only applicable to shared variables?

[altenbach]

---

@Nickerbocker wrote:
Can a FIFO only be used if I have the real-time module and only applicable to shared variables?

---

Easiest would be to just setup a queue. Write to it in one loop and read from it in the other.

[Ben]

"It executes once and hangs at the event structure until something happens...right? "

Exactly ....

Unless you have a timeout event defined. In that case it executes if there are no other events in the time out period.

Ben

[hecmar.arreola]

Attached is what I've come up with from all of your suggestions.  I am having some problems with the queue VIs, however.  Functionality wise it is working exactly how I would expect it to.  The enqueue vi adds elements to the queue while the other loop monitors how many elements are in the queue and when that element number gets higher than 5 it pops them while saving.  The problem is every time I hit "stop" I get the same error:

"Error 1 occured at Enqueue Element in learning.vi

Possible reason(s):

LabVIEW: An input parameter is invalid.  For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=======================
NI-488: Command requires GPIB Controller to be  Controller in Charge."

I have no GPIB controllers on this system... ???.  I have received the exact same error from the Release Queue and Get Queue Status VIs as well.  It is rather random.  The problem HAS to be related to the "queue" data type because that is all that is commonly wired to these VIs.  My code capture didn't capture the waveform constants right, but they look right on my system diagram.  Those waveform constants initialize the datatype for the queue and clear the Waveform chart.

Everything works fine as expected except for that error that always pops up when I hit the stop button.  Overall I'm really impressed with the code as it only consumes about 2-5% of the CPU instead of 100% now.

Also, I'm still not happy with how ungraceful my loop stopping is.  Everything is fine and dandy until I try to incorporate stopping all the loops in the event of an error in any of the loops.  For some reason the above error doesn't trigger a loop termination....it just happens when I hit "stop."  Hmmmmm........

Any additional help is always welcome.

-Nickerbocker