11-11-2009 12:48 PM
Hi,
I need to aquire a digital and analog signal simultaneously for 5 mins at 5Ms/s without any gaps in the data,and I'm confused about how to do this. I'm using a PCI-6110 card, and trying to use DAQmx to program the acquisition. I also tried ccreating a large memory buffer to store the data, and tried to transfer the two lines out of the acquisition loop using queues.
From what I can understand though, it looks like the sucess or failure of the aquisition depends on how fast my loop runs? IFor example, without using the queues, I get an Error -200279
"Measurements: Attempted to read samples that are
no longer available. The requested sample was previously available, but
has since been overwritten.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem."
Right now Ican't even get the acquisition to start usingn a simulated deevice, and my block diagram is pretty contorted looking. This is my first time usig DAQmx (Though I've used NISCOPE and FPGA extensively), so I'd appreciate any DAQm specific pointers. There must be a better way to simply record two data lines than what I'm doing.
Thanks
11-11-2009 12:59 PM
Another point is that I'm trying to acquire events that hapen at 40 Hz, so thee aquisition really can't depend on variations in my computer speed. One glitch of a few ms could make me miss an entire event
Thanks
11-11-2009 01:06 PM - edited 11-11-2009 01:08 PM
Try wiring the "samples per channel" that is going to your DAQmx Sample Clocks to the "Number of Samples Per Channel" in your DAQmx Read VIs.
The Read VIs need to know how many samples they are waiting for before reading. Try lowering this number if you have problems. Each loop should run once a fifth of a second.
A few concerns after looking at your VI (not related to your original question):
1. The way you are stopping your threads can lead to a race condition. Consider closing the queues after the stop button is pressed for your main thread, and using the "error" output of your queue VIs to stop the other threads. When the Queues are released, the queue VIs that reference them will generate an error and will close the threads. That way you don't have to use any local variable booleans.
2. If one queue is hanging you will have problems. You may want to consider adding a timeout to those queues.
3. Your plots are only going to show the last 1/5 second worth of data and not continuous data.
4. Your Analog and Digital data will not be in-sync if that is what you are after.
11-11-2009 01:09 PM
Hmm..
Yeah, I also need the analog and digital data to be in sync.. I was originally going to put the Read vi for the two in the same loop, but then figured that the digital data would still be data acquired after the analog data. Is there a way to REALLY have them in sync?
Thanks
11-11-2009 01:13 PM
Another question Nickerbocker,
I was planning to concatenate the data to the end of a file (every data segment acquired at 1/5th a ssecond intervals) How much of a time gap could I expect between these 1/5th segments, and is there a way to reduce/eliminate it, so that when I concatenate it, there's no more than 1 ms or so of missing data?
11-11-2009 01:14 PM
Your question is beyond my expertise (I'm a if it happens every 250ms I'm happy kind of developer, lol).
Umm... not sure if it will work, but can you possibly acquire the digital signals via the analog inputs? That way it is all coming from one DAQmx task?
The kind of percision you need is out of my DAQ level. 😛
Hopefully someone with more experience will chime in to help you get-in-sync ;).
11-11-2009 01:16 PM
11-11-2009 01:17 PM
noli wrote:Another question Nickerbocker,
I was planning to concatenate the data to the end of a file (every data segment acquired at 1/5th a ssecond intervals) How much of a time gap could I expect between these 1/5th segments, and is there a way to reduce/eliminate it, so that when I concatenate it, there's no more than 1 ms or so of missing data?
I think that the buffer on your hardware should prevent any gap in the data. Also, your method of handling the data in a seperate thread is the right approach.
11-11-2009 04:12 PM - edited 11-11-2009 04:21 PM
Ah, the 6110 does not support hardware-timed DIO. Therefore you cannot configure a sample clock for the DIO and expect to have it mean anything. I expect that loop is erroring out.
Therefore, since you have to software time your DIO, you aren't going to be able to synchronize it with your AI. Nor are you going to be able to collect it at 5MS/s. Nor are you going to be able to acquire it as a waveform. I expect that's one of the reasons you're having so much trouble. You're telling the card to do something that it can't do.
As for your AI, it is definitely hogging up the entire CPU (at least, it does when I simulate it - I should specify that I added a loop delay when I ran it). Can you try working at a lower sampling rate to start with? I don't have time to delve farther into it now but will try to mess around with it later tonight.
11-11-2009 04:45 PM
Hi Diana,
Thanks for your notes... that's somewhat disappointing regarding the card's capabilities. I've taken Nickerbocker's advice and made everything as a 2-chan analog input, and the block diagram looks much cleaner also. I think it should work mostly, except that now when I simulate it, it tells me after a while, "Not enough memory to complete this operation", and I get a memory allocation error
Error -50352 occurred at DAQmx Read (Analog 2D DBL NChan NSamp).vi:1
The requested memory could not be allocated.
I'm also simulating my device right now, since I'm not at work.. I don't know if that's a part of theh problem or what..
I could add a delay to the AI acquisition, but if I do that will it leave gaps in my data collection, when I concatenate it all together?
I'm not sure of how low a rate I can sample.. I was originally sampling at 100Mhz with NIScope, and developed an algorithm to do tomographic reconstruction from the data. 5Ms/s is already a cut back, and I'm not "totally" sure the reconstruction algorithm will work at this low rate.
I have uploaded an updated version of my program
Thanks!