Transitioning from Traditional DAQ to DAQmx; sampling rate problem

[ilnus]

Hi, this is my first post, and I apologize in advance if I posted this question in the wrong board.

I am updating code that was made several years ago written by a previous LabVIEW programmer in which I have no contact with. One part of the code requires updating the Traditional DAQ parts to DAQmx, since we are now running Labview 2011 in Windows 7, which in incompatibile with Traditional DAQ. We are still keeping the same hardware, which is PCI-6052E connected to a BNC-2110.

In the original code, it has three AI Acquire Waveform blocks, each one connected to a different channel. It is collecting 3361 samples with a sampling rate of 336,134. I am assuming my predecessor wanted the maximum sampling rate, since the PCI-6052E has a sampling rate of 333 kiloSamples/second, but I am unsure why he used a value greater than the datasheet.

I thought I could replace these three blocks with the DAQ Assistant express vi, and create the channels within that Express Vi.

However, when I tried to run it, I would get an Error -200019: ADC converstion attempted before the prior conversion was complete.

I read somewhere that channels share the same bandwidth, and that I have to divide my max sampling rate with the number of channels. Since i have 3 channels, I used a value of 111000 for my rate based on my datasheet (333000 / 3 = 111000). I also change my # of samples to 1110 (I think this is unnecessary, but I wanted to keep the rates consistent with the original. When I run it with the new values, it works, and the results did not appear to be different to the original results. But were my changes a valid answer to my problem, or should I have done it another way?

The part where I am confused is regarding the original program. Was the original running at a sampling rate of 336134 samples/sec for each channel, or were they all sharing that sampling rate equally?

Linus

[bstreiff · Accepted solution]

With DAQmx, putting all three of your channels into the same task causes the data to be acquired from all channels in the same timespan. (For the 6052E, each sample consists of readings from the ADC multiplexed on each channel in sequence, which is why the sample rate must be divided by the number of channels.)

Traditional DAQ predates me by a considerable amount, and I'm not able to find any documentation on how 'AI Acquire Waveform' works. However, the impression I get from the Traditional DAQ screenshot that you've posted is that those are three separate single-channel acquisitions; it doesn't appear that there's any shared timing or other state between the three VIs. This would explain why a rate of 333k (333k divided by 1 channel) works there, whereas in your replacement version you can only use a max of 111k (333k divided by 3 channel).

For your application, I don't know which of the two is the 'correct' answer. I suspect your version is probably closer to what was intended (acquire from all three channels so that the data from all three is from the same window of time) instead of what it actually was (three separate 0.01 second waveforms), but since you just take an average DC value the input signal might be periodic enough that you get a similar enough answer either way.

As to why 336134 works: I think that's a rounding issue. The rate is used to compute an integer divisor of the 20MHz timebase. The minimum divisor is capped at 60 (20MHz / 60 == 333k). In the case of 336134, that would be a divisor of 59.50008, which I suspect is being rounded up to 60. (336135 would be 59.49999, which would round down, and give an error; perhaps your former colleague trial-and-errored to find the largest value that didn't give an error?)

[Kevin_Price]

I spent several years learning under traditional DAQ before DAQmx was introduced, and would confirm/agree with everything bstreiff said.

Those acquisition vi's are very analogous to DAQmx express vi's in that they encapsulate all the config, operation, and cleanup in a single call.  I agree with bstreiff's opinion that your 110k acquisition of all 3 signals during the same time window is most likely more appropriate than the original code's sequential 333k acquisition of 1 signal at a time during different time windows.  I also agree with your decision to acquire proportionally fewer samples so that your measurement is taken over data representing the same total waveform time as the original code.

The only catch is that you lose bandwidth by sampling at a lower freq.  We are supposing that the DC/RMS measurement choice suggests that high freq components aren't of particular interest.

One thing worth re-evaluating, in case the original programmer used improper assumptions, is whether the total acquisition time is the best choice for the particular signals you're measuring.   If the signals are periodic waveforms of some kind, you'll want to try to capture a reasonably large integer # of periods worth of the waveform for best discrimination.

-Kevin P

[ilnus]

I see, thanks for your views. Glad to know the new method works correctly.

Linus