AO waveform with sync Pulse

[Dpete]

I am using a PCI-6154 to generate 4 continuous waveforms.  I am trying to generate a sync pulse on PFI 6 each time the waveform restarts.  I would expect this to be a simple common task, but it has been causing me consternation for a while.  I can get a single pulse out timed with start of generation, but not a pulse synced to each restart of the buffer.

This and variations on it do not work because it does not consider wrapping the buffer back to start a new start.  When I tried using the counter output to generate a pulse, I get a single rather than a free run.

[santo_13]

I don't think there is a way for DAQ to tell that it wrapped around the buffer.

[Kevin_Price · Accepted solution]

Here's how to make your counter method (mostly) work:

1.  Remove the 2 trigger-related DAQmx calls.

2. In their place, add a call to DAQmx Timing that configures Continuous Sampling.  Choose the "Implicit" version of DAQmx Timing rather than the default "Sample Clock" version.

3. Get rid of the race condition where you use a local variable to set your pulse timing parameters!  Extend the actual wire where you calculate size.

4. In addition to defining low time and high time, you *also* need to define the 'initial delay' parameter for your pulse train.

5. Keep using dataflow to enforce that the CO task starts before the AO task.  You've already done this right, just be sure not to *undo* it.

After this, the remaining problem is that your trigger pulse will be offset by 10 samples from the beginning of the buffer.  Counter pulses start in idle state for "low time" and then transition to pulse state for "high time".

    You can make this be as small as 2 samples by changing your constant, but 2 is the minimum time allowed for either low or high time.

I can think of 2 possible workarounds, but can't test either one right now. 

    One involves defining your pulses with a high idle state and an "Arm Start" trigger.  The theory is that the counter will first transition to high idle state on receipt of the Arm Start trigger, allowing you to sync with the beginning of AO generation.

    The other involves a little AO buffer trickery.  You'd first write a buffer that contains 10 values of 0 followed by all but the last 10 values of your waveform.  Then, after starting the AO task, you'd *overwrite* the buffer contents with a rotated version of your waveform where the final 10 values come first, and the rest of the buffer is filled with the beginning portion of the waveform.  There's a palette function that can rotate an array forward or backward.  Run a quick test with it to be sure you're rotating the right direction.

-Kevin P

[Dpete]

That works beautifully with no "drift" that occurs when the timings are not quite right.  I may need to verify that all waveforms are more than 6 samples (due to the minimum 2 samples for the high and low, and would assume for the delay).  I am not worried about the pulse being offset from the start of waveform so long as it is consistent. I can make up for that in pre-trigger or delay on the O-scope side. (This generates the external trigger in for the scope)  

The DUT syncs up after after a few cycles of waveform then we look for pulses that should occur at some point in time related to the waveforms we feed it.  I can adjust the window in time that we look in, it just needs to be the same every cycle.