Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Retriggerable/Gated Infinite Pulse Generation

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.

0 Kudos
Message 1 of 10
(3,017 Views)

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

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 10
(2,998 Views)

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

 

 


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
0 Kudos
Message 3 of 10
(2,978 Views)

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?

0 Kudos
Message 4 of 10
(2,973 Views)

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!

0 Kudos
Message 5 of 10
(2,967 Views)

@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