LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to limit an array size?

Note that when you Obtain Queue, the Max Queue Size is the maximum number of Queue elements you want to store.  Snce your Queue Element is an Array (possibly 9 Dbls = 72 bytes), a Queue of 100K is 7.2 Mbytes.

 

I'm not sure what you are doing with your DeQueue loop.  Once a second, you empty the Loop into an array "Elements", continually overwriting it (what's the point?).  You never get around to saving it, it is just a huge buffer that keeps growing until it is full, then "circles" itself.

 

I've forgotten -- what are you trying to do here?  You've got the makings of a nice Producer/Consumer design -- if you wanted to stream your data to disk, for example, you could use a "normal" Queue (without specifying the size, i.e. "all that I need"), and start filling it.  Assuming your disk can write faster than your Queue can fill, the bottom loop simply does a Dequeue/Write Element until it is time to stop.  For this to work, you want to open the output file before entering the Consumer, only write in the Consumer, and close the file when the Consumer exits.

 

And that's another point -- how does the Consumer know when to exit?  Simple, the Producer tells him/her.  The way I do this now is to not use a Queue, but to use a Stream Channel Wire, which has two Boolean flags that the Producer can set to tell the Consumer that no more data are coming, safe to close.  Before there were Channel Wires, I used a "Sentinel", a unique Queue element (here I'd use an Empty Array) that the Producer would send after it was done.  The Consumer would check each Dequeue to see if the Sentinel was present (i.e. check for an empty Array), and if so, would skip processing and exit the Consumer.  And the Consumer would Release the Queue.  Much better than the former NI method of having the Producer Release the Queue, causing a (deliberate) Error in the Consumer, which was programmed to exit on Error.  But what if it really was an Error?

 

Bob Schor

Message 11 of 14
(614 Views)

@Bob_Schor

 

The queue size is 100k elements, and each element is an array with 9 elements.

I would prefer if it was a 2D array with 100k rows and 9 columns... but I can live with the 1-D Array of Cluster of 1-D Array.

The process becomes a bit clunky (because of Index > Bundle > Index), but it's OK

 

And the second loop does not have a dequeue, but only a function "Get Queue Status" that returns all elements of the array

These "elements" will enters a subVI that plots data in XY Graph (can't use waveform chart or graph because dt is not constant and need to plot non-time X-Axis is a few graphs)

 

In the end, what I'm trying to do is to store in the Memory RAM 100k values of nine variables obtained from a PLC, then use these 100k values to plot XY Graphs

 

About saving data. Don't need to save the buffer data, because I'm saving these 9 points in a .txt each iteration (subVI not shown in my examples). So the buffer only to plot graphs to the user.

 

And the exit I'm doing according with the examples shipped with LabVIEW 2012

Don't have the option to use "Stream Wire" (LV2012) and read somewhere in this forum that some known users don't like "Stream Wire"

If the Queue have an error, I think it's OK to end the loop, even if it's a "real" error. Because the software will not work without the Queue anyway

 

1st loop store data, 2nd loop plot data (I'm working in the subVI)1st loop store data, 2nd loop plot data (I'm working in the subVI)

 

 

@Hooovahh

I will definitely take a look into these circular buffer structures. Does it uses the same amount of CPU resources of the "Lossy Enqueue"?

 

 

0 Kudos
Message 12 of 14
(603 Views)

@mthheitor wrote:

 

@Hooovahh

I will definitely take a look into these circular buffer structures. Does it uses the same amount of CPU resources of the "Lossy Enqueue"?


There are various trade offs in play with these APIs.  My version tried to have a speed performance, at the cost of extra memory requirements.  It also focused on a situation where you write much more often then you read.

Message 13 of 14
(595 Views)

As mentioned here, do you really need to plot 100k * 9 points on a graph? This makes no sense.

I suggest that you limit the amount of data displayed to a more adequate value. For example, 200-300 points per plot.

 

If your data was arriving at an inconsistent rate, then using queues would be a good solution.

You also mentioned that XYGraph is a separate SubVI. Using queues allows you to get rid of data transfer between subVIs through an array.

Just open a connection to the same queue in the "display" SubVI (with the same name and data type), read the elements of the queue directly, and display them.

 

You can do the same in SubVI, which periodically saves data to a txt file. For example, using the Preview Queue Element function.

Producer.pngConsumer.png

Download All
Message 14 of 14
(553 Views)