Retriggerable/Gated Infinite Pulse Generation

[numb7rs]

Hi all. I'm trying to use LabView and DAQmx to generate triggers during a specific window, specified by an external trigger, and want to know if it's possible.

The situation is this:

• An experiment runs for a finite, but undefined time (from tens of seconds to some minutes).
• A main trigger signal is provided for the duration of the experiment, raising to high when the experiment starts, and falling back to low when it stops.
• From the start of the main trigger, and after an initial delay (user defined, around 0.5 seconds), a camera needs to be triggered at a user-defined time interval (anything between ten seconds and a few minutes).
• This camera sub-triggering should continue until the main trigger goes low again. It doesn't matter if the last sub-trigger overlaps with the fall of the main trigger, but it should otherwise be low whenever the main trigger is low.
• This process should repeat, including the correct initial delay, when the main trigger rises again.

What I've found so far is that this will somehow need to be done on a device with counters, probably using the 'Pause Trigger' functionality on a pulse generator with the 'EnableInitialDelayOnRetrigger' option set. I'm comfortable reading up and messing around with example scripts until I have a solution, but I don't yet have any hardware for this. I've tried using a simulated device, but you can't trigger them, and you can't see the output, both of which are kinda useful for building a triggering system.

I think this should all be possible using an NI 9402 in a cDAQ-9171 USB chassis. The 9402 has 4 internal counters, and 4 DIOs, and the USB chassis should be relatively pain free to interface with LabView. Can someone please confirm this, before I splash out on the hardware?

Thanks in advance.

[Kevin_Price]

I can't speak authoritatively about the cDAQ capabilities, but it sounds like you're largely on the right track with your approach.

However, I'd caution you about relying on pause-triggering.  A counter pulse task is pause-triggered by suppressing the input timebase signal, *NOT* by suppressing the output pulse signal.  Thus, when the pause trigger asserts, the output state will get stuck at whatever state it's in at that instant.  And the next time it de-asserts, the counter will start counting from where it left off when the timebase was previously suppressed.  This may slightly shift the relative time of camera pulses relative to the main trigger.

It may end up being useful to add a simple logic AND circuit so you can suppress the output signal externally rather than using a pause trigger to suppress the timebase internally.

-Kevin P

[ikaiser]

Kevin's AND suggestion is a neat solution.

If you wanted to do inside the cDAQ and the counter output potentially stuck in "high" would break your application, then a retriggerable task might be helpful: Retriggerable Tasks in NI-DAQmx. Your external trigger starts/pauses your main counter. On raising edges of this main counter your slave counter is re-triggered and sends the trigger to your camera.

The main counter might get stuck outputting "high", but the slave counter does not care. Only needed of course when a) the counter can indeed get stuck in high mode and b) your camera recognizes "high" and not the signal edge.

The number of timing engines available on your cDAQ-9171 is enough to cover this: Number of Concurrent Tasks on a CompactDAQ Chassis Gen II

[numb7rs]

Thanks for the reply both. Unfortunately you've confirmed something I had feared. 

The pausing-on-high-state isn't such a big deal. The camera can be configured for rising edge triggering, and, as you say Kevin, and AND circuit could be used in an emergency. 

What this does cause problems with is that initial delay. The timing of the sub-triggers has to be correct relative to the start of the main trigger, so that the camera records the same point in time for each experiment. This means that the sub-trigger can't just pick up where it left off, as you say would happen with pause-triggering, but needs to start the sequence anew.

As there would be 4 counters in that box to play with, I can afford to have a couple of slave counters, the initial delay can be separate from the main sub-trigger sequence if it has to be. Is there a way to reset a paused counter?

[numb7rs]

I've just realised that there are usually a couple of minutes between each experiment. The end of the experiment is also software detectable, either through the 9402 (preferable) or through some other software systems that are already in place (less preferable as it cannot always be relied upon).

This means that I should be able to trigger a software event at the end of each experiment in LabView to run a Stop/Start on the counter tasks. It would be nicer of course to have everything in hardware, but if there's no way to have a re-triggerable infinite pulse train, then software will have to do.

The raises another question: Can I use the same incoming external hardware trigger multiple times? Once on the rising edge to trigger my counters and sub-trigger stuff, and again on the falling edge as a pause trigger, and/or for a Change Detection Event?

Many thanks!

[Kevin_Price]

---

@numb7rs wrote:

...there are usually a couple of minutes between each experiment. The end of the experiment is also software detectable...

Ok, that simplifies things considerably.  When you detect the end of the experiment, just go ahead and stop the pulse train task that's sending out "sub-triggers" to your camera.  That'll both return the output to idle state *and* prevent the problem of "picking up the count from where it left off".   Just programmatically re-start the task again after stopping it -- this approach also means shouldn't have to configure anything related to re-triggering.

For your future (possible) benefit, there is a special way to speed up the stop-->restart process.  You don't need it now, but it might be good to know for the future.  You can read up on the "DAQmx Task State Model" and the function "DAQmx Control Task".  The summary is that you *commit* the task just before you start it.  When you do, the subsequent stop-->restart process proceeds more quickly and efficiently.

Can I use the same incoming external hardware trigger multiple times? Once on the rising edge to trigger my counters and sub-trigger stuff, and again on the falling edge as a pause trigger, and/or for a Change Detection Event?

Sure, you can configure a given signal to be used in multiple different ways at the same time, provided DAQmx can route it from the physical pin to where it needs to go functionally.  I'm not sure what all the routing options/restrictions are on your cDAQ setup though.  On the desktop boards I'm more familiar with (M-series, X-series), timing signals like clocks and triggers would need to be physically wired to a "PFI" pin, while a signal used for DI change detection would need to be wired to port0 which does *not* share a PFI designation.

Further notes:  I don't believe you can configure your sub-trigger pulse generation task to use both a Start Trigger and a Pause Trigger.    It *might* be possible (but I'm not sure) that you could configure simultaneously for an "Arm Start Trigger" and a Pause Trigger on your cDAQ system.  Here's a post I know of (because I made it) to show how to configure an Arm Start Trigger using a DAQmx Trigger property node.

-Kevin P

[numb7rs]

---

@Kevin_Price wrote:
Ok, that simplifies things considerably.

Yes, yes it does. Maybe I should have realised that earlier, sorry!

Sure, you can configure a given signal to be used in multiple different ways at the same time, provided DAQmx can route it from the physical pin to where it needs to go functionally. I'm not sure what all the routing options/restrictions are on your cDAQ setup though. 

I don't actually have any of the hardware yet, the C series was just what looked easiest to get going! If you have any other suggestions, I'm more than open to them. I'll do a bit more playing with the simulated devices to see if I can set up the routes I'll need.

Further notes: I don't believe you can configure your sub-trigger pulse generation task to use both a Start Trigger and a Pause Trigger. 

This could cause some difficulties. Can a Pause Trigger be used to start a task, if the trigger is low when the task starts?  That's if your trick with the Arm Start Trigger isn't the solution! 

[Kevin_Price]

X-series boards are a good option.  I tend to prefer desktop boards over USB, but that's primarily for reasons like bandwidth for hardware-timed tasks and lower latency for software-timed tasks. These considerations wouldn't matter for the app you describe, and a USB device should work just as well for you as the equivalent desktop device.

There's likely a simple cDAQ configuration that can work too, I just don't have enough familiarity to identify one with great confidence.

A Start Trigger starts a task with a digital edge, and once the task has started and is running, any subsequent digital edges have no effect.   A Pause Trigger is more like an Enable/Disable signal.  The task pauses while the pause trigger is in a particular state and continues running when in the other state.  If the pause trigger signal keeps toggling back and forth, the task keeps toggling back and forth between running and being paused.

There's another approach you could take that uses 2 counters together if my idea with the Arm Start Trigger doesn't work out.  You'd set up a helper counter task to generate a pulse train at maybe 1 or 10 MHz.  It would be pause-triggered by your master experiment signal so it's only allowed to count time and make pulses while the master experiment signal is high.   Then you'd use this counter's output as the timbase that your subtrigger task would use for generating pulses for the camera.  When you notice the experiment signal going back low, you'd stop and restart both counters before the experiment signal goes high again.

-Kevin P

[numb7rs]

Ok, thank you very much for the clarification on the hardware differences and the Pause Trigger behaviour.

I think I have enough now to buy the hardware and start tinkering to find something that works. I hope that the 4 counters in the 9402 are enough(!).

I'll post back when I've got something that works (or when I'm completely lost ...)

Thanks!

[Kevin_Price]

I would confirm that the 9402 ought to work out.  Given the view from here, the 9402 should provide access to the counters built into the chassis and the max speed restriction does not appear to be an issue for your usage. 

-Kevin P