Gating a Counter Output with a Digital Pause Trigger (Python)

[robinvanzutphen]

Hi all,

I am trying to run a finite pulse train as a master clock for an acquisition application, which should run continuously for a specified number of pulses. In addition, a second pulse train should also run. However, after a certain number of pulses from the first train, the second pulse train should be paused for a set number of pulses, and then resume again.

To test this functionality in Python, I made a simple piece of code that does the following:

• Generate a finite pulse train on CTR0.
• Create a High/Low gating signal on DIO2 based on CTR0 timing.
• Physically wire DIO2 to PFI2.
• Generate a finite pulse train on CTR1, gated by the signal on PFI2.

CTR0 works fine, and the gating signal on DIO2 looks correct. However, when I probe CTR1 output, the gating is never applied. I have tested all PFI lines, even though the documentation suggests they should work. The 5 V signal is also correctly registered by PFI2.

Currently, I’m out of ideas for further debugging, so I’d greatly appreciate any pointers. If there is a simpler way to achieve the same outcome, I’d love to hear about it.

Best,

Device: BNC-2110 connected to PCIe-6323

[Kevin_Price]

Caveat:  I program in LabVIEW and don't know any details about the correct Python syntax.  That said, I couldn't identify any problems in the code you posted.  The way you set everything up *looks* like it should have worked as you expect.

I can see that your DO task timing is driven by the Ctr0 finite pulse train.  And assuming the proper physical jumper wire to bring the DO signal over to a PFI terminal, I can see that your Ctr1 pulse train *should* be enabled/disabled by the PFI pause trigger.  And you're starting the tasks in the right order.

Are you really *sure* you've got the signal wired from port 0.line 2 over to PFI2?  Have you tried simplified troubleshooting with nothing but the pause-triggered Ctr1 task, where you can manually switch PFI2 between 0 and 5 V?

A somewhat pain-in-the-neck workaround is to remove the DO task and configure Ctr1 as a buffered pulse train output since you already have pre-defined knowledge of its desired pulse timing relative to Ctr0.  The time periods when you were previously "pausing" the pulse train simply become long durations in the idle state when you define the buffer of pulse parameters.  You may need to add a start trigger to both tasks to make sure you line up their t=0 points.

I kinda like the original approach you took and would do some more troubleshooting before abandoning it though.

-Kevin P

[robinvanzutphen]

Hi Kevin,

Thanks for your reply! I did some more troubleshooting, but unfortunately, I wasn’t able to gain any meaningful new insights. However, I realized I was somewhat stuck on using the pause trigger instead of considering an easier workaround similar to what you suggested.

Rather than using the DO as a pause signal, I am now directly using it to generate the desired signal. It’s driven by ctr0, but since I already know the pattern I want, I manually define the high/low sequence. I’m not sure if this is the most robust approach, but for my intended frequency range, the signals are synchronized. Do you see any potential pitfalls with this method?

I also considered using a buffered ctr1 pulse train, but funny enough I came across this post whilst googling where you explicitly stated:

"Unfortunately, NI doesn't provide any buffered output functions for their counters."

https://forums.ni.com/t5/Multifunction-DAQ/Finite-pulse-train-generation-with-variable-time-lapses-w...

That was the reason I decided to stick with the DO instead.

Anyway, thanks again for your help!

Best,
Robin

[Kevin_Price]

Using DO for your 2nd intermittent output can *potentially* work, but ONLY if the timing for all the DO high/low transitions happen to fall on integer periods of Ctr0 (which is being used as a sample clock to drive DO).

If you're sure you can live with that timing restriction, then predefining your DO buffer of output states should work out just as well as predefining a CTR buffer of interval times.

---

I also considered using a buffered ctr1 pulse train, but funny enough I came across this post whilst googling where you explicitly stated:

"Unfortunately, NI doesn't provide any buffered output functions for their counters."

https://forums.ni.com/t5/Multifunction-DAQ/Finite-pulse-train-generation-with-variable-time-lapses-w...

And that was in fact true back when I made that post... 20 years ago.  Your 6323 is an X-series device which was introduced since then and *does* support buffered counter output.

Buffered counter output would give you more flexibility with the timing of your intermittent signal's digital transitions.  But DO would also work fine provided all the transitions can align with active edges of Ctr0.

-Kevin

[robinvanzutphen]

Hi Kevin,

Thanks again for your response and insights. I indeed ran into the timing restriction, which is why I set CTR1 to double the frequency, synchronized it with CTR0, and used it to drive the DO. That said, a buffered CTR seems like the most straightforward approach.

Best,
Robin