encoder rollover

It you are talking about a rotary encoder in which you only need to know the angle, you keep the count mod FULL_REV_COUNTS. You can directly subtract angles and easily adjust.

For linear encoders with fixed travel, you should be able to handle the full range.

For unbounded counts, such as odometer ticks or accumulated angle over many revolutions, you probably want a sufficient range such that overflow is not a factor.

What is you application?

Thad

= Rotary encoder for measuring wire. The app uses the position for feedback to another axis. Let's assume the wire * never * stops and the second axis must stay accurate (forever). - RM

and..

There are several types of rollover here. First, depending on what you use to read encoder counts, there is a rollover when the number of bits in your counter is exceeded. A 16-bit counter will roll over from FFFF to 0000. This type of thing is handled by extending the counter in software. When there is a transition where the sign bit changes, then you use the signed difference between the two consecutive readings to decide if the extension should go up or down by one count. For this to work you must guarantee that your software will read the raw encoder often enough to detect changes before they reach approximately a half of the counter range (Hex(8000) in this example). This type of rollover has nothing to do with the application, only with the hardware used to do the reading.

But from your second posting it seems you are talking about the kind of rollover that defines a complete revolution of the encoder in the application. You want to know the position modulo one revolution - that is, you want to know the phase. This is handled by deciding upon a unique representation for any phase. For example, for 1024 counts per revolution you can decide that the phase should always be between

0 and 1023, or between -512 and 511. Whenever a position is read that is outside this range, it must be reduced by adding or subtracting multiples of 1024 as needed to make the result lie within the pre-determined range. This can be done by maintaining an offset that is applied to every encoder reading, and modifying the offset as needed. But if you should ever encounter the kind of rollover described in my first paragraph, then you will have to apply that type of correction to both the raw encoder reading and the offset.

Even with all this, it might still be insufficient for your app. If you are using the encoder to maintain lock between two axes, then you need to maintain phase over a range large enough to encompass all expected phase differences. Using 1024 as the number of counts, if the two axes were ever to drift out of phase by more than 512 counts, then the action of a typical phase comparator in software would be to begin applying feedback in order to let that one cycle go and try to lock up with one reel being one complete cycle ahead of the other. I imagine this would not be good for your wires. In that case you have two options. One is that you can try to ensure that the axes never get more than 512 counts out of phase so that this bad thing never gets a chance to happen. The other option is to maintain phase modulo some larger range, such as two or maybe four revolutions.

You are right in looking critically at the use of encoders in this application. It is rife with possibilities for failure. But if you carefully think through the various boundary conditions you can make it work.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Let me see if I understand. You use an encoder to measure wire, which is unbounded. The result is used by a another control, presumably to match the length, so that for every cm of wire on axis 1, you apply so much insulation (or something) from axis 2. The ratio between the wire length and whatever is being controlled on axis 2 is constant.

If that is the scenario, allowing rollover at a specific point makes sense. It can be 1000 ft., 1024 km, 2^32 encoder ticks, or whatever you want. Motion can be bi-directional if needed.

The essential point is that the second axis is slaved closely enough to the first so that if the last axis 1 position is x and the new axis 1 position is y, it is always obvious WHICH version of y it is -- the previous, the next, the one after that, etc. In other words, if the maximum difference between two axis 1 readings is x, a rollover value of at least 2*x+1 becomes unambiguous. In general, you probably want healthy margins for the rare cases in which the differences can be extraordinarily large.

Thad

There's the rub: it is not a constant ratio but a periodic action (hard real time) that is done with precision by a (h/w) comparator that matches the current wire length to a preset value; after the comparator fires then the upper level program (soft real time:-) loads the next value; rollover must be anticipated so that the (dumb) comparator is given the rolled-over value to watch for.

BUT (you knew there was going to be a 'but') to keep within the current low level library our present solution is to see rollover coming and force the wire position to a new value by resetting the wire 'position'. This introduces some error (read, modify, write) because we are ignoring velocity.

Happily we never go backwards (well, hardly ever).

Right. I use a 25% margin!

address is fake.)

Thanks Robert. Plus there is always the hope that next generation harware will put the rollover point well beyound the length of the wire/run/10yr mark! - RM

That sounds straight-forward so far. Wire is rolling. When the incrementing encoder value matches a given set point, the comparator fires, which does something to the process -- cut the wire?

What do you mean by "force the wire position to a new value" and why do you do it? Why does it matter that the encoder value rolls over? Does your comparator use a greater than or equal comparison? If so, I see the problem. It is possible to construct a comparator (or implement code logic) that handles rollovers gracefully.

I have done that for 16 bit timers, which roll over. I can compare the current time to a target time. I restrict the range so that you cannot set the timeout value to more than, say, half the rollover period into the future. With that rule, you remove the ambiguity: if the target time is slightly less than the current time, it is an expired timer, not a point far into the future. To remove the rollover concern for comparison, subtract the two values, modulo the timer / encoder range.

Thad

[...]

I'm hoping I'm not misunderstanding the question...

Does the second axis depend (or can it be made to depend) on a relative position rather than an absolute position? Can the maximum value of the raleative position be bounded (i.e., guaranteed to be less than, oh say, 4294967295? If so, it's a trivial matter of unsigned math.

For example, if your encoder is counting up, something like

new = Read_Encoder(); rel_pos = new - old; old = new;

Where new, old, and rel_pos are all unsigned. Unsigned rollover handles overflow for you. E.g. (using 8 bits), if new = 0x0A and old = 0x05, rel_pos will be 5. If new = 0x04 and old = 0xFF, rel_pos will be 0x05 (again).

If you have 2's complement arithmetic and manage it carefully, rel_pos can be signed, and negative motion can be measured as well.

HTH,

-=Dave

--
Change is inevitable, progress is not.

That is sort of what I do now. But to let other parts of the system read the values we force the rollover, change the current position, and carry on. It is during the "change" that errors will creep in because we do not use the wire velocity in the calculation.

Ah, the good ol' days of 2's complement! (gone forever?)

-- Rick

Not sure how you read the encoder, but we use these chips for a custom wire winding control box:

With a 16 bit counter, plus the fact that the chip keeps track of the direction and counts up/down accordingly, the interface to read a quadrature encoder is trivial.

Of course, overflow is still an issue, but with the read timing constraints relaxed due to the above chip it is easy to use unsigned math to determine the delta. Then convert the result into a single- or double-precision floating point number to track absolute position, length, etc.

--
Michael McCulloch