USB6008 - mixed up analog input channels

[jboti]

Hi all,

I want to measure voltage with the USB-6008 device on 6 different channels. I've tried with DAQmxCreateAIVoltageChan specifying Dev1/ai0:5 as physical channel name, as well as 6 different calls to DAQmxCreateAIVoltageChan for the six different channels. I can read all six channels, but my problem is, that sometimes (qute often actually, about every second, third time) I start my program the input channels get mixed up. I use single-ended mode, and, for example, sometimes I read the voltage wired to AI0 on channel 0, but sometimes on channel 4. Same thing with AI1 and AI5.

I use LabWindows/CVI ver. 7.1.0, NiDAQmx ver. 8.7.1 (runtime 5) distribution.

Software sequence I use is:

DAQmxCreateTask()

DAQmxCreateAIVoltageChan( )

DAQmxCfgSampClkTiming( )

DAQmxRegisterEveryNSamplesEvent( )

DAQmxRegisterDoneEvent( )
DAQmxStartTask()

I also tried commiting the task before starting it; not helpful.

Any ideas?

Thanks,

Boti

[Doug_L._Bear]

Is it always with the same two (or i guess four) channels that always switch in the same manner, or is it seemingly at random which ones switch.  Also, what are you measuring that indicated that they are switching, and how are you looking at the data to know it has switched.  Also, how are you reading in the multiple channels.

Doug

Applications Engineer

National Instruments

[jboti]

Hi Doug,

Software sequence for creating the DAQ task/channels is:

DAQmxCreateTask()

DAQmxCreateAIVoltageChan(  "Dev1/ai0" )
DAQmxCreateAIVoltageChan(  "Dev1/ai4" )
DAQmxCreateAIVoltageChan(  "Dev1/ai1" )
DAQmxCreateAIVoltageChan(  "Dev1/ai5" )
DAQmxCreateAIVoltageChan(  "Dev1/ai2" )
DAQmxCreateAIVoltageChan(  "Dev1/ai6" )
DAQmxCfgSampClkTiming()

DAQmxRegisterEveryNSamplesEvent()

In EveryNSampleCallback I call DAQmxReadAnalogF64(), I read data with DAQmx_Val_GroupByChannel then in a for loop I separate samples i*N to (i+1)*N (N being the number of samples read). Then I display the datas separately for each channel.

I've just made some tests, nothing is wired to the USB-6008, so every channel's reading is around 1.4V. Then I short-circuit pins GND-AI0, GND-AI4 and so on to see which input is changing it's value. On every second run of the application the inputs look like they are shifted by 4. So normally the input channel sequence when reading is:

AI0 AI4 AI1 AI5 AI2 AI6

on the next run it will be:

AI1 AI5 AI2 AI6 AI0 AI4

These two sequences are changing each time I start my application.

Boti

Message Edited by jboti on 02-26-2009 03:57 PM

Message Edited by jboti on 02-26-2009 04:00 PM

[aNIta B]

Hey Boti,

          I'm curious, do you have VM Ware installed?  Also, when you're doing this test, I would make sure that you are inputing a voltage on every channel that you're reading- so that you don't have floating voltages.  Am I correct in assuming that you are getting the same results when you are reading the channels in order (0:5), and when you are reading 0,4,1,5,2,6.  Is there a reason you are skipping channel 3.  Have you tried running an example like one of the ones found here: C:\Documents and Settings\All Users\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog In\Measure Voltage ?  If modifying one of these examples still gives you the same result, there might be something wrong with your hardware.  Is this a new device? Have a great weekend!

aNItaB

Applications Engineer

National Instruments

[jboti]

Hi aNItaB,

No, I don't have VM Ware, I'm using a plain desktop PC with WinXP Proffesional, and also an Advantech PanelPC with WinXP Embedded, which will be the controller for a heating process. Same thing happens on both. I've redone my test with +5V connected to all pins, except for AI5, where I've connected 0V, this is my control input. Yes, you are correct, I'm getting the same result when reading channels in order (0:5). I've also tried running an example (ContAcq-IntClk to be precise, modified to read 6 channels - 0:5 ), the same result. The hardware is brand-new, but I've also tried another USB-6008 device, which I borrowed from a friend, the same result. I've also tried another USB input on the PC, same result. I really can't think of anything else I could try...

Is there anyone who experienced similar problems? What can I do in this situation?

Thanks...

Boti

[jboti]

Funny...

 It seems that this problem only appears when 6 channels are read. Strange, isn't it

Looks like the solution will be to configure all 8 channels, read them all, but using what I need from them...

Boti

[aNIta B]

Hey Boti-

        I'm glad you found a way for it to work, but I definitely think that's strange.  Would you mind posting your code?  I'd like to try to reproduce that, it doesn't seem there's much documentation on that behavior.  Thanks!

aNItaB

Applications Engineer

National Instruments

[jboti]

Hi aNItaB,

Here's the modified example project I used for testing - the DAQmx part is identical to my project. Try to start/stop the acquisition several times, you can check if the channels are mixed up from the colors of the traces.

Boti

[jamescway]

Hello,

I am experiencing this problem also with 3 channels and I DO use vmware.  Does this make a difference?  

I can cause this problem by making a break point in my asyncCallback  this triggersan exception (-2000279 ).

Then when this line below gets executed, the resulting data array the order is no longer valid.  My understanding it should be in the order

that I created the channels.   

double[,] data = analogInReader.EndReadMultiSample(ar); 

Any ideas?

Thanks,

James 

[hoffiz]

Hi James,

I think you have two different problems. Error -200279 refers to an overflow error as you can see in these KBs: Why Do I Get Error -200279 When Writing Continuously Acquired Data to a File? and Error -200279 or other Buffer Errors During a Continuous, Buffered Acquisition. Be aware that error -2000279 is not defined.

Now in regards to the second problem, I want to make an input, if you create your channel list as ai0:5 it should be read in order (i.e. 0,1,2...,5), if it is not doing it, we will try to replicate and let R&D know about it since this is a bug.