I have four different analog inputs connected to ai0 to ai3 of the 6220 HW. I read these values using one task, all 4 channels assigned to this task. When ai0 reads 7V, I see 0.8 V in ai1 too, though I expect it to measure 0V. If I just assign ai1 to the task, and do not measure all 4 channels, then I measure 0V as expected (though ai1 contains 7V, I just don't measure it).
Another 'funny' observation, is that if I change the order in which I add the channels to the task, the measurements errors are different.
However, when measured with the multimeter all 4 channels show voltages as expected.
Since my calling task is cannot block, I call the function
Any help is highly appreciated.
Solved! Go to Solution.
apparently you see ghosting effects, typically caused by high impedance signals connected to multiplexed data acquisition devices like the 6220. Please refer to this link for detailed information and potential solutions.
I hope this helps,
Thanks a lot for the info.
I came across this as one of the suggestions. I read only 4 channels together in a task. And the AI signals are not any waveforms, but power supply signals that switch between 7V and 0 V based on 'on' or 'off'. Infact I do not set a sampling rate, I just use the default setting.
Is this suggestion also relevant for my channels? Or is this suggestion relevant for signals that change (waveforms), like a sinusoid or a PWM?
What is the default sampling mode selected? Also is round robin the default selection?
The other suggestions related to HW are being checked. I will get back with our observations!
Thanks a lot once again for the great support!
as long as you configure all channels in one task, the board's multiplexer works in a hardware timed manner. That means, interchannel delay is relevant in this mode, regardless of the type of your signals.
If timing is not critical, you also could do single point acquisitions for each channel seperately. In such a scenario the timing for the switching is software based, which is much slower than the hardware clocked method. Please use this approach only, if you don't need any kind of deterministic timing in the mili- or microsecond region.
I don't understand exactly how you sample your channels, because there is no real "default mode". Could you please post a small example to demonstrate your approach?
Thanks a lot for the suggestions! Was indeed ghosting, related to multiplexing signals from a high impedance source. By setting ConvRate and Sampling Rate more optimally, the problem is resolved.
I have one more question though.
My application is such that we need to read the current signal value (poll) now and them, in all the 4 channels(in one task). We are not interested in data acquisition. And the function to read the current value should return immediately without blocking. Hence, I cannot set the timeout value to anything other than 0. But with this setting the very first read (DAQmxReadAnalogF64) results in a timeout error. Further reads work without any problem.
Is there a function to read the current sample and not a buffer of samples?
How do I avoid this error?
Thanks in advance!
could you please post some code? This will allow me to better understand the issue.
The C code looks like this.
DAQmxCreateTask "task", &hTask);
// the following is called 4 times for ai0 to ai3.
DAQmxCreateAIVoltageChan (hTask, channel, NULL, DAQmx_Val_RSE, 0, 10, DAQmx_Val_Volts, NULL);
DAQmxSetSampClkRate(hTask, 500); //500 Hz
The following function is called repeatedly approximately every 10ms.
DAQmxReadAnalogF64 (hTask, 1, 0, DAQmx_Val_GroupByChannel, uVals, 4, &numSamplesRead, NULL);
This function returns a timeout error only the first time it is called. After that, it is okay.
However if I call
DAQmxReadAnalogF64 (hTask, 1, 1, DAQmx_Val_GroupByChannel, uVals, 4, &numSamplesRead, NULL); the first time, this error goes away.
Please do let me know incase you need more info
thank you for the code snippet.
When you call DAQmxReadAnalogF64 the first time and set a timeout value of 0, there is a chance, that the acquisition is not yet initialized. This is expected behavior and shouldn't be a problem. If the timeout error occurrs at the first call, you could either ignore it or set a different timeout value for the first call only. In any case you should drop the first value and start with the second value.