USB 6009: DAQmxSetAIConvRate causes error -200452

[chassan]

Hello,

I'm developing in VS C++ and acquiring two channels of analog data on a USB-6009 (oem).  Whenever I try to decrease the conversion rate of the channels to 20kHz using the daqmxsetaiconvrate function I get error -200452 "Specified property is not supported by the device or is not applicable to the task."

The task is an AI task so I'm pretty sure it's correct.  

Is the AI conv rate really not supported by the USB-6009 (oem)?  If not, is there any way for me to control the rate of the conversions or do I only have control over the scan interval.  Does this mean that I can only tell the 6009 how often to scan and it automatically scans each channel in the task at whatever conversion rate it deems appropriate?

Thanks for the help,

Chris   

[stilly32]

Hi Chris,

Setting the AI converte rate is not supported on the USB-600x series. You are correct in that you have control over the sample rate, that is the number of samples taken per second.  From the DAQmx  C Reference Help -

"By default, NI-DAQmx selects the maximum convert rate supported by the device, plus up to 10 microseconds per channel settling time. Other task settings, such as high channel counts or setting Delay, can result in a faster default convert rate. "

Hope this helps,

Andrew S.

National Instruments

[MTR1a]

Is there any way to increase the settling time?  Is there a firmware patch that can slow down the convert rate?

I'm doing single-ended, multichannel analog acquisition on a USB-6009, and I see lots of spikes or glitches.  The spikes increase and become more frequent when the voltage difference increases between successive channels in the scan.  I'm developing in C for MacOS and Windows using the latest version of DAQmxBase.

For now, I've solved my problem by wiring the same input signal into two successive channels in the scan.  The first one has the spikes, and the second one in the scan is clean.  The downside is that it cuts the number of usable channels in half.  I tried implementing this solution in software, but I get an error if I specify the same channel twice in the scan list.

Are there any other workarounds for this problem?

Thanks,
Mike

[MickeyD]

Hi Mike,

The settling time is not what i suspect is causing the problem.  If you just remove the second channel and connect it to ground, then do channels 1 and 3 show the spiking?  This will still cut your channel count in half, but it would be good to know if you still see the spiking behavior, because the settling time should be more than adequate.  What rate are you performing this acquisition at?  I am glad you have a work around, but there is no firmware patch, so if you want to see how the setup I mention above shows then I will be glad to try and solve this behavior with you.

Have a great week,

Michael D
Applications Engineer
National Instruments

[MTR1a]

Thanks for the reply, Michael.  I'm sampling at 200 Hz.  I tried grounding every other input as you suggested.  The spikes came back and all had a value of (or close to) 0 volts.  I forgot to mention previously that the spikes appear to have an envelope that matches the input signal for the previous channel in the scan.

And by "previous channel in the scan" I actually mean the next channel in the channel string.  Just to make things concrete, my channel list is "0,4,1,5,2,6,3,7" with 0&4 having the same input as well as 1&5, 2&6, and 3&7.  Channels 0, 1, 2, and 3 are the clean ones; I expected those to be the spikey ones, but maybe the scan happens in the reverse order of the how the channel string is specified??

Mike

[MickeyD]

Hi,

That behavior sounds like ghosting.  If we were to take the connections to channels 4,5,6,7 off, but keep them in the scan list, then would almost be an exact reporduction of channels 0,1,2,3.  This is most often caused by fairly large source impedances.  The USB 6008 and 6009 are particularly susceptible to this, since they have much lower input impedances.  One thing you could try doing would be to put a buffer circuit such as a voltage follower amplifier between the signal and DAQ device.  Let me know if you see that ghosting behavior.

Have a great day,

Michael D
Applications Engineering
National Instruments

[MTR1a]

Hi Michael,

I guess what I'm seeing could be ghosting, but disconnecting some channels doesn't help.  When I first saw the spiking, I thought there was a software problem, where some samples get stored with the wrong channel.  Are there any known bugs with the driver software that might cause this?  Could I just have a bad unit?

BTW, I currently have channels 0 and 1 buffered, channel 2 is connected to a 1k resistor in a voltage divider, and channel 3 is unused.

--Mike

[MickeyD]

Hi Mike,

It is possible you have a bad unit.  I was going to ask you said you had disconnected some of the channels, but you did not mention  if you continued to scan  them and could  still see the spikes even though the signals were no longer connected.  This would let us know if  it was ghosting or not.  I have never heard of any driver issue like that, but let me know if even though the channels are unplugged if you can still see measurements on them.  One last question if channel 3 is unused, then you see no voltage on it, but what about the other channel associated with it?

Have a great day,

Michael D
Applications Engineering
National Instruments

[MTR1a]

I kept all the channels in the scan list.  I still see the spikes on any channel with a different input than the previous channel in the scan.  If there are three channels in a row that are disconnected, for example, then the first one will be spikey and the next two will be clean.

Thanks for your help,
Mike

[MickeyD]

Hi Mike,

It seems clear your USB 6009 is having trouble with multiple channel measurements.  What if we take our acquisition from a single channel.  Do we see spiking.  If that is the case then something is wrong with your 6009 for sure, and it is not just a timing problem with multiple channel acqusition.  It sounds like your convert clock is not working appropriately, but it seems this would cause other problems, with the timing of the signal and not just effect it with this spiking, so let me know what behavior you see recording just 1 channel.  If you turn the rate down does that get rid of the spiking behavior?

Have a great day,

Michael D
Applications Engineering
National Instruments