Complete newbie question here. First time using Labview so I apologize for asking this question: Is it possible to have multi channel contiuous acquisition? If so, does this have to go through a circular buffer to prevent tying up all the computer memory? Can you vary the scan and read rates for each channel? Last question: If it is possible to do all of the above....how do you do it? I've attached a .pdf file with screen shots of my front panel and block diagram....it's extremely crude just trying to get some basic concepts down. Also if anyone can recommend some good books on actually doing the wiring and conditions of the various elements, I'd be extremely grateful. Currently I have "Labview for Everyone".
Yes, you can easily do continuous multi channel acquisition.
Yes, a circular buffer is employed - you can set the circular buffer size to be whatever you believe is appropriate, but you must be able to read data out of the buffer fast enough to avoid a buffer overrun error.
If you are using a single data acquisition device, then there is only one scan clock so there can only be one analogue input process and the scan rate has to be the same for all channels (which you list). In your diagram you show two separate data acquisition loops - you cannot do this if you are using a single daq device (only one scan clock).
The buffer can be read at any rate and varying amount you like, as long as you read it often enough so that the buffer does not overrun. You read out of the buffer in scans (of your channel list) rather than channels.
Look at the LabVIEW "Examples" e.g. Examples>Hardware Input and Output>Traditional DAQ>Analog Input>Cont Acq&Graph(buffered).vi
I've used this sort of continuous multi-channel data acquisition quite successfully, to create an XY "oscilloscope" style display - it literally runs continuously, all day long.
Just one caution though: Windows PCs can, and do, run multiple applications and processes, many unseen - sometimes these tasks can hog the processor time, slowing down your LabVIEW application to the point where the DAQ buffering may inevitably overrun (unless you have a very large buffer, and can "catch up" again). In my application I just trap the occasional overrun error, and transparently restart the acquisition - this might not suit all applications (there would be data gaps/loss).
In my application, there shouldn't be a problem having a data gap in the event of buffer overrun. If I understand you correctly, I have a fixed scan rate but can vary my buffer read rate so the net effect is a varied output to the front panel.
I'll look at the sample you suggested. So, I need to setup a buffer for each channel of data being acquired then use individual "AI READ" elements to get the data out of the buffer. Is this correct?
You mentioned setting up the system where in the event of buffer overrun the system wouldn't shutdown but just continue acquiring and start over in the buffer. I would like to incorporate this b/c as I mentioned above a data gap is not critical.
Yes, the scan rate is usually fixed by the one on board scan clock (at rate you specify) - many DAQ devices also enable you to supply your own external scan clock source. If you list three channels, then a single scan clock "pulse/trigger" initiates a scan of the three channels. There is also a "channel clock" that controls the sampling interval between each of the channels in the channel list, but if not specified LabVIEW automaticaly sets this (in special cases, you may want to set it yourself).
You only specify one buffer (not one per channel), and you specify its size in "scans". You also read out of the buffer in "scans" (our example one scan=three channels).
Note, there is nothing to stop you listing the same channel multiple times within your "scan list" either consecutively, or variously interwoven with other channels - this can be a useful way of allowing extra time for particular signals to "settle" whilst avoiding the need to slow the entire scan rate down just for one fussy channel/signal.
Another note; for most DAQ devices you can also specify different "gains" per channel in the scan list (if needs be).
If I get a chance, I'll try to strip out the relevent bits of my application and post them for you to look at.
Think I got it now. So, the card makes a scan across all channels then throws them into the buffer as you read a scan out of the buffer the scan contains data from all the channels. If you specify to read out of the buffer lets say 1000 scans to plot in a wave graph does Labview plot the first scan then second and so on until you're at the 1000th scan for the first readout from the buffer?
In my case I'm bringing in 3 channels. When a scan is completed and put into the buffer does the data from each channel get indexed so when you read the data from the buffer you can display an individual channel? Something like: Index1 Index 2 Index 3 Scan#1 ABC XYZ LMN Scan#2 123 456 890
So, the data under Index 1 would represent scans from channel 1. So, I reference a specific index that would be displayed. Ultimately, I'm trying to have it so there's an individual graph + numeric indicator for each channel. So on my front panel I'd have 3 graphs + 3 indicators each displaying data from an individual channel. I've been able to get to display all 3 channels in a single graph but can't isolate the channels for a single graph.
Funny, I'm going to Austin this weekend maybe I should stop by National Instruments and see if there's a Labview class for dummies.
Well, actually it's just past 9:30 P.M. here in the U.K.
It sounds like you've got the basic idea - I would expect that you would want to feed the scan data read from the buffer into a "waveform chart" rather than a "waveform graph", the "chart" objects maintain their own history buffer and new data sent to the chart is continuously appended to previous data. The "graph" objects clear and plot afresh with each new data set.
I haven't used the "waveform" data format much myself; in my example the data comes out of the buffer as an array where each array "row" is the data from a single scan (the different channels), and each array column is effectively the values from successive scans for any particular channel. The data is in the same order as the order in which the channel scan list is specified. You will see in my example that I read from the data buffer, then split-up the various signals (array columns) to suit. I suspect you want to do pretty much the same, in order to display in seperate graphs.
Re: my example..
The first sub VI initialises and starts the data aquisition outside the loop.
The first sub VI within the loop reads from the buffer and divides up the data by signal/channel.
The second sub VI within the loop checks for a buffer overrun error, and if found then it restarts the aquisition (note: I've programmed it to give up and pass the error through if the error occurs three times in succession, to avoid a potential infinite loop occuring).
Just came back from the UK last fall stayed in London for a week or so had a great time. Next time I'm in the area pints on me..you pick the pub. My company has few facilities in the UK ever heard of Parker Hannifin?
I'm using an older version of Labview and it wouldn't let me open your example. Is it possible to save as version 6.1? If not could send a screen shot?
Yep, I know of Parker Hannifin - I get confused with all the company's various structure/divisions/changes, but I've used one or two "Digiplan" stepping motor controller/drives over the years. Still using some Digiplan kit dating back to the 1980's.
I work for Renishaw PLC, (www.renishaw.com) - we're based in the Cotswolds, half way between Bristol and Gloucester (the west side of England).
Hopefully, I've managed to save the VIs/LLB in version 6.1 - give it a try.
Nope, you're O.K., there's nothing missing - I deleted almost everything except what was relevent, leaving some trailing unconnected wires.
The VIs posted are the analogue input data aquisition core from a much larger block diagram. I didn't want to send all the program, as it contains about 20+ VIs, which only distract from the key issue (and also might show too much of our product build/test methods).
I left the trailing wires coming out of the "Get AInput Data2.vi" to illustrate the way that the signal channels are separated into seperate arrays ready for processing/display within the main loop.
Happy to answer any further questions.
P.S. Note: The LV "Route Signal.vi" function call within the "Init AInput2.vi" is not required - this is just routing an internal DAQ board signal out to some external sample & hold amplifiers in our test kit.