Encoder Triggering at Tick Interval

[LyncLuke]

I am working with the NI PCIe-6343.  I have a quadrature encoder with no z channel, just A, /A, B and /B.  I do not need an absolute position as my 0 position will be relative to the start of each run.  I have a 10000 point encoder and it will eventually be rotating at roughly 65Hz.  I need to accomplish the following:

1. Counter the number of ticks on the encoder, accounting for direction.
2. Every N ticks, generate one 100 microsecond pulse.  (Ex: at 1000, 2000, 3000, 4000, etc ticks, generate the pulse.  If it reverses from 4100 to 3600 the next pulse will be 5000 [later goal])
3. Manually designate a 0 position either by digital signal or software (later goal)

So far I have based what I've done off the Measure Angular Position example.  I can count the ticks up and down.  I can separately generate the 100us pulse using the DAQ Assistant.  But I have not bee successful in combining the two processes.

I currently have it setup to have A and B go to ctr0 (PFI8, PFI10) and the output to ctr0 (PFI12).

[Kevin_Price]

It may help if you can explain a little more about your system and the reason for the requirements you laid out.  I'm pretty sure you won't be able to meet them all with hardware alone, and I don't know if software-based approaches would be appropriate for whatever it is you're doing.

1. Counter the number of ticks on the encoder, accounting for direction.
2. Every N ticks, generate one 100 microsecond pulse.  (Ex: at 1000, 2000, 3000, 4000, etc ticks, generate the pulse.  If it reverses from 4100 to 3600 the next pulse will be 5000 [later goal])
3. Manually designate a 0 position either by digital signal or software (later goal)

1. Your device's built-in quadrature decoding capability can keep up with your ~650 kHz encoder pulse rate, tracking incremental position that includes direction changes.  So far so good.

2a. A 100 usec pulse every N ticks is possible, but trickier.  You actually have to use 2 counters working together to accomplish this.  One derives its "timing" from the ticks coming in and issues a pulse every N ticks, regardless of encoder speed.  The other derives its timing from an internal timebase and can generate the 100 usec pulse -- again, regardless of encoder speed.  The second counter needs to be retriggerable by the output of the first counter.

2b. To the best of my knowledge, making this happen at each unique point that the internal count register reaches an exact multiple of 1000 is NOT possible with the hardware.  A scheme like I outlined in 2a can only work out for UNI-directional motion, not BI-directional.

3a. This probably won't be possible to do perfectly.  You can *try* to generate your own simulated Z-index signal but you'll have 2 further problems to solve:

• you somehow need to make it align with sufficiently with your A,B quadrature states that the reset to 0 occurs at a repeatable encoder angle regardless of motion direction.  You'll find that this is harder than it sounds, especially when coupled with the next constraint
• your task will need to designate the quadrature state during which the Z-index pulse must be present.  If the pulse is short and doesn't span the correct quad state, no 0 reset will occur.  If the pulse is long and it spans the correct quad state across multiple cycles, the 0 reset will occur multiple times.  Neither is what you want.   Timing and alignment are both crucial and rather difficult to accomplish.

3b. You're not going to be able to set a repeatable 0 position in software either, at least not while in motion with an encoder rate of 650 kHz.  If you also have *control* over the motion, you can probably get repeatability within some reasonable tolerance by establishing a careful homing routine, always approaching the home sensor from the same direction.

-Kevin P

[LyncLuke]

Thanks for your comments.  I have read a few comments regarding the capability differences with uni-directional vs bi-direcitonal movement, but I haven't been able to grasp what the specific mechanisms are regarding this.  I am primarily working in a single direction, probably 99%, but I don't want to mistake a brief travel in the reverse direction for additional travel forward.  When I refer to the manual 0 position, it would be something that occurs once before movement begins, not a recurring synchronization like a Z signal would typically provide. 

Basically, my encoder would be mounted on a track.  As the mounting platform travels along that track, the encoder will spin at a dynamic rate.  The starting position is 0, and I will generate that 100us pulse at a discrete distance interval along the track.  I understand that the encoder will need one clock and the timed pulse will require a second.  I was under the impression that the clock speed for the timed pulse would be sufficient for checking the encoder counter more quickly than the 650kHz generated by the encoder.

[Kevin_Price]

Uni vs. Bi:  the core issue is that all the timing & triggering config you can set up is based on digital edges or states.  Rising, Falling, High, Low are the things that matter to the hardware logic circuitry.

    Meanwhile, you want to react to a *count* value, which is held in a storage register.  The count however is not a signal and it doesn't propagate out to be able to perform the functions of a digital edge or state.  You can't trigger another counter to generate a pulse based on the instantaneous count value held in your encoder counter's count register.  You have to approach things indirectly.

    In Unidirectional mode, you can know that for every 1000 rising edges of encoder channel A, your count value will change by 4000 (assuming 4x quadrature decode mode.)   So you could configure another counter to generate a pulse once every 1000 rising edges of channel A and you would know that it was going to occur every 4000 counts.  Both the count value and the output pulse are direct effects of the same cause so they stay in sync.

    In Bidirectional mode however, 1000 edges of encoder channel A could change the count value by any amount from 0 to 4000, depending on if and when the direction change happens.  If the other counter generates a pulse every 1000 edges, you can no longer count on it being correlated to the count value.  That's the fundamental problem trying to accomplish this under bidirectional motion.

The need for 2 counters to accomplish 100 usec pulse every N edges of ch A isn't about speed.  Not exactly.  It's just that you need to rely on a variable timing source to accomplish the "once per N edges" part and a constant timing source to accomplish the 100 usec part.  A given counter gets its timing info from only 1 source, so when you have 2 different kinds of sources, you need to program 2 counters to work together, each getting its timing info from just one source.

-Kevin P

[LyncLuke]

This is what I've managed to accomplish so far which I thought I uploaded before.  I imagine the timing would not be ideal in this setup and I guess this is where the two different clock settings comes into play...  I may be mixing up 'clock' and 'counter' in my thinking.

[LyncLuke]

On further testing, would I need / or be able to accomplish what I'm discussing with an FPGA I/O board instead of just a DAQ?

[Kevin_Price]

Though I'm only minimally familiar with FPGA, I would say that yes, to respond quasi-instantly to specific count register values, you would need an FPGA implementation.

However, once you drop down to FPGA you may also need to tackle more responsibility for sampling and quadrature-decoding the encoder signals. I'm not really sure about this though, it isn't something I've ever explored.  And it might also be something that depends on your specific chassis and module.

I can't look at your LV 2024 code unless you save it back to an earlier version (preferably to 2020 or earlier) and repost.

-Kevin P

[LyncLuke]

I believe this should be V20. 

[UliB · Accepted solution]

---

@LyncLuke wrote:

On further testing, would I need / or be able to accomplish what I'm discussing with an FPGA I/O board instead of just a DAQ?

---

If I understand your requirement correct than: Yes.

I once implemented something like that on a FPGA Board.

I had a A/B/Z Counter in FPGA (one pulse represented 20nm) and when moving in positive direction and reaching upfront computed counter values (about 16000 values) I set eight digital lines to a new pattern.