Issues with USB-6210 DAQ - Programmatic cross talk?

[Roberteh]

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 shown 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. I'm completely at a loss with this

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. When I run the VI in continuous acquisition mode instead, I get the desired 200hz but after 30 minutes of running the data starts to lag behind real time, which would break the control loop in my main program. Does anyone have advice for getting the VI to report data at 200hz real time? I'm not sure if this is a related problem or not.

I'm running LabVIEW 2018 on a windows machine

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

[GerdW]

Hi Robert,

Does anyone have advice for getting the VI to report data at 200hz real time?

Delete the wait function in the loop!

(It will also help when you don't update the graph/chart at 200Hz. 10Hz will be good enough…)

First, channels 5, 6, and 7 all show a reflection of channel 13.

Are those channels connected to any voltage/signal sources?

[Roberteh]

Hi GerdW,

Deleting the wait time has no effect on the loop timing. The wait should keep the loop from running any faster than 200hz, but the loop currently runs at closer to 70hz. When I delete the wait time (and the chart), the loop runs at the same speed. It's something with the DAQ block itself. That's all when running in finite acquisition. Running in continuous acquisition mode with the wait time holds the loop at 200hz, but the DAQ slowly builds up a buffer and the data starts to lag behind real time. Without the wait while running in continuous acquisition, the loop speed oscillates very quickly between 170hz and 250hz. I have not run the loop in this mode long enough to see if the data would lag, but I need more precise timing so I haven't thought it necessary.

Channels 1-14 on the DAQ are all hooked up to transducers, all the same kind of transducer. I've tried this with the transducers connected to 5, 6 and 7, and with them disconnected, and the problem is the same. I have also probed the transducers directly with an oscilloscope and they are reporting the correct voltage. Additionally, when running the express VI those channels report the same voltage as their respective transducers, regardless of the voltage on channel 14.

Thanks,

Robert

[GerdW]

Hi Robert,

Deleting the wait time has no effect on the loop timing.

Yes, it has…

Right now the wait function limits the iteration rate to 200Hz. But Windows will also influcence your loop, when it thinks it has more important things to do than your DAQ stuff (like virus scans, network communication, whatever). So your loop has to lag behind the DAQ sample generation with time…

Without the wait while running in continuous acquisition, the loop speed oscillates very quickly between 170hz and 250hz.

Removing the wait allows to loop to run as fast as possible: now it has the chance to read the next sample faster and to keep up with your DAQ device. The sample rate is still set in your DAQ task (much more stable then your loop or Windows timing!) and is not coupled with your loop iteration rate!

But: you selected the "1 Sample" mode when reading samples. This is the slowest mode available.

Try to set a sample rate of 1kHz and read 5 samples per DAQmxRead call, using the "N chan N samples" mode. Then average the 5 samples per channel…

You also should move the chart out of this loop: think about using a producer-consumer scheme. The chart has a lot to do with your samples as it needs to handle it's internal history buffer. Doing this 200 times per second is non-sense…

[Roberteh]

Hi GerdW,

When I deleted the wait time nothing changed. That is what I mean when I say deleting the wait time has no effect on the loop time. I also deleted the chart, and again nothing changed. Moving it to a consumer loop will not have an effect if deleting it didn't help. The code I've posted is a test bed for diagnosing this issue, not the end product. In the end product I only have the DAQ block in a loop set up as the producer for a consumer. I have also set this VI to run at high priority, so windows should be letting it run first whenever possible.

I need this loop to run at 200 hz and I need it to send 1 data point each time, otherwise the rest of the program will be slowed and the system I've designed will go unstable. Unfortunately I've tried averaging samples before, but it doesn't change the loop speed issue.

[GerdW]

Hi Robert,

Without the wait while running in continuous acquisition, the loop speed oscillates very quickly between 170hz and 250hz.

What's wrong with that "speed oscillation"?

After all you are on a Windows computer, so you can't expect a jitter-free stable 200Hz loop!

The main timing will be provided by your DAQ hardware as it provides new samples exactly (within hardware specs) at 200Hz…

I need this loop to run at 200 hz and I need it to send 1 data point each time, otherwise the rest of the program will be slowed and the system I've designed will go unstable.

This sounds like a bad design when you rely on a stable 200 Hz clock - on a Windows computer…

If you need less/no even less jitter then you should use RT or FPGA targets!

I have also set this VI to run at high priority, so windows should be letting it run first whenever possible.

Changing VI priorities within LabVIEW usually doesn't provide any measurable gains. It might help you in your specific use case, but even NI does recommend not to change the default priorities…

[Roberteh]

An 80 hz swing is a big deal, and I can get a loop running on the computer at 200hz with closer to a 5 hz swing without the DAQ acquiring data. 80 hz isn't a little jitter, its a wild oscillation. Given that oscillation, there's no way to be sure the DAQ is actually providing data at the rate required, and since the DAQ doesn't report timestamps I need the loop to generate timestamps. 

We've put some months into this and had it working with a different DAQ before limitations on that board made us switch. This is well within the capabilities of this DAQ on a windows machine. 

Do you have any advice for my other issue? The seemingly programmatic cross talk?

[GerdW]

Hi Robert,

there's no way to be sure the DAQ is actually providing data at the rate required,

When the DAQ device allows to set a sample rate, then you can be sure the samples are measured using exactly this sample rate (within hardware specs)!

The problem here (IMHO) is the transport of the samples from DAQ device over USB to the computer memory: this could be influenced by other USB devices on the same USB port - or when Windows taskmanager is shifting priorities…

Additionally, as written before, you are reading the data in "1 sample" mode, which also is rather slow and also contributes to the jitter.

But the samples are measured exactly at the configured samplerate!

Still we are talking about loop iteration times between 4ms and 5.9ms (with desired 5ms), which is quite good when using DAQmxRead in "1 sample" mode on a Windows computer…

[johntrich1971]

To get stable acquisition you need to use continuous acquisition. You do not need to read one sample every loop. Instead read (for example) 100 samples every loop (update your data every 0.5 seconds with 100 samples). If there's jitter (even wild jitter) in your loop it won't matter - your DAQ is handling the timing and you won't lose samples. You also reduce the read overhead which will decrease the likelihood that you have buffer overruns. Also, if you'll do a waveform instead of a double you'll have a timestamp (t0), a dt, and an array of data for each channel directly from the DAQ driver - much more stable than anything you could ever do with loop timing. 

[aputman]

I suspect you've got some grounding issues happening with those 14 single ended channels.  You say what with the express VI, you don't see the reflection.  So right click the express VI, open the front panel and see how the tasks are configured and then translate that over to your VI.  Be sure to make a copy of the express VI before doing this because you can't go back once you've open its front panel.