Reference trigger usage with continuous sampling using DAQmx

[lebecker]

I have a PXI-1045 chassis populated with PXI-6120 digitzers and 6653 timing module. The acquisition/recording software (LV 8.5/DAQmx) is a producer/consumer design pattern configured for continuous acquisition. I have noticed about 30-40 ms delay between an event (digital line going high) and when it is actually recorded in the data file, and this is about in the ball park for Windows XP systems.  I suppose this is attributibal to using a queue to transfer the data packet from the producer to the consumer loop. I am interested in being able to get a more accurate recording that exhibits little or no delay. For some tests, the 30-40 ms would constitute and entire rotor cycle or two when the reference trigger is a combination of a one/rev signal from the hub and a program conditional boolean. Questions:

1) Is a reference trigger (post sampling) the way to remove the delay in the recorded data?

2)Can a reference trigger work with continuous sampling or are they mutually exclusive? 

I have read where RTLV operates in the 2-5 ms delay range, but we have invested heavily in regular LV...

Thanks,

lb

[Paul_C.]

Hello lb,

Without seeing your code it might be difficult to understand the exact reasons you are getting a 30-40ms delay.  Anytime you transferred acquired data from a "producer loop" to a "consumer loop" for file save, you will see some delay recording this information to disc.  I believe there may be some confusion regarding the reference trigger.  The reference trigger is used to acquire pre and post trigger samples during an acqusition.  On the 6120, this can only occur once per acquisition.  On some of our high-speed digitizers, you can use a retriggerable reference trigger in something that is like a continuous acquisition.  This would make it such that you could trigger and acquire multiple chunks or sets of data each trigger and transfer these "chunks" to the consumer loop for file save.  The only way I could see a reduction in delay between the two loops would be to use small data sets that can be processed faster.  Perhaps I am misunderstanding the question.  Can you provide more information regarding your application? 

Regards,
Paul C.

[lebecker]

Hi Paul,

I think you answered the question, ie., we'd have to go to a higher-speed board to get the re-triggerable reference functionality for continuous acquisitions that is needed.

The code is large but I could post the producer/consumer loops if you think you could spot deficiencies in the way it's programmed...

[Dan_K]

Hello lebecker,

You can go ahead and post your code to the forums, at the least it would give a good reference point for further discussions on your issue.

[lebecker]

Hello Dan_K,

I'll post the entrire code, it didn't fit too well in jpg format...it's a bit ponderous, but the meat of i is the last 2 loops (producer/consumer)

lb

[Dan_K]

Hello lebecker,

Given the amount of processing you are performing on the data, along with the normal overhead of a DAQ task it is unsurprising that you are getting a 30-40 ms delay between acquisition and write to file. One thing you could do to work around this problem would be to read the data as a waveform instead of as unscaled data. This would include the time data in the DAQ read, allowing the time data to propagate through the program instead of having to be added on at the end.