Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

hardware lag on analogue output daq card NI-USB 6211

I’m having trouble with a 1300ms lag on the output from my DAQ card. I can correct it with an offset value but I would like to try and find out why it is occurring so that I can correct the code rather than compensate. Please see below for explanation of what the code is programmed to do and also why I believe it is hardware related.

 

Program functionality

 

 

  1. Setup AO and AI channels for recording and output of data along with trigger AI channel (sample clocks for AO and AI are synchronised with the exception of the trigger AI).
  2. Wait for trigger AI voltage, after trigger is detected AI trigger channel is stopped.
  3. (picture 2 top code) – The aim of this section of code is to calculate the time in ms and use the time to control a DC output voltage with set limits in this case 0V for 2secs then 1V for 5Secs before returning to 0V. After 12Secs the loop should be stopped. Please note the labelled “offset time compensation” to start the output 1300ms before the “incubation time has ended” this compensates for the hardware lag.
  4. (picture 2 central code) this logs the data from a resistive temperature sensor, the AO fed back into the DAQ card, and some other channels.
  5. (picture 2 lower code) used to take a sample of data 200 samples before the 1V is applied and display it on a graph.

 

Reason for believing it is a hardware lag

 

  1. The “write to…” express VI is not recording the time output from the ms timers (even though I have tried to wire this in) and in operation finishes writing at 11.8s. This is 200ms less than the calculated time it is programmed to stop. However, there are 61 iterations of the while loop in the 12s period so it is only not recording the final 1 iteration. If I increase the total time then the 200ms is maintained (so this should just be that the loop stops before the final loops data is recorded) and therefore the ms timers are synchronised with respect to the “Write to ….” Express VI.

 

  1. The “on” time (1V output currently set to 5s) of the voltage output is the same as the set value.
  2.  
  3. All of the timings seem to accurate but just with a hardware delay?!
  4.  

Any help would be much appreciated!

 

 

 

0 Kudos
Message 1 of 9
(4,560 Views)

Hi,

 

I'm trying to replicate your set up myself to help with debugging your vi, however I only have the 6212 in the office not the 6211. What signal do you have going into ai0/3/6? What I'm seeing for the simulated signal output is it goes fro 0v to 1v but not back to 0 and the timing isn't 0 for 2 seconds 1 for 5 like you said. 

 

One thing I recommend trying is adding a small delay in your while loops, without the delay and depending on what you have in your while loop, cpu usage can spike resulting in undesireable outputs and unexpected behaviour, you can read more here:

http://labviewwiki.org/While_Loop

0 Kudos
Message 2 of 9
(4,524 Views)

Hi,

 

I do appologies, the settings for the program I posted were for a 5seconds wait time 5 seconds on at 1V and then a total experiment time of 5s. This means that the program ended before 1V was applied so you wouldn't see any voltage as you suggest.

 

To play around with the timings on the front panel top right there are three time inputs

 

1."incubation time" is the delay time before 1V is applied to the system

2."Voltage supply time" is the time the voltage is switched to 1V

3. Total experiment time is the total time before the while loop is stopped.

 

 

Please also note in the program that offset time compensation is set to 1300 (so there hardware offset was compensated for on my setup)

 

With regards to the AI

 

 

AI3 is physically wired to the AOO

AI0 I had connected to a resistive temperature sensor in a quater bridge config.

AI6 is not connected to anything.

 

 

Thanks for the advice on adding the timing. I have tried a few different time delays but not had any success with this.

 

Thanks for your help also:)

 

0 Kudos
Message 3 of 9
(4,518 Views)

Hi again,

 

thanks for the response, I've made the necessary changes to my set up however I don't have anything going into ai0 since I don't have a temperature sensor. I've also changed the offset from 1300 to 0. What I see on the output for both the recorded step output voltage and the cell output is a square wave signal that goes from 0 to 1v then back to 0 at the same time. How are you determining a hardware delay? Are your waveforms delayed from each other? 

The only delay I'm noticing is the simulated signal graph changes to 1v before the triggered data output. Is this the delay you refer to? Because for me this happens with or without the 1300 offset.

0 Kudos
Message 4 of 9
(4,516 Views)

Hi,

 

The delay is seen in the recorded data text file with respect to time. The time is listed in the left hand column and the output voltage as recorded from the AI.

 

I believe the trigger data graph takes a bit longer to update because it is taking more samples and outputting all of the samples at once, so this isn't a concern.

 

 

Thanks again 🙂

0 Kudos
Message 5 of 9
(4,513 Views)

Hi,

 

Can you show me an example of what you mean? I have my txt file here so you can compare.

0 Kudos
Message 6 of 9
(4,508 Views)

Hi,

 

Sorry for the slow response i'm in and out of meetings today!

 

Please see attached doc, it shows very similar results to your data where the the voltage does not start until 3.3s and finishes at 8.3s then the data stops recording at 11.8s

 

The input parameters for test1.txt are as follows:

 

Incubation time 2s

voltage supply time 5s

total experiment time 12s

 

 

 

0 Kudos
Message 7 of 9
(4,493 Views)

Hi,

 

So I've spent a lot of time narrowing down where the delay is coming from and what I think is that it's due to how you are using the DAQmx Write vi. When you enter the loop, it auto starts the vi even when there is no data on the line. So I think it gets stuck around here and this is where the unexpected behaviour occurs. The main problem is with how you are using the DAQmx write vi, I've attached a few links which are similar to what you want to achieve:

http://www.ni.com/example/27148/en/

http://www.ni.com/product-documentation/3874/en/

 

However I'm not entirely sure if what you want to do is possible with the USB 6212 device, there have been people with similar problems using it when trying to re write to it's buffer in a loop like what you are doing. Most examples only write to the buffer once and then it's manipulated later in the code.

 

I hope this helps.

0 Kudos
Message 8 of 9
(4,444 Views)

Thanks for looking into this and for your suggestion, I'll have a play around with the regeneration feature and see if it solves the problem.

 

Cheers

 

Darryl

0 Kudos
Message 9 of 9
(4,406 Views)