PCI-MIO-16E4: simultaneous or sequential sampling of channels??

[JTed]

I am using a PCI-MIO-16E4 board to sample pressure transducers on four different channels. I can't seem to work out from the literature whether this board samples all four channels together, each scan, or if it samples them one at a time.
I am hoping it samples them simultaneously. Although the Labview measurements manual definitely says "some" DAQs sample simultaneously, it does not go on to explain which ones!
If it cannot sample simultaneously, then I guess the shortest period of time between each of the four samples, is dictated by the 250,000 samples/sec  rate of the board, ie 0.004 ms?? This amount of delay might be ok, but I'd much rather be sampling all four at the same time. Anyone care to enlighten me?!

Thanks
Theo

[WM_John_Weeks]

That device samples sequentially.

[JTed]

Thanks, John

That's not ideal, but it's probably not the end of the world. So, am i therefore right in thinking that the shortest possible time period between each channel sample is 1/250,000, or 0.004 milliseconds (250,000 samples/sec being the scan rate I've seen quoted for this board)?
Forgive the naive questioning, but I'm very new to Labview and DAQ systems! Then I guess my four channels take 3 x 0.004ms = 0.012ms to complete a scan?

Cheers
Theo

[Matt_Sweetland]

Hello JTed:

Yes, some of our boards do acquire data simultaneously... Our S-series boards allow you to do this.  Our M-series and E-series boards have one analog to digital converter(ADC) which each channel is multiplexed to, allowing inputs to be taken only in sequence though the delay is small.  The S-series boards have a dedicated ADC for each channel allowing for measurements to be take simultaneously. 

I hope this clarifies the issue for you.

Regards,

Matt Sweetland

NI Applications Engineer

[JTed]

Matt, that's great, cheers for the explanation. I assume my calcs above are right, so yes, the delay is very small. I'm actually measuring variation of in-cylinder pressure in a four cyl diesel engine. The four channels are read every half degree of engine rotation - you can imagine that at any appreciable speed half a degree of rotation doesn't take a very long time! So, short as the delay may be, i estimate that the period of time to read four channels is over 15% of the scan period, even at a fairly low speed ~ 1000rpm.  I'd really like all four channels to be read at exactly the beginning of each scan, but since that clearly requires a different board, I don't think that's a short term option!

On a related note, I seem to be having a very strange problem with how the four channels are being written to the buffer - if I use the AI Read vi to output what is written to the buffer each revolution, and then output that to a spreadsheet or similar, I'd expect to see four columns, one for each channel, each column being 720 elements long, for the 720 half-degree pressure readings in each rev. BUT, for some unknown reason, I am presented with 16 columns, with the first channel data being duplicated four times, then the second, then the third and fourth. However many of my channels I specify to read, the output is always duplicated four times over, so reading three channels would result in a 12 column output for example. I've checked the shaft encoder output with scope and it's perfectly in line with the engine (thought perhaps it was giving four times too many pulses per rev), and I've experienced the same problem if I use one of my own vi's or one of the NI examples, so I begin to wonder if this is something more deeply rooted with the DAQ? After all, what I'm seeing in the output of the AI Read is just what is being taken from the DAQ and written to the computer buffer, so it's hard to believe this is a Labview/software problem...
Any thoughts??

thanks very much

Theo

[Matt_Sweetland]

Theo:

I think what you should attempt doing is grab data from one channel for debug purposes.  From this channel use an indicator to display your data as it is grabbed from the buffer; is your data displayed as a 4 column array then?  Diagnose the problem piece by piece to better understand whether it is either software or hardware related.

Are you using an example vi?  If so can you reply with the exact name of the vi?  Even better, can you attach a copy of your vi so I can take a look at it?

Thanks,

Matt

[JTed]

Hi matt, 

Cheers for responding so quickly. Right, I'm away from the rig right now, but I think I can answer your questions from memory...

The same problem occurs when I use either the vi that I wrote, and any of the example vi's that work for this purpose, like the Acquire N scans ExtChanClck.vi and so on. I forget which exact one I'm thinking of, probably the above one, but it has a display that shows the output from the AI read on the front panel as a column vector, which you can toggle to show the various columns. Even with this example vi, scanning only one (and any one of the four) channel(s), I still get exact duplication of the single channel, four times over. So you can toggle through four identical vectors in the front panel display. I even took the vi that i wrote and pared it down to just the bare elements and "removed as much software" as I could, so it contained just the clock config, trigger config and ai read vi's, and it still gave the same problem. I can post the vi for you at a later date, but given all the above I just can't help thinking it's a deeper problem. As a matter of fact, I eventually removed and completely reinstalled the Labview software, DAQ board and DAQ software out of sheer frustration, and still I see this problem. I've checked the shaft encoder signal with a scope, and at any given engine speed the frequency of the pulse is perferctly aligned with the rotational frequency, so I'm pretty sure it's triggering ok. I'm beginning to run out of options!

Thanks

Theo