How to delay trigger from IRC for predefined number of TTL pulses

[ceties]

Hello,

I am making measurements with IRC sensor mounted on camshaft. The IRC offers TTL pulses and the trigger pulse. When the trigger pulse comes I acquire predefined amount of data over multiple revolutions(ignoring other triggers). In the same time the trigger signal is also directly connected to other device where it serves like reset for each revolution.
The problem is when the IRC is mounted I don’t know where exactly is the trigger mark so sometimes it happens that the trigger comes when the valve is open. So I have to mount it again.

What I would like to accomplish is to delay the trigger pulse for predefined amount of TTL pulses. Meaning that the trigger is connected to the DAQ board. When trigger comes it counts predefined amount of samples and then it outputs it’s own trigger for the connected device (trigger = reset) plus it starts the DAQ.

Can I accomplish this with PCI 6120 ? Especially if I use one of the two counters for other task?

Thank you very much

[Matyas]

Hey Ceties,

Use DAQmx Triggering Property node and choose Star >>More >> Start Delay property to set your delay either in tick or seconds (choose delay units)!

Check this link as well:

http://zone.ni.com/devzone/cda/epd/p/id/905

I hope it'll help!

Matyas

[ceties · Accepted solution]

Hi Matyas,

I know that I am a bit late but I came back to this after a year. The solution you suggested did not work since the trigger can be delayed this way only if the card timebase is used. Not if I use an external source, the TTL pulses from IRC. Plus I would still need to generate a pulse after the daley to reset the connected device that provides me the signal I want to measure.

Instead what I did was that I set one counter for pulse generation (Ticks) and I used an external source of the ticks. When the counter recognizes the trigger it will output a pulse that is first LOW for N ticks and then HI for few ticks. This operation is set as retriggerable. N=delay.

I actually don't understand why the counters on my PCI 6120 are digitally triggerable for output operation and not for input operation. Somedy knows the answer?

[Kevin_Price]

It sounds like you solved your original problem just fine, right?  So the question is just for curiousity?

As far as I know, the only "why" would have something to do with history of NI's DAQ technology.  Your board is an S-series board, one of a family of related boards initially designed more than a decade ago.  As I recall, it uses the DAQ-STC counter chip. This is the same one found in E-series boards and provides pretty much (maybe exactly) the same counter capabilities.  That doesn't happen to include the use of triggering for input / measurement tasks, but at the time of design it was still a big upgrade from NI's previous counter technology which didn't ev accomodate buffered measurements.

Then came the NI-TIO based dedicated counter boards which added quadrature encoder capabilities, input triggering, and a few other things.  Later, the M-series boards made some more incremental improvements and recently the X-series finally fulfilled some decade-long wishlist items of mine, including buffered CTR-based variable freq pulse generation, and hardware-triggered count reset.

So if you have new needs for triggering counter input measurements, NI has a variety of options available in their more recent boards.  (And considering that the NI-TIO counter cards are at least a decade old,  "recent" covers as much as the past 10 years.)  One little tidbit: counter input measurements are triggered with the special "Arm Start" trigger which is distinct from the standard start trigger used for most other DAQmx tasks.

-Kevin P

[ceties]

Thanks for your answer.

Yes the original problem is solved.

Yes the 6120 has the DAQ-STC counter chip which doesn't allow the Arm start trigger operation. I think I will have to look for a counter board since I don't want to give up the 6120 and comparable X series cards are only to PXI or USB.

[ceties]

Just one more thing. Also the "initial delay" plays role in the example I posted. In some cases the delay can be set through the amount of ticks Low/High but it depeneds how you set the reacto on rising/falling edge. In the other cases the initial delay is what causes the shift.

[Kevin_Price]

There are some things about that "initial delay" parameter and retriggerable pulses that are not what I consider especially intuitive.  (A little searching will show that the for delay after the 1st trigger can be different than it is for subsequent triggers.  It's been a while since I really looked into it though, so there's a chance that a new version of DAQmx may offer a workaround.

Most (maybe all?) of my personal uses allowed me to simplify down to the following to get consistent & repeatable total delays:  For high pulses like yours, I just wire the "low time" value so it *also* feeds the "initial delay" input.  I know there are circumstances where this won't accomplish what's needed, but I've found it to work out fine for many apps.

-Kevin P