Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with USB-6210 possible cross talk

Solved!
Go to solution

Hi All

 

I'm trying to use a USB-6210 DAQ to read 14 single ended channels at 200 hz. I've run into two very strange problems (one may be a symptom of the other?)

First, channels 5, 6, and 7 all show a reflection of channel 13. When channel 13 reads 2 volts, 5, 6, and 7 read -2 volts. Attached is a snapshot of my code. When I use the express VI rather than the blocks below, this problem does not occur, but the express VI has too much overhead for the code I'm trying to write. I've probed my transducers with an oscilloscope and they aren't reporting these negative voltages either. Disconnecting terminals 5, 6, and 7 does not stop them from reporting these negative voltages.

 

 

 

My second problem has to do with the sample rate of this code. I've wired 200hz to the rate input on the timing Vi, but in the configuration shown I measure the loop running at 50hz with occasional spikes of 100hz. I thought that had something to do with the "2" wired to "samples per channel", but I'm unable to wire in anything lower than 2. I'm not sure if that's a symptom of the same issue that I'm seeing above, or a different problem entirely.

 

Any help would be appreciated. Please let me know if there's any other information I should post

Download All
0 Kudos
Message 1 of 7
(3,090 Views)

DAQ diagram.JPGDAQ front.JPG

0 Kudos
Message 2 of 7
(3,089 Views)
Solution
Accepted by topic author Roberteh

Your first issue sounds like "Ghosting" where adjacent channels can pick up each others signals if they're not connected.  I've never heard of a negative reflection on a DAQ card though.  Are your signal sources very high impedance or something?  Have you tried setting your Input Configuration to referenced single-ended?  I think it defaults to that but you should wire it in the Create Channel VI to be sure.

 

The timing issue is simply your misunderstanding of what the clock does.  Your VI sets its clock to collect 2 samples 5ms (200Hz) apart on each channel, then you override that with the read VI which only gets 1 sample (otherwise you'd have a 2D array coming out).  You seem to be counting on your 5mS wait function in the loop to get you 200Hz performance but unless you have a real-time OS you can't count on that.  You can do pretty good though and you should be able to scan 14 channels at 200Hz with your card.  Take a look at the Voltage - Continuous Input example VI and modify it to your needs.  Help> Example Finder... Hardware IO > DAQmx > Analog In

 

Play with that and see if you can get the speed performance you need but remember that non-RT OSes like windows will never be deterministic and may fool you into thinking you have a stable collection until they decide to spend half the CPU cycles running an update or virus scan.

 

EDIT: Also take a look at Voltage - Timed Loop VI if you need good timing stability.  The timed loop overhead will actually cost you performance but if it works at your 200Hz needs it may be more stable.  At the least it will warn you if it couldn't keep up.

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
0 Kudos
Message 3 of 7
(3,016 Views)

The ghosting issue was a result of the input configuration. Apparently the analog inputs don't all default to the same configuration.

I managed to get the timing to work by removing the DAQ clock setup vi and placing a high resolution polling wait in the while loop

0 Kudos
Message 4 of 7
(3,002 Views)

Sounds good.  At the speeds your collecting the DAQ card you are using should do fine but still remember not to expect consistent, very accurate timing behavior from your loop unless you have a real-time PC and OS. Smiley Wink

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
0 Kudos
Message 5 of 7
(2,984 Views)

Hello. I'm actually having the exact same problem, with the exact same HW, but using Python. I have lowered the source impedance of my sensors to zero by using unity gain buffers, and lowered the ai_conv_rate and have not seen any change. 

Using the python nidaqmx module, how do I go about configuring the input channels to ensure they are all single ended? My code snippet is below.

 

    with nidaqmx.Task() as task:
        task.ai_channels.add_ai_voltage_chan("Dev4/ai1:Dev4/ai12")
        task.timing.ai_conv_rate = 1000
        # task.timing.ai_conv_max_rate = 1000
        data = task.read(number_of_samples_per_channel=10)

 

 

0 Kudos
Message 6 of 7
(2,963 Views)

I know it's the terminal_config parameter in the channel collection but I haven't used enough python with DAQmx to be sure and I don't have any DAQ hardware to play with here Smiley Sad

The docs are good though.  Here is a relevant page:  https://nidaqmx-python.readthedocs.io/en/latest/ai_channel_collection.html

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
0 Kudos
Message 7 of 7
(2,936 Views)