How to gate a non-continuous counter output pulse

[550nm]

Hi,

I've configured a PCIe-6612 counter to generate a single pulse every time an external trigger occurs. Triggers occur at ~1KHz.  Now I'd like to gate that output pulse - the pulse should only occur if an "enable" signal is high.

I thought that this "enable" function was the purpose for the counter's "gate" input, but connecting the enable signal to the counter's gate had/has no effect.

I don't think "Continuous" pulse generation is an option - since we need one output pulse for every external trigger (if enabled-signal is high).

Thanks in advance! 

[Kevin_Price · Accepted solution]

You'll probably need to use 2 counters.  The problem is that the start trigger and pause trigger functions both want access to the same counter "gate" pin, so you're not allowed to configure a task to use both at the same time.

You'll need a new continuous pulse generation task that is pause-triggered by the "enable" signal.  Set it for a very high frequency such as 10 MHz.  Now you'll need to use this counter's output as the *timebase* for your retriggerable pulse task.  Instead of using the internal clock to count time, it'll use this signal coming in.

Caveat:  Use the shortest possible pulse time (2 periods of the timebase).  This minimizes the chance that the enable signal drops out in the midst of a pulse, potentially leaving it stuck in the high state.

-Kevin P 

[550nm]

Hi Kevin,

Thank you for the reply!

I was recently reminded of a new constraint...

There are actually other pulses being generated as a consequence of the external trigger.  These pulses need to be as "phase-stable" - with respect to each other - as possible.

I was using the 100MHz timebase as the timebase for my "generated-pulse".  Switching to a lower-frequency timebase (synthesized from the 100MHz timebase)  will introduce more phase uncertainty. If the highest synthesized frequency is, say, 25MHz, that translates to an error of ~40ns - which may still be OK.

What do you think about the idea of using the "enable" signal to trigger a (finite) pulse-train which is used as an "arm.start.dig.edge.src" for the generated pulse?  (If there are multiple arming-edges for each trigger, will that be a problem???)

Time to start experimenting...

[Kevin_Price]

Do the other triggered pulses also need the enabling/disabling action?  If not, those pulses can continue to use the 100 MHz timebase.

All the generated pulses will have very stable timing with respect to each other, since they all ultimately derive their timing from the same internal 100 MHz clock.  The variability comes between your pulses and the triggering edge.  There you'll get nearly 1 timebase period worth of uncertainty (and likely also true variation) b/c the incoming trigger is independent and can occur at any phase within a timebase cycle.  So your concerns about 10 ns vs 40+ ns will only apply to the timing from input trigger edges to output pulse edges.   All the output pulse edges will have very consistent timing relative to one another.

I'm not exactly clear on your idea of triggering a finite pulse train off the "enable" signal.  I don't see how that method will produce the same kind of "trigger-reaction" behavior.

-Kevin P

[550nm]

Thanks for the explanation - I will probably attempt to implement your idea today or tomorrow.

The idea of using the "arm" functionality was to keep the generated-pulse exactly as it was described in OP.  Instead of connecting the "enable" signal to GATE, connect a pulse-train of arming-triggers to gate.  The arming triggers can be a finite pulse-train triggered by the "enable" edge. So, generated pulses only happen if the task is armed, and the task only gets armed for the duration of the enable-triggered pulse-train. However, predicting how long to send arming edges is a problem,  

Many thanks! 

[550nm]

Hi Kevin,

Just an FYI:

The project was put on hold shortly after my last post (test-leads moved, etc). Eventually we'll get back to it and, once able to test/confirm your solution, I'll mark it as the solution.

Cheers!

[Kevin_Price]

Sounds good.   After all, it ain't a solution until you see that something's actually been solved.  (Wonder if we can convince our politicians to think that way?)

-Kevin P

[550nm]

Hi Kevin,

Pulses look good!

Green plot shows triggers.

Yellow plot is sync/enable signal.

Blue plot shows sync-enabled pulses.

(Sync-paused 50MHz timebase not plotted.)

Thanks/Cheers!