02-11-2016 09:05 AM
How much time should it take from a start trigger condition happening to the actual start of waveform acquisition on a PXIe-6535? In my case, it's taking ~70ms, which strikes me as being way too long. The delay times I found in the manual are all down in the single to double digit nano-second range.
Here's a little background: I'm trying to measure a PWM waveform, to verity duty cycle, frequency, total time generation, etc.
The PWM signal is coming in to the PXIe-6535 on the Port3/Line3, and I've jumpered Port3/Line3 to PFI5 on my breakout board. The start trigger is configured to fire on the rising edge of PFI5, with waveform acquisition happening on Port3/Line3. PFI5 and Port3/Line3 both see the same PWM waveform, which is the yellow signal on the scope shot.
The task is configured to use a sample clock rate of 10Mhz and collect 2,500,000 samples, which comes out to a 250ms waveform acquisition time. You can see on the scope probe that there is a gap in PWM signal. I want to collect just the first section, and I know that section is (or should be) 250ms long.
However, I'm very clearly getting that gap and ~70ms of the next PWM waveform from the PXI system. The PXI waveform acquisition is verified 250ms. The problem is it's delayed by ~70ms from when the first time PFI5 goes high to when it actually starts acquiring.
Ignore the ringing. The probe does not have the best reference.
Here's the setup code:
readPwmTask = new NationalInstruments.DAQmx.Task("Read PWM task"); readPwmTask.DIChannels.CreateChannel("PXI1Slot6/Port3/Line3, "", ChannelLineGrouping.OneChannelForAllLines); readPwmTask.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("/PXI1Slot6/PFI5", DigitalEdgeStartTriggerEdge.Rising); readPwmTask.Timing.ConfigureSampleClock("", 10000000, SampleClockActiveEdge.Rising, SampleQuantityMode.ContinuousSamples); reader = new DigitalSingleChannelReader(readPwmTask .Stream); reader.SynchronizeCallbacks = true; reader.BeginReadWaveform(2500000, new AsyncCallback(DataReady), readPwmTask );
Solved! Go to Solution.
02-11-2016 10:22 AM
Narrowed it down.
This problem only happens when it's the first waveform aquisition in the lifetime of the application. If I do a "normal" aquisition before attempting to use the start trigger based aquisition, it works much better.
03-08-2016 10:33 AM
The first time a task is committed to HW, it takes time to download the board settings which may be causing the delay. You can explicitly commit settings to hardware using the DAQmx Commit function, then you can start your task knowing there will be no delay in the time it takes to download settings to HW. Otherwise, once the task has started and is awaiting a trigger, it will be very quick (next rising edge of the sample clock after the trigger is found).