LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Buffered Viewing of Waveform Charts?

We're acquiring very large data sets, using 'Cont Acq&Graph (buffered).vi' as sort of a template for the data acquisition.

The resulting files are much larger than physical RAM, but the researchers are only interested in small parts of the collected data: The researchers need to be able to go back over the data run, choose a few seconds here and there for permanent archiving, and then discard the rest of the data.

Because the size of the data run is larger than the physical RAM in the computer, the 'viewing and extracting' VI can read from file and display to screen [via a Waveform chart] only a few seconds of data at a time. Because hard drive access time is so much slower than RAM access time, I'd like to buffer this data view
[just a little to the left and a little to the right], so that if the researcher chooses to move a little bit back in time, or a little bit forward in time, the data will [probably] be cached in RAM and the VI won't have to make a relatively slow call to disk.

Of course, the art of buffering rapidly degenerates into a PhD level computer science mess [owing to not necessarily contiguous runs of not necessarily ordered data], and I really don't feel like writing a buffering algorithm from the ground up [especially not in a visual language like LabView].

I was hoping maybe the Waveform Chart might have some capability to perform [not necessarily contiguous and not necessarily ordered] buffering. Does anyone know if this is possible, or am I asking for too much?

Or should I just rely on the operating system [soft caching] and/or the disk controller/disk [hard caching] to perform my buffering [caching] for me?

Or do the standard LabView byte stream disk reading VIs perform thei
r own [not necessarily contiguous, not necessarily ordered] buffering?"
0 Kudos
Message 1 of 5
(2,984 Views)
 

It's looking like I'll have to write a linked list of Waveform datatypes to serve as the buffer.

Ughh...

 

0 Kudos
Message 2 of 5
(2,984 Views)
 

To be more precise, it will probably be a doubly linked list sitting in front of an array of Waveform datatypes.

Big ughh...

 

0 Kudos
Message 3 of 5
(2,984 Views)
The waveform chart does keep a history of the data passed to it. You can set the buffer length at program time. When you read the data (the data desired + buffered regions) from disk you can polulate the history by writing to the history property node. You can then postion the data in the chart with a property node. Be sure to make the x scroll bar visible. (right click on the chart >> visible items >> x scroll bar). I attached a VI in LV 7 to demonstrate.

There is no telling if relying on the OS and hard disk controller will give you desired performance. I do not believe the byte stream functions in LabVIEW do any sort of buffering either.

You will have to experiment to see what works. If you as the user cannot tell between experiments then
chances are the implementation does not matter.

By the way, LabVIEW does not support abstract data structures because it does not expose pointer operations to the programmer.
0 Kudos
Message 4 of 5
(2,984 Views)
A couple of thoughts:

- do the users need to see every single data point, or could you decimate the data somehow to give a representation that would still let them identify the areas of interest, but would fit in RAM?

- is this posting of any relevance?:

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000007FBC0000&USEARCHCONTEXT_CATEGORY_0=_49_%24_6_&USEARCHCONTEXT_CATEGORY_S=0&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0
0 Kudos
Message 5 of 5
(2,984 Views)