I have a PXI-1033 Chassis with a PXI-5402 function generator in slot 2 and a PXI-4498 16 channel simultaneous DAQ in slot 3. I'm controlling in with Labview 2011 64bit though a ExpressCard-8360. I'd like to synchronize it so that DAQ starts collecting data an even number of cycles after my function generator starts.
Ideally it would work like this:
1. Start Function Generator
2. Wait a specified amount of time for the mechanical system to settle
3. Wait until the next cycle of the output from the function generator starts.
4. Gather the required data from the DAQ.
I'd like steps 3 and 4 above to happen with as little delay as possible. Currently I'm doing it like this:
1. Init Function Generator
2. Configure reference clock to PXI_Clock, this is the chassis internal 10Mhz clock
3. Route the front panel Sync_Out to PXI_Trigger Line 0
4. Init the DAQ and create the AI virtual channel
5. Configure the reference clock to PXI_Clk10, this is the chassis internal 10Mhz clock.
I believe that I now have the all the 10Mhz clocks PLL together. Am I correct?
6. Set to True the DAQmx Channel Property AI.RemoveFilterDelay
7. Start the function generator
8. Wait the specified amount of time
9. Setup the sample clock on the DAQ
10. Set the DAQ to trigger on the rising edge of PXI_Trigger Line 0
11. Use DAQmx Control Task to commit these settings
12. Start the Task
13. Read the samples with DAQmx Read
This seems to work well except that I can tell from my data that it takes several 'tick' of the sample clock from the time the trigger fires until the first sample is actually read. Is there a way to reduce or compensate for this time?
Thinga that don't seem possible due to the limitations of the hardware:
Using Sync Triggers are not possible because they are not available on the function generator.
Using the Tclk function since it can't be used with DAQmx
Using the the Start Trigger and setting the AI Delay Time (or whatever it's called) to delay the start of data acquisition since it has the same problems with trigger delay as the sync out
Setting the DAQ to slave because you cannot set the Function generator to Master.
So, finally, is there a better way to do this synchronization that will more closely tie the receipt of the trigger and the beginning of data acquisition?
I've also thought I could use a reference trigger and acquire the necessary number of pretrigger samples but I don't know if it's possible to get the trigger delay time through one of the property nodes. Is there a property node for trigger delay?
Hi Ben Manthey,
When you are talking about how your data from the DAQ device seems to be acquiring several ticks after the trigger fires, it sounds like this is from the filter in the DSA device (PXI-4498). In the following link is a KnowledgeBase article that talks about why data is delayed when using DSA devices: http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D?OpenDocument. I also attached the link to the NI 449x specifications and on page 11 you can see the amount of samples that are delayed based on a given sample rate: http://digital.ni.com/manuals.nsf/websearch/EA0EC7BBCF855373862579F700547A33.
Yes, I know about the filter delay and I have set the DAQmx Channel property AI.RemoveFilterDelay to true. This will supposedly remove the filter delay automatically.Canyou confirm that this is true?
I currently have the output from my FGEN input directly to my 4498, assuming the first sample is taken immediately after the trigger is detected I would expect my first sample to be very close to zero. It's not, it is always a few samples after where it should be crossing zero. I can easily change my trigger from 'Start Digital Edge' to 'Reference Digital Edge' and manually set the 'pretrigger samples per channel control' to a number that gives causes my first sample to be very close to zero. The number of samples I have to acguire is dependent on the frequency of my waveform, for example at 1000hz I have to acquire 4 extra samples but at 1600 hz I only have to acquire 1.
I don't know what to call this except trigger delay. Is there a way to figure out how much delay I can expect between the trigger and the first sample?
Hi Ben Manthey,
What the AI.RemoveFilterDelay property node does is automatically discards all samples acquired before the start trigger. Another way to control the code to get your first sample where it crosses zero is to get rid of the AI.RemoveFilterDelay property node and use a dummy read finite VI and set it to the amount of pre-trigger samples you want to disregard and then have another read VI as your real read to get the samples that you want.
Also if you had an empty analog input channel on your card, you could change the trigger type to an analog trigger and the first sample you will get after the trigger should be the one that you want to see.
How will making a dummy read before my actual read be better then just using the AI.RemoveFilterDelay property?
I don't want to use analog triggering since I need tight timing control between my output waveform and my data reads. Is there a better way to improve this synchronization than how I described earlier?
Hi Ben Manthey,
By using the dummy read before your actual read gives you the option of how many samples you throw out. The AI.RemoveFilterDelay property node only gets rid of a constant number and you are unable to change that. It seemed like the first couple samples you got were after the zero line and with the dummy read you can control how many are erased and have your first sample right at zero line. In the following link the article discusses more about using the dummy read and its use: http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D?OpenDocument. Also if you use the analog triggering, you do not have to worry about the extra samples and the following KnowledgeBase article discusses this: http://digital.ni.com/public.nsf/websearch/EA42429C0BF5510C86256DA9007876E3. I have also included the NI Dynamic Signal Acquisition User Manual to provide more information about the triggering of DSA devices: http://digital.ni.com/manuals.nsf/websearch/C7F1AE47873FDE428625773700589591.