Use Counter to Trigger based on Quadrature Encoder input

[Gregory]

A follow-up question... is there a way to trigger off of a "CI-Position-Linear Encoder" task? For example, could I output a pulse after the task reads a certain number of units?

The counter output task works great for a single channel, but I'm a little worried about picking up false movements. If I could make use of both channels from the quadrature encoder, that might be a better solution.

[Kevin_Price]

I'm not aware of a clear and direct way to do that.  This kind of thing has come up several times in the past, and I don't recall a hardware-level solution that's based on (potentially) bi-directional quadrature *position* increments. 

-Kevin P

[Gregory]

I found a post that looks promising. (The poster states it is a roundabout way of doing it, not clear and direct!).

https://forums.ni.com/t5/Multifunction-DAQ/quadrature-encoder-based-triggering/m-p/3126154/highlight...

They use the counter output event as the z-index to reset the position count. This could only support unidirectional motion, but that will be fine for me.

Unfortunately I don't have a way to simulate the B channel yet, but maybe I can rig up some function generators to experiment a little bit.

[Kevin_Price]

Here's the sticking point about the example you linked: the counter output event pulse can be very short and may not occur at the right time.  I think the pulse width is only 1 cycle of board's timebase -- but unsure whether it'll be the master timebase (100 MHz with the 6612 or X-series) or the 20 MHz timebase (which is what I recall observing, but it was way back when I was probably still messing around with older boards).

"Z-index reload" will only actually occur if the pulse happens during the specified phase of your A,B channels.  So you end up with only a 1 in 4 chance of doing the Z-index reload.

I remember trying to scheme up a way to lengthen that pulse by using it as a trigger for another counter set up as a retriggerable single pulse generator.  But I think I got stuck when trying to sync it to the A,B edges the way a real Z-index signal would be.

<a little time, a little searching>

Some of my musings from 15+ years ago can be seen here.  Reading through it, I'm pretty sure the newer devices that weren't around back then (6612, X-series) still have the same constraints.  I mostly kinda skimmed my further thoughts about the external flip-flop-like circuit.  If it sounds promising, I'll review it more carefully.

-Kevin P

P.S.  A little more info and complaints about z-index reload and the need to specify A,B state can be seen here.  I later copied that stuff into the Data Acq Idea Exchange and at least part of my wishlist made it into the X-series boards and the 6612.  (Edge-based count reset - though only in edge counting mode not in encoder position mode, and buffered counter output).

[Gregory]

I see, there was a mention of setting it for the X1 encoder scheme, because X4 may cause the Z-index reload to get skipped. Also some mention of using digital filtering to help synchronize some timing. I'll have to play around once I get my stages and see if I can get this working.

[Kevin_Price]

It's worth a try.  It's been more than a decade since I was doing motion and encoder work pretty regularly, so I'm counting on my memory about a lot of this stuff -- and that isn't improving over time!

It's possible that the real rule is that the terminal count pulse will last for 1 cycle of the counter's Source input.  In pulse generation mode, it's most typical that an internal timebase will be routed to the Source pin to act as the timekeeper for the pulses.  That would explain the 50 nanosec pulse I remember observing. 

    However, in your less conventional pulse-making encoder task, the counter's Source pin is connected to encoder ch A.  So if the output pulse lasts 1 cycle of ch A, that'd correspond to all 4 possible A,B state combinations.  And if you're in X1 mode, it won't matter whether the correct state combo is the 1st, 2nd, 3rd, or 4th one you encounter after TC the way it could matter in X4 mode.

I'm curious what you find.

-Kevin P

[Gregory]

Ok, I've setup 2 function generators with a 90 deg phase difference. The blue signal is triggering off of the yellow signal.

Channel A and B signals

If I set it for X1 encoding, it does seem to catch every counter output event as a Z-index reset. The tick count doesn't rollover at all. If I set it to X4, then it rolls over and I would have to wait a long time for it to get back to 0.

It seems to be working reasonably well. For example, if the channel A and B frequency is set to 500 kHz, and the Z-index reset is set to 10, then my counter output event has a frequency of 50 kHz. The only thing I don't like is that the counter output event jitters around. On the oscilloscope, if I trigger off of Chan A, the counter output pulse just flies around on the screen. In the picture below, I triggered off the counter output pulse, but you can still see the jitter because there are 2 pulses where there should be 1. I'm not sure if this is acceptable or not. If one counter output event is off by 1, the next by 0, the next by 1, then it's probably fine. If it's off by 1, then 2, then 3, then 4... then I can probably just subtract one from my tick interval. But that didn't make the oscilloscope trace look any more stable.

Yellow: Chan A input, Blue: Counter output event

Edit: the jitter may be from the way I have the function generators set up. I'm using "burst" mode to trigger a couple thousand pulses. And while it looks pretty well synced up on the oscilloscope, if I trigger a longer burst (ex: 100k pulses) then the function generator signals are not synced up anymore. So, I think something is going on at the start of every burst, which may be causing the jitter I see on the counter output event.

[Kevin_Price]

From the 2nd pic, it does indeed appear that the output pulse lasts for 1 cycle of the A channel (which connects to the counter Source pin).

When you triggered off ch A, it's no surprise the output pulse was jittering all over the place.  You get 10 cycles of ch A for every output pulse and each time the scope retriggered off one of those ch A signals, there's no telling what the *phase* was relative to the output pulse.  Maybe it was the 1st ch A edge after the previous output pulse, maybe the 10th, maybe anywhere in between.  So that'd make the position of the output pulse jump around in a seemingly random way.

Unsure what to think of the double pulse appearance in the 2nd pic.  If you're triggering off the output pulse, it sure seems like you at least shouldn't have any doubling-up right at the trigger position.  Is there some scope setting that might superimpose multiple passes over the time window represented by 1 screen?

In any event, the *main* effect seems very promising.  It'll be good when you can connect an actual encoder and test things out while injecting actual direction changes.

-Kevin P

[Gregory]

---

@Kevin_Price wrote:

Unsure what to think of the double pulse appearance in the 2nd pic.  If you're triggering off the output pulse, it sure seems like you at least shouldn't have any doubling-up right at the trigger position.  Is there some scope setting that might superimpose multiple passes over the time window represented by 1 screen?

In any event, the *main* effect seems very promising.  It'll be good when you can connect an actual encoder and test things out while injecting actual direction changes.

---

I have the averaging turned off, but it does kind of flicker around, maybe if the trigger is not quite as periodic as it would like. It's just a visual thing though, if I pause the scope and run it just once, I only get a single output pulse as expected.

Luckily, I think I can get a loaner stage in next week, so I should be able to make some good progress then.

[Gregory]

I got the demo stage in, and I've had good success so far! I found some encoding types and z-index phase relationships work reliably, while others have a high chance of missing the reset and rolling over. I can get X1 and X2 encoding working reliably, but not X4.

I am using units of "Ticks" when creating the "CI Linear Encoder" task. Something interesting I found is that "initial position" and "z-index value" are automatically scaled depending on the decoding type. For example setting a z-index value of 100, actually sets the following z-index values:

X1 : 100

X2 : 200

X4 : 400

I also found that enabling digital filtering on the encoder inputs is essential to get periodic spacing of the trigger pulses.

I've run some tests where I move the stages a certain distance, and count the output pulses. For example, move the stages 10mm, trigger every 100um, and get 100 counter outputs. I get the desired number of trigger output pulses reliably. I also read the current position (which should be around 100um at the end of the move. The variation corresponds to about 1.5um, which could be chalked up to the accuracy of the stages. All in all, I'm pretty happy with how it is working!