Two analog input signal interaction on myDAQ with LabView

[bmcbride]

I have a Labview/myDAQ setup to measure two load cells. A 10V excitation is applied to both of them with a dedicated regulated power supply. The load cells feed data in through analog ports A0 and A1. The LabVIEW program receives the datafeed, scales the data, performs some basic logic operations and then will display a range of data (e.g. 50 sequential samples) if a certain criteria is met. 

The issue I'm having is that I get very unusual spikes in measured voltage when I try and program both data streams to be read in LabView with the myDAQ Assistant. If I reprogram it to just read in one channel of data, for example A0, I do not have this issue. I'm thinking it must be software related, as I can leave all hardwiring wiring the same and not experience this issue with only 1 channel being read. 

What is the best way to read in analog data from A0 and A1, and then have two separate data streams? I've tried "split signal" and selecting a channel for continuous data streams with the same issue. I've attached the VI for the program and an Excel file showing some of the random voltage spikes. 

[MichaelB123]

Hi,

I would first consider looking at some of our sample code and see if the same behaviour will exist. You can find a analog input examples by going to Help » Find Examples » Hardware Input and Output » DAQmx » Analog Input » Voltage SW-Timed Input.vi

To use multiple channels you can simply click Browse in the Physical Channel dropdown and ctrl click to select two channels.

Michael B.

Applications Engineer

National Instruments 

[AjayShankar]

I am receiving two analog inputs from two photo-detectors at myDAQ analog input channels and need to synchronized it perfectly to find quadrature relation between the signals for phase retrieval.  If I am creating two channels through DAQ Assistance Express as in attached VI do it provide perfectly synchronized input or needs anything more. Please suggest.

[MichaelB123]

Hi Ajay,

Since you are using only one DAQ assistant Express VI, both channels are happening on the same task. This means they well have the same timing and triggering properties. If simplicity is what you are looking for, this is an effective method for synchronizing two analog inputs.

If you are curious about the capabilities of the myDAQ and its timing accuracy, I would look at the datasheet for your product. http://www.ni.com/pdf/manuals/373061f.pdf

Michael B.

Applications Engineer

National Instruments 

[charlesy]

Hello bmcbride and Ajay,

Keep in mind that the myDAQ analog input is multiplexed, meaning both channels route into a switch into the same instrumentation amplifier. When measuring one channel, the switch stays in the same position and the output of the amplifier always represents your input signal to the ADC. When measuring two channels, the switch has to change back and forth between each channel for each sample. The channels are not acquired at the same time. The myDAQ ADC has a maximum aggregate sample rate of 200 kSps (200k for one channel; 100k for two channels). Make sure your application is tolerant of that 5 us channel-to-channel skew. As you slow the sample rate, the channel-to-channel delay also gets longer... I believe until it gets capped around 60 us. 

If the output impedance of your sensor is high and the sample rate is fast, it won't be able to change the charge on the switched path before the ADC captures a sample. You can get crosstalk artifacts between the channels. See the "Settling Time" graphs in the myDAQ specifications.

Mitigations for high output impedance sensors are to place buffers on each sensor before connecting them to the AI channels, and slowing down the sample rate.

I hope this is helpful,

Charles Y.

National Instruments

[bmcbride]

Hello Charles, 
Thanks for the advice. I've been running a VI that iterates every 10 ms. From my understanding, this is far below the 100k sample rate maximum. I've been experiencing three issues:

1. The sample rates I'm getting is not what I expect. I am repeating this VI every 10 ms but do not seem to be getting a sample rate of 100 Hz. Is it possible that the VI takes so long to execute such that it delays the sampling rate?

2. I get decent measurement values at the beginning of any test, but if left overnight, these values start to drift. This occurs with some VERY significant fluctuations for what should be a static signal around 0.05mV, almost to the maximum expected signal (around 20mv)

Is there anything obvious that I am missing or misunderstanding? I've attached my VI

[Niki.B]

Hello,

In relation to your first question, is there a specific reason you are having the program take one measurement every 10 ms, versus setting the program to take continuous measurements at that specified frequency?

[charlesy · Accepted solution]

Hello bmcbride,

I think your system is getting bogged down by the Write to Measurement File happening every loop iteration. As the file gets larger (or at the whim of your operating system), your loops will start taking more than the 10 ms delay. 

You might rearchitect this loop in a couple of ways. As Niki suggested, you could change the DAQ acquisition to continuous. That would be appropriate if you care about precise measurement timing. Using the LabVIEW loop timer leaves it to Windows to count the delay, and if the process gets interrupted, there's no guarantee when it will resume. 

You can gain quite a bit of performance by moving the Write to Measurement File into the Load History case statement... only write the file when you have 125 samples. That might be enough to satisfy your performance needs, but there are other ways to acquire and stream data to disk more efficiently.

Take a look at the IEPE - Continuous Input.vi example (Find Examples -> Hardware Input and Output -> DAQmx -> Analog Input). Notice that the only loop is around the DAQmx Read VI. That's really the piece you want to cycle on. Looping on the DAQ Assistant VI is like looping on the entire chain in the example. There's a lot of overhead with task initialization, configuration, and closing, that's all unnecessary in this application.

In the example, the hardware will continuously fill the FIFO with samples in the background. You just need to go in and read (for example, 125) samples at a time. You should have no problem avoiding an overflow at these data rates.

This example also shows DAQmx logging to the TDMS format, so you don't have to use the Write to Measurement File step. It's far more efficient for streaming data to disk than rewriting an lvm file each iteration. 

Good luck,

Charles Y.

National Instruments

[bmcbride]

Niki and Charles, 

Thanks for the advice. Unfortunately I have only a basic understanding of LabView. I notice the computer is a bit slow and starts to lag at times. If I do change the DAQ acquisition to continuous, I have a few questions:

1. Will this still sample from both channels simultaneously? (With necessary delay for duplexer..)

2. The continuous sample mode is n samples at a specified sampling rate, correct? So I could just do 1 sample every 100 Hz to be effectively the sample as a 10ms delay?

3. I'm not sure how the rest of the VI will execute if not in a timed loop, especially if I'm using shift registers. 
4. The Write to Measurement File should only execute on button press, although it is in the main loop iteration. Will this still affect performance if it is in the loop but not active for every iteration?

[JoAl0304]

Have you made any changes to the code?