ni 9205 signal delay

[Chrispy555]

Hello:

I am using a NI 9205 input module card in a cDAQ9188 chassis. In labview there is a delay between the signal change and the change in labview. For example. I have a flow meter that is outing 1.5V to the module. When I increase the flow, the meter outputs 1.9 volts right away, but Labview has a delay of about 20-30 second before the reading changes. As time goes on, it gets worse (up  to 2 minutes) I've rebooted the computer and chassis and the delay decreases, but then it just gets worse again. I've also swapped out modules and it does the same thing. I'm thinking its a computer problem as when we tested it in our computer lab, it was working fine. All other modles in the 9188 are working fine (temperature, digital and analog output cards)

Anything I can check before I format the computer and reload labview?

Thanks

Chris Paulusse

[Tom_W_[DE]]

Hey Chris-

What mode are you operating your 9205 in (On Demand or Finite/Continuous)?  Which type of DAQmx Read instance are you using (single-point or N samples)?  And how is your 9188 ultimately connected to the test PC (directly connected or through some switch/router network)?

It might help if you posted a screenshot of your code, assuming it is simple enough to understand with a quick inspection.  Do you see this same delay if you use one of the DAQmx LabVIEW shipping examples for continuous acquisition?

[Chrispy555]

Hi Jim:

I am running the 9205 in continuous samples, and using single point samples on the read. The 9188 is connected via TCP/IP with a static address through a switch. I haven't tried any of the shipping examples, but my code is not difficult. I just took it from one of the tutorials off of NI.

I have included a screenshot of the code. When I use the proble (#7), I can read the voltage reading off of channel 1, and when we read the voltage with a voltmeter, the output voltage from the instrument changes immediately, but there is a lag between the voltage change and when the labview probe reads it. This morning its only 7-8 seconds, but yesterday afternoon, it was up over 3 minutes.

Any suggestions would be helpful.

Thanks

Chris

[Chrispy555]

Here is the attachment

[Tom_W_[DE]]

Hey Chrunchy 😉

I did not see the code attachment, but I can offer some advice based on your description.  If you are using the continuous (or finite) acquisition mode, I would strongly suggest using the 'N Samples' version of DAQmx Read that is appropriate for your channel count.

When you are using a sample clock-timed acquisition (like continuous or finite), samplese are being continuously buffered by the device and transfered to the host.  When you call DAQmx Read with these sample clock modes, the data is then pulled from the backlog on the host.  Reading one sample at a time can be inefficient processing-wise, but depending on your sample rate and the loop rate with which you're reading, you could also fall behind in the backlog on the host.  This could eventually result in buffer overflows (loss of data, which would be signalled by a DAQmx error) or apparent long lags in updating of data (like you're seeing).

Try reading 'N samples' where N equals approximately your sample rate divided by your loop rate.  So if you are sampling at 200Hz and your loop is running twice per second, try reading 100 samples per loop iteration.  You can decimate the data if you're only interested in the most recent sample, but it should help you avoid the lag you're seeing and you can take advantage of the DAQmx Read blocking behavior (it blocks until the N samples are available or the timeout to DAQmx Read expires) to throttle and control the loop rate, too.

If it isn't easy to make this change in your application to confirm my suggestion, you might try the LabVIEW example "C:\Program Files\National Instruments\LabVIEW 2013\examples\DAQmx\Analog Input\Voltage - Continuous Input.vi"