Use Counter to Trigger based on Quadrature Encoder input

[Gregory]

Hello, I've used NI DAQ hardware before, but I've never used a counter. I'd like to use a counter with the quadrature encoder output from a stage to send a trigger pulse every time the stage travels a certain distance (e.g. 5um).

I plan to start the counter, move in a single direction, then stop the counter. The encoder has a resolution of 1nm, which I understand means I will get a rising edge on Ch A every 4nm. If the stages are moving at 100mm/s, this means a rising edge every 40ns, corresponding to a frequency of 25MHz.

I've looked into Counter Output Events, and it seems like they can do what I want. I would set the initial count to correspond to my output trigger interval. (e.g. 5um / 4nm = 1250 initial count). I would set the action to count down, and select the output terminal and behavior (pulse). Then I expect that every time the counter measures 1250 pulses it will output a pulse, reset, and continue counting. I plan to run the stages ~10mm with the task running, and would expect 2000 output pulses (10mm / 5um = 2000). Then I would stop the task.

Before I run off and buy some hardware, I wanted to check my understanding with the experts here.
1. How do I pick hardware that is capable of counting a rising edge every 40ns? What is the relevant spec to look for?
2. Is my understanding of Counter Output Events correct? I can count down from initial count to output a trigger and it will continue resetting until I stop the task?

Please let me know what information I've left off, and thanks for your help!

[Gregory]

I've been digging through the NI 660X manual, and found that the 6601 can handle 50ns pulse period and the 6602 can handle a 12.5ns pulse period without pre-scaling. Also, it seems like the 6601 is getting to end of life, so I think it would be better to go with the 6602 for that reason. So, I think only question #2 remains now, thanks!

[Kevin_Price]

1. I'd recommend you at least give consideration to the PCIe-6612.  It's the next generation replacement for the 6602 and I'd say at least 90% of the differences are improvements.  It appears to be spec'ed for counting at 20 nanosec intervals which seems to meet your requirements.

2. There's more than one way to get the behavior you want, if I understand you correctly.  I would recommend a different method than the one you seem to be describing b/c I find it more natural and simple to deal with.  (It sounds to me like you want to start with an edge counting task.  There's a way to do things that way, but the 6602 wouldn't support it while the 6612 would.  Meanwhile, hear me out on the alternative below).

   I'd create a counter output task with units of Ticks, set for Continuous Sampling, and then set low ticks, high ticks, and initial delay all to 1250 (or whatever's appropriate for a given run).  I'd also configure the output behavior as "pulse" rather than toggle, just like you were already planning.

Bear in mind that this plan mostly assumes unidirectional motion.  If direction changes back and forth, you're likely to be generating your output pulses at different physical locations each time the direction changes.  (Because you may stop motion after 200 of the 1250 edges needed for a pulse.  Once you change direction, the next 200 edges gets you to where you issued your last pulse.   But you'll then be issuing the next one after only another 850.)

-Kevin P

[Gregory]

Hi Kevin, thanks so much for replying. I think you understood what I'm trying to do, but I'll put a graph below just to be extra clear. In this example, I'll just pretend that I want to create an output trigger after counting 50 rising edges, and repeating until I stop the DAQmx task. The width of the output trigger pulse is not too critical. I will only be moving in one direction during the task. Then I may stop it and start it again and move in the opposite direction, but I haven't decided if that is necessary yet.

I somewhat understand what you are saying for the Counter Output / Pulse Ticks task. I started from a DAQmx example and modified as below. I'm a little confused by the definitions of some of the inputs though. I assume "source of ticks" is going to be my encoder signal, is that right? If so, I'm not sure what the "counter" input would be.

Do "high" and "low ticks" refer to the output signal or the input signal? From your description it seems like these refer to how many ticks my input signal should be high and low before generating a pulse. But from the LabVIEW description, it sounds like it is the number of ticks the output signal should be high and low. So if I want a pulse every 50 ticks, I'd start by setting "high ticks" to 5 and "low ticks" to 45 (or any other combo that totals to 50). But, I know you're a DAQ expert, so I think I'm interpreting something wrong. Could you clear these up?

[Kevin_Price · Accepted solution]

Good questions, and you're definitely on the right track.  There are a couple subtle differences between my suggestion for pulse mode and low/high/init = 50/50/50 and your question about (presumably) toggle mode and low/high = 45/5.

First off, the ever-troublesome (but also useful) "initial delay".  Oft-ignored and frequently with little consequence, there are certain times it's important to get right.  And your situation sounds like one of them.

A standard pulse is defined by a time in idle state (low by default) followed by a time in "active" state (that's what I call it, sorry for confusion if NI's terminology differs).  HOWEVER, there's a special behavior for the very first pulse.  The time spent in the very first idle state is defined by the "idle time" rather than the low time.  I usually wire the same value to both the low time and idle time inputs to make every pulse have the same timing.  But that wouldn't be the right thing to do in your particular case.  Read on.

Here's how your proposed config would work:

1. you configure for low/high = 45/5,  leave the counter task in "output toggle mode" (the default) and start it

2. if unwired, the default idle time is 0 ticks.  Sneakily however, DAQmx will coerce that to the smallest legal value of 2 ticks instead.

3. So after 2 encoder edges (your initial idle time), your counter output will go high.

4. It will stay high for 5 total edges, then revert to low again on the 7th edge overall.

5. Thereafter it will follow your desired 45 / 5 pattern.  So it'll go high on edge 52 and low again on edge 57. And so on...

6. Note: you could get the kind of timing you really want if you set low/high/idle to 45/5/50.  That'd produce your first output transition to high after 50 idle time edges.  Then all subsequent low->high transitions happen after 5 high and 45 low edges.

Here's how my proposed config would work:

1. you configure low/high/idle for 50/50/50, set the counter task to "output pulse mode" and start it

2. after 50 encoder edges worth of initial delay, the counter output will pulse.  I *think* the pulse width will be 1 cycle of the device's internal master timebase -- so 12.5 nanosec for the 6602, 10.0 nanosec for the 6612.

3. after another 50 encoder edges worth of "high time", the counter output will pulse again.

4. Thereafter it follows the low/high timing of 50/50, pulsing briefly at the end of each interval.

So either approach can be made to work.  I kinda locked in on pulse mode since you seemed ready to use it in the original post.  But your 45/5/50 approach allows you to lengthen and choose your pulse width, which might be important for whatever equipment needs to react to the pulse.

To your direct question: when output mode is set for "pulse", the terminology low time, high time, and initial delay are no longer really meaningful.  The output is just always in idle state except for a brief pulse high at the end of each of those intervals.

[The internal behavior of the counter is to load one those values into its count register, then decrement on each "source of ticks" edge until reaching 0, aka terminal count.  Upon reaching terminal count, the output mode determines whether the output state is toggled or whether a brief pulse happens during the next master timebase cycle.  In the default toggle mode, low ticks and high ticks are good terms for what really happens.  In pulse mode, not so much.]

-Kevin P

[Gregory]

That's all starting to make sense now. I'm pretty confident that a counter card, or maybe even a multi function card with a counter could do what I want, and I can refer back to this to figure out the details when it arrives.
Can you clear one more thing up? What is the difference between the "counter" and "source of ticks" input to the "counter output pulse ticks" task creation? I thought I would wire the encoder signal up to the "counter", but it seems like the encoder signal should also be the "source of ticks".

[Kevin_Price]

The "source of ticks" will be a DAQmx *terminal*.  Examples include external terminals with a name like "/Dev1/PFI0" or internal terminals like Ctr0InternalOutput.  The same terminal can be used as an input for many different tasks simultaneously.

The "counter" input references the counter resource itself and will be a DAQmx *channel* with a name like "Dev1/ctr0".  A counter resource will be fully consumed by a task and cannot be used by another task.

So yes the encoder signal should be wired to a PFI terminal that is configured to be the "source of ticks".  Then you'd configure your task to run on one of the available counter channels that allows you to route the PFI terminal to its "Source" input.  (A routing table can be found for your device in MAX.  Generally, the 6612 counter board or an X-series MIO board will allow pretty much any PFI terminal to be routed to any of the counters' input pins.  Older boards had more limitations.)

-Kevin P

[Gregory]

I see, thank you! All of your posts were helpful and answered my question, and I'm sure I'll look back at this once I have my PCIe-6612 in hand 🙂

[Kevin_Price]

FWIW, you might *also* want to look into the X-series MIO line to give you a lot more versatility than the 6612.

Of note: X-series provide 4 counters where finite pulse trains only consume 1 of them (unlike the 6602, M-series MIO, and E-series MIO which consumed 2).

Both X-series and the 6612 support hw-clocked DIO, unlike the 6602 which is static only.

An X-series device would give you lots of general purpose AI capability, and optionally some AO capability too.

-Kevin P

[Gregory]

Just a quick update: I found a spare USB-6210 in the lab today. It's not a fancy device by any means, but it was working great. I actually enjoyed the flexibility of defining the output pulse by "high ticks" and "low ticks". It was able to keep up with my 15 MHz function generator without issue.