encoder rollover

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
How do you handle the inevitable encoder rollover?
Do you do it on the fly or anticipate it at a
convenient standstill or just use a number size that
can't rollover for 10 years at maximum use?  War stories? - RM


Re: encoder rollover
Quoted text here. Click to load it

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

Re: encoder rollover
Quoted text here. Click to load it

= 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


Re: encoder rollover
Quoted text here. Click to load it



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


Re: encoder rollover
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Right. I use a 25% margin!




Re: encoder rollover

Quoted text here. Click to load it


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?

Quoted text here. Click to load it

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


Re: encoder rollover
On Fri, 28 May 2004 21:48:42 GMT, Rick Merrill

[...]
Quoted text here. Click to load it

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.

Re: encoder rollover
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

-- Rick


Re: encoder rollover
On Tue, 01 Jun 2004 20:13:30 GMT, Rick Merrill

Quoted text here. Click to load it

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

http://literature.agilent.com/litweb/pdf/5965-5894E.pdf

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

Re: encoder rollover
On Fri, 28 May 2004 20:16:04 GMT, Rick Merrill

Quoted text here. Click to load it

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.)

Re: encoder rollover

Quoted text here. Click to load it
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


Site Timeline