Pausing a retriggerable counter

[dropthebase]

Hi everyone, I'm trying to accomplish something that I believe is simple, but I'm having a hard time implementing it.

What I have is two pulses. The first pulse triggers off of an external TTL signal at 10 Hz with a 3ms delay, so it also fires at a rate of 10 Hz. The second pulse triggers off of the first pulse with a 100 microsecond delay, but I need this pulse to fire at 1Hz instead of 10. This seems like a classic example of gating, but I'm having trouble with LabVIEW. (Note: the 2nd pulse is triggered off the first pulse instead of the external trigger for timing stability.)

What I need is extremely similar to the example presented here: http://digital.ni.com/public.nsf/allkb/204538A044431C9B86257377004EB952, as in, I would like to pause my fast signal using a the low time of a slow one. Except in my case, my fast counter (10 Hz) is triggered and the slower counter (1 Hz) can be arbitrary, rather than vice versa as in the example.

I tried to do this using three counters. One of them is a retriggerable pulse that controls the 1st pulse (ctr0). Another one is the same, but used for the 2nd pulse (ctr1). And the third just uses the implicit/continuous timing tool to create a 1Hz signal (ctr2). I then tried putting in the "pause" trigger property node into ctr1 using the output of ctr2 as the pausing source, but this completely erased my 2nd pulse.

I'll upload a VI as soon as possible (maybe it's a trivial mistake), but does this sound like the correct approach?

Many thanks!

[dropthebase]

Attached is a picture of my VI of what I think this should look like. The counter numbers are different. As mentioned above, rather than gating my 2nd pulse, adding the "Pause" trigger type  completely eliminates it.

Should I instead be using one of the counter gate pins rather than this pause method?

Thanks.

[Kelly_B]

Hi dropthebase, 

I think you are on the right track here.  I would recommend structuring your code more like the code in the example.  Try and run the configuration steps in series rather than parallel, by connecting the error wires as shown in the example.

I've included a couple of links below, these may be helpful.

Tips and Techniques in Data Acquisition Triggering: http://www.ni.com/white-paper/4329/en/#toc3 

DAQmx - Retriggerable Gated Pulse Counting: https://decibel.ni.com/content/docs/DOC-4516

I'm not sure what is causing the pulse to disappear, but it seems like it might not be triggering.  Is the trigger source set correctly?

[Kevin_Price · Accepted solution]

The snippet below is a starting point for generating your 2 pulses with just 2 counters.  No need for a 3rd counter or any kind of pause trigger.

Assumption: I'm treating only the rising/leading edge of the pulses as the critical timing feature, making sure those edges meet the timing you described.

Both are just retriggerable single pulses, one triggers off the external 10 Hz signal with a 3 msec delay.  The pulse is short enough that the counter will easily be ready to retrigger 100 msec later.

The second counter triggers off the output of the first with a 100 usec delay.  This time the pulse is set to be long enough that the pulse won't end for almost a full second.  It will end just in time to be retriggered by the 10th subsequent trigger edge.  So these pulses will occur at 1 Hz, with leading edges delayed by 100 usec from the other counter and 3.1 msec from the external pulse source.

-Kevin P

[dropthebase]

Thank you for the replies!

Kevin, I'm glad to see that that method actually works! I shied away from that originally because I was worried that I would create really long pulses every 100 ms. i.e. the first pulse would become low just in time, but the second really long pulse would still be active by the time it needed to be retriggered. By what mechanism are triggers "ignored" during the high time? Does the DAQmx hardware take care of this, or is this a software mechanism?

Also, I recently found this: http://forums.ni.com/t5/Counter-Timer/Gate-two-retriggered-counters-using-a-seperate-counter/m-p/232... where Kevin, you mention why my original plan was essentially doomed from the start:

"The reason for your problem is that a pause trigger would need to map to the same internal counter pin as the retriggering signal.  That's why you can't do both at once, at least not *directly*."

Anyway...I managed to get something to work using this example: https://decibel.ni.com/content/docs/DOC-7372, where I just count my 1st pulses and send the 2nd pulse after counting 10. This was the most intuitive solution I could think of, but it uses 2 extra counters and a lot of loops! which is why I like your solution better, Kevin.

Thanks again for the help!

[Kevin_Price]

The mechanism for "ignoring" a trigger edge while still generating the previous pulse is something built into the hardware.  It's common across other kinds of tasks as well -- any retriggerable task will not interrupt an active task due to new trigger edges.  They are ignored until the task completes and re-arms the triggering circuitry/logic.

Now, a couple gotchas to watch out for, based on what you posted:

1. It doesn't look like you're enforcing the specific 3 msec and 100 usec delays you mentioned

2. The very first triggered pulse's delay is governed by the 'initial delay' input that you aren't currently wiring.  If you look at my snippet, you'll see that I wired the same value to both 'low time' and 'initial delay' to make sure *all* pulses showed the same delay.

3. I expect it'd be a good idea to add some sequencing to your tasks.  I'm guessing you want control over how many of your 10 Hz pulses occur before your first 1 Hz pulse.  In my example, the 1 Hz pulse triggers off the 1st edge of the 1st 10 Hz pulse.  In your posted code, there's no way to tell how many 10 Hz pulses you'll generate before the first 1 Hz pulse, and it's likely to vary from run to run.

-Kevin P

[dropthebase]

That was very helpful. Thank you!