Generating triggers at specific encoder values

[Rogerlu123]

Hello, I'm having a hard time trying to figure out a way to generate triggers at specific encoder values. Right now, I have an quadrature encoder setup that will increment/decrement a counter and I want to ideally pass an array of encoder values so that when the encoder reaches that value, it generates a trigger. I'm still new to all this, so if someone could point me to the right direction, I would be grateful.

By the way, I'm using the USB-6341 in C++.

[Kevin_Price]

This is not a hardware-supported capability for the general case.  You haven't described enough details of your particular situation for me to figure out if there's a decent workaround or not.   Here are some questions that'll help:

- Is this linear or rotational motion?   

- Will it be uni-directional or bi-directional during the times of interest? 

- Are there discrete times of interest or is this meant to operate continuously and without gaps? 

- What's the trigger signal for?   

- How much lag time can you accept between crossing a target position and generating the trigger signal?

-Kevin P

[Rogerlu123]

Hi Kevin, thanks for your answer!

- Is this linear or rotational motion?

Linear motion

- Will it be uni-directional or bi-directional during the times of interest?

Uni-directional

- Are there discrete times of interest or is this meant to operate continuously and without gaps?

There would be a small window before moving in the opposite direction where I would not generate triggers, but can't guarantee that the encoders would remain constant at any time. I would also want to avoid resetting the encoder values.

- What's the trigger signal for?

While moving in one direction, I would want to trigger a camera at those precise encoder values.

- How much lag time can you accept between crossing a target position and generating the trigger signal?

As little lag time as possible, ideally none.

I initially asked the question to see if there was some comparator function that was available in the NI API, but from what I understand now, this might be more complex than I thought. If I could get your input on how feasible this is, I would greatly appreciate it.

[Kevin_Price · Accepted solution]

Ok, being unidirectional is a great start -- there will be some decent to very good workarounds.  First, a couple more questions:

- Do you have an unambiguous physical 0 position -- the equivalent of a "Z Index" for your linear encoder?

- Do you need the extra resolution of X4 quadrature decoding?  (Note: a "yes" will add some additional complexity)

Here's my core idea: Use another counter in buffered pulse generation mode to generate the trigger signals.  (There's a shipping example for buffered pulse generation to illustrate the basics).  This counter will use the encoder signal as its timebase source and its buffered trigger pulse parameters will be defined in terms of those increments of motion.

For example: let's suppose that channel A produces 10 cycles / mm.  And further suppose that you want to generate triggers at positions of 140 mm, 205 mm, and 311 mm.  And further suppose that the counter task idles low and the camera reacts to a rising edge and needs a minimum pulse width corresponding to about 1 mm motion at your speeds.  You would set up pulse parameter pairs in terms of (low cycles, high cycles).  They'd be {(1400,10), (640,10), (1050,10)}

If you truly need the extra resolution of X4 quad decoding, then you'll *also* need an additional DI task configured for change detection of both rising and falling edges of both encoder A & B channels.  You'd also need to physically parallel wire them to port 0 terminals which support hardware-timed DI.  And then your trigger pulse output task would need to use a special internal signal known as the "change detection event" as its timebase source instead of using channel A directly.

-Kevin P

[Rogerlu123]

- Do you have an unambiguous physical 0 position -- the equivalent of a "Z Index" for your linear encoder?

I don't.

- Do you need the extra resolution of X4 quadrature decoding?

I am using the decoding type DAQmx_Val_X1 if that answers your question.

Your explanation makes a lot of sense, so that I could set up all the positions right before starting the acquisition. I've tried searching for the example you mentioned, but I can't seem to find it. I'm probably not looking at the right place. Could you provide me the example or a way to find it?

I've spent quite a bit of time scratching my head over this, but I appreciate you guiding me through this!

[Kevin_Price]

DAQmx examples are at Help->Find Examples...->Hardware Input and Output->DAQmx.

Attached are my mods to an example for buffered counter output using the #'s of "Ticks" (i.e., encoder cycles) I used as an illustration in my previous post.

-Kevin P

[Rogerlu123]

Hi Kevin, thanks for your example and all your help. I've got something working now!

For anyone using c++, I used the DAQmxWriteCtrTicks function where I passed 2 arrays for the high and low ticks. If I had to generate pulses at positions (105, 150, 355), the first array (high ticks) would contain [5, 5, 5] as the high pulse and second array (low ticks) would contain [104, 40, 200]

By the way Kevin, what would change if I did have an unambiguous physical 0 position? I've been looking into z-index and I may need to use something like that.

[Kevin_Price]

I would look to use a z-index (or other "home" sensor) as a start trigger for the task.   Then on every test run, the pulse tick parameters would always start from the same specific physical position and give repeatable results.   Otherwise, they just start from wherever the system is when you start the app.

I know sometimes linear encoders will have multiple z-index positions placed at a regular distance increment.  If that's your situation, you'll have some further work to do to scheme up a way to trigger at the same one each time.  Linear systems will usually have limit sensors or hard stops at the ends of travel that you may need to incorporate in your homing scheme.

-Kevin P

[Rogerlu123]

Thanks for all your help Kevin! I appreciate all the help and guidance you provided me and this community!