Missing external triggers occasionally (due to tight timing?)

[joehsiao]

I am generating a pulse train from counter 0 on a PCI-6723 by following this example:

https://forums.ni.com/t5/NI-DAQmx-Examples/Generate-Retriggerable-Finite-Digital-Pulse-Train-from-Co...

The start of the pulse train is triggered by PFI0, which is wired to an external signal.

The timing is very tight between the triggers and pulse train. The trigger is set to come in every 200ms and a pulse train is set to last 200ms.

My problem is sometimes the trigger signal would just be ignored. I figured the reason might be the timing is so tight that when a trigger signal comes in, the counter is still outputting a pulse train from a previous trigger, thus ignores the current one. Any idea how to avoid this?

[joehsiao]

Is there a way to store input triggers in some sort of buffer/queue so the pulse train would check the buffer for triggers?

[Kevin_Price · Accepted solution]

Decision time:  what's more important?

A.  responding to every trigger signal without missing any (at nominal 200 msec spacing)

B.  producing a full 200 msec pulse train when responding to a trigger

Pick one.

You are correct, if one pulse train hasn't quite finished when the next trigger edge arrives, that trigger is ignored.  You can't avoid this.  The task should catch the next one, but you'll miss one interval worth of pulse train generation.  

It sounds like you have behavior B at present, and aren't totally satisfied.  To move toward behavior A (depending on regularity of incoming trigger signals, you may not get 100% there), you'll need to marginally reduce the period of the pulses you generate.  I'm assuming the # of pulses is more important than their exact frequency.

The timing margin you need is down at the board hardware level.  I don't know exact specs, but I'd expect a few microsec (or maybe less) would be plenty.   For example, if you have 100 pulses, I'd shorten each by maybe 100 nanosec to make a 10 microsec margin.  Of course, this assumes that the trigger interval is a perfect 200.000 msec.  If the interval can vary, you need to shorten the pulses more to accomodate the shortest possible trigger interval with a few microsec of margin.

A different approach is to keep the same pulse period but decrement the # you generate by one.  This strikes me as much more likely to be undesirable though.

-Kevin P

[joehsiao]

Thanks Kevin. I reduced the total time of a pulse train by 1ms and it works.