Pseudo-queue Using Build Array

[Nathan_S]

I'm trying to get around having to use a queue by simply building an array.  I have values being written to a DAQmx Write in one loop at 50 ms, but I don't want to update the graph every 50 ms (for obvious reasons).  I'm using a functional global to pass the data to a slower loop at 500 ms. 

Problem is, I only get every tenth point.  Is there any easy way to build an array and pass (without overwriting or skipping data) to the slower loop without having to queue? 

Thanks for the help.

[ramses64]

Hi,

in your case, I would just use a queue : add in your queue each sample when you write to daq.
Add an other loop to update your graph when the size of the queue is greater than...

Best regards,

[smercurio_fc]

Your question is not clear. Are you trying to graph decimated data, or are you trying to graph the data that occurs are 500 msec, ignoring the data that was taken during the previous 450 msec? If you want to graph decimated data then you can use a set of VIs that had been previously posted on this forum. You can find an example here: http://forums.ni.com/t5/LabVIEW/plot-2D-arrays-on-graph/m-p/1412816#M548241

[crossrulz · Accepted solution]

Why not use a queue?  It is by far the most efficient way to do what you want.

What you ran into with the FGV is a race condition.  They way you used it, it might as well be a local variable or a global variable.  FGVs do NOT prevent race conditions in the way you are using it.  Here's a good article about race conditions from the LabVIEW Field Journal:http://labviewjournal.com/2011/08/race-conditions-and-functional-global-variables-in-labview/

[Nathan_S]

It looks like queue is the way to go.  I'll see what I can do.

---

@crossrulz wrote:

Why not use a queue?  It is by far the most efficient way to do what you want.

What you ran into with the FGV is a race condition.  They way you used it, it might as well be a local variable or a global variable.  FGVs do NOT prevent race conditions in the way you are using it.  Here's a good article about race conditions from the LabVIEW Field Journal:http://labviewjournal.com/2011/08/race-conditions-and-functional-global-variables-in-labview/

---

If you don't mind, can you elaborate on why FGV's don't eliminate race conditions?  I read the article and most of the comments, but I'm still not 100% understanding it.  Any help would be appreciated.

[crossrulz]

As stated in that article, FGV are only good for protecting CRITICAL SECTIONS of code.  The example from school was a bank account.  You want to deposit money.  So the program reads the balance, adds the deposit, and writes the new balance.  That is a critical section.  If somebody withdrawals while the deposit is happening, it could read the balance, subtract the withdrawal, and overwrite the deposited balance.  So you have the wrong balance at the end of the day.  Not good.  So what a FGV allows is to put these critical sections into a protected interface.  You call the FGV with a deposit task, and it does it.  It is also blocking the withdrawal task until the deposit is completed.  This is protecting the balance data from becoming corrupted.

Now the important part.  If all your FGV is doing is Reading to or Writing from the USR, it is behaving just like a normal global variable, race conditions and all.

After re-reading your earlier post, maybe you don't have a race condition.  But I don't know what your FGV looks like, so I can't quite make that call.

[Norbert_B]

You can use something like attached code (LV 2012).

But crossrulz is correct that using the FGV Ringbuffer in parallel loops (so access NOT sequentially in a well defined order), the complete meaning of this constract is obsolete!

You can, of course, add functionality to the FGV to address this, but the queue has already this feature, so why not use it?

Additional Note:

I didn't typify the "Operation" which is a bad thing in general. Additionally, i only adopted part of the NI style guides, so the code is NOT to be considered of being good quality!

Norbert 

[Nathan_S]

Thanks everyone.  I'll go with a queue.