LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

AO waveform with sync Pulse

Solved!
Go to solution

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.

Dpete_1-1640037105847.png

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.

 

 

0 Kudos
Message 1 of 4
(644 Views)

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

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 4
(618 Views)
Solution
Accepted by topic author Dpete

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



Message 3 of 4
(612 Views)

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.

0 Kudos
Message 4 of 4
(599 Views)