LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx timing problems

Hi there,

 

Attached is a VI that shows a photoeye that triggers a sequence of control solenoid outputs.  It also triggers reading from a microphone.  The control solenoids operate a hammer and microphone that are raised and lowered.  The sound of the hammer hitting an object is recorded.

 

When we remove the microphone analog input read everything works perfectly and timing is excellent (exept we get no audi data!).  When the microphne read is included, there are very occasional inconsistencies in the output timing of around 40-60ms.  Another odd side effect is that analog data also seems to be delayed by around 250-300ms.  Like the recording does not start immediately.

 

We have an oscilloscope on all the signals so can see the timing of everything at the inputs and outputs (cDAQ 9132) in practice.

 

Does anybody have any suggestions on how we could eliminate these delays caused by including analog read and also make analog sampling start at the expected time?

 

For example, the scope shows the sound pulse occur at 2050ms after the trigger input, we delay sampling for 1500ms after the trigger input, then record for 1000ms.  This should land the sound pulse starting nearly in the middle of the recorded waveform.  But instead of the sound pulse starting half way through the sampled data it is early by approx 200ms suggesting sampling started late (refer attached picture).

 

Besides the above mentioned occasional 40-60ms jitter (that only happens if analog read is included), the control outputs all change state at the times expected showing that the "swing hammers" state starts at the expected time (when the photoeye is triggered).

 

Any help appreciated, I have burnt a lot of time on this!

 

Regards

 

Ashley

 

Capture.PNG

 

0 Kudos
Message 1 of 4
(2,854 Views)

Hi Ashley, I've just encountered a very similar problem using my myDAQ with MATLAB. (it's peculiar that it occurs on the very same day as you post this)

 

To test the problem I have connected an analog output directly to a positive pin of a differential analog input with the input AGND connected to the negative pin of the differential input. With this I then run a sine wave through and record the output.

 

The recorded measurement seems to lag the output by 62.2ms (taken at 100 kHz sample rate). I don't have an understanding of why this happens or a fix, and I can't even be entirely sure our problems are the same (apologies if this is the case), but I'm hoping the mistake is either trivial to fix or is a driver bug which can be fixed by rolling back.

 

I have attached a minimum working example of my code from MATLAB, and an image displaying the timing issue. The sine wave is padded with 0.5s of zeros, and the output scaled by 0.5 to highlight the effect.

0 Kudos
Message 2 of 4
(2,800 Views)

Quick update: I have narrowed down my problem to the DAQ itself.

 

I have swapped the DAQ out for a different one and tested for lag and found none, confirming it is a part of the myDAQ. I made sure I had the most up to date drivers on the myDAQ as well, which made no difference. I am going to assume now that it is a calibration issue and probably needs to be sent to a NI engineer.

 

Have you tried checking if your DAQ is calibrated?

0 Kudos
Message 3 of 4
(2,758 Views)

We managed to resolve this issue.  By doing some debugging looking at the actual start times of the frames we were able to determine it was the DAQmx start task VI causing the problems.  It waks 299-309ms to execute.  The stop task VI is also slow at around 200ms. 

 

To fix this we changed the analog read to hardware triggered and start it once at initialisation.  Then the same edge that triggered the sequence also triggers the recording.  We ideally wanted to start recording at a later point but settled with recording the entire duration and creating a subset of samples in the area we care about.

 

 

Corrected VI is attached for reference in case it helps anyone in the future.

Message 4 of 4
(2,736 Views)