Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Trigger an output pulse every N input pulses

Hello. I am new to LabVIEW and DAQs; the examples and this forum are very helpful.

I am using a USB-6341 DAQ.

 

I have a digital input signal that I would like to use to trigger a digital output. I can use the Counter - Single Pulse Output example vi from the Help menu and it works as expected.

 

However, what I would like to achieve is to trigger the digital output only every N input pulses. eg only on odd input pulses, or only every 5th input pulse.

 

To achieve this I think I should count the input pulses. I can use the Counter - Count Edges example vi, which works as expected to count the imput pulses.

 

What I am not sure about: how can I wire the number of edges from the count edges such that it becomes a 'trigger' for a single pulse output?

 

If you have any suggestions, or relevant links to help me with my problem I would be very greatful.

0 Kudos
Message 1 of 4
(1,287 Views)

There are a lot of possible options, can you answer some further questions?

 

1. Are the external pulses arriving at a known constant rate or is it unknown?

2. Any idea what that rate is likely to be?

3. Do you need a highly precise lag time from the incoming pulse to the outgoing one you create?  Or can you allow for software timing tolerance?  (Here precise = microsec level or below, tolerance = multiple millisec of variation)

4. Some techniques may lead to missing an output pulse opportunity if incoming pulses arrive faster than expected.  Is it important never to miss?

5. What's important about the output pulse - lag time until leading edge?  time spent in high state?  Anything else?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 4
(1,274 Views)

Thank you for your questions.

1. The input pulses are from a camera indicating that the camera has finished aquiring the current frame. So they will be arriving at a (fairly) constant rate. I say fairly because while the exposure time of the camera will remain contant (and will be known) I don't know if the time it takes to write a frame to disk will be the same for every frame or might vary over the course of ~6000 frames aquired.

 

2. The maximum rate of input pulses would be 50 ms.

 

3. I think a tolerance in the low ms would be acceptable.

 

4. It is important not to miss an incoming pulse, but it is more important that the output pulses remain synchronized with the input pulse (ie the output pulse remains synchronized with the end of the camera frame)

 

5. I think the time spent in high state is important for the output pulse. It should remain high until the next input pulse is detected.

0 Kudos
Message 3 of 4
(1,261 Views)

The net result of all those answers tells me that you probably ought to be doing the timing in hardware based on how you configure your counter task(s).   

 

You say you're new to this stuff and I'm not going to be able to teach all the details right now.  But here are some breadcrumbs of ideas to do some more research on.

 

1. You'll want a counter task configured for retriggerable single pulse generation.  Each input pulse triggers it to produce exactly 1 output pulse.

 

2. You'll be able to specify which edge of the input pulse to trigger on.

 

3. You can define the polarity of the output pulse as needed.

 

4. There are 3 timing parameters available in the DAQmx functions - low time, high time, and initial delay.  If you're making a pulse that idles in low state and active in high state, you should set low time and initial delay to the same value.  Initial delay gets used for the 1st pulse, low time for all the subsequent ones.

 

5. NI's counters define pulses to start in their idle state and end in their active state.  The initial delay will set the time from triggering on the input pulse's active edge until the output pulse transitions from idle state to active state.  All subsequent delays will be defined by low time if idle state is low or high time if idle state is high.

 

6. Times can't be set to exactly 0.  But on your device, they can be as low as 20 nanosec which is close enough.

 

7. The counter will not rearm for the next trigger until it completes its pulse.  Any additional triggers arriving in before the pulse is done will be ignored.  You can use this to configure pulse times that are long enough to *force* you to miss a certain # of the expected 50 msec triggers.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 4
(1,251 Views)