Re: Help with DRO

>
> From: Joe Vicars <jvicars@...>
>
> I have a picture of a servo encoder that was broken and I removed it
> from it's motor. Can someone tell me which wires do what? I have 6
> more of these encoders (unbroken) that I would like to use for DRO.
> If you think you can help I will email you a Word document with the
> pictures in it. I will also include the wiring schematic for Lindsay's
> DRO.
> Help is appreciated.
>
>

Mail the pics if you'd like dfs@...

Where did they come from?

Is this a wheel with slots cut in it?

If so, if there is one set of slots, it is probably a relative
quadrature type.

If there is a bunch, in concentric rings, it is an absolute type.

As to the exact type and wire connections, that will probably take
some experimentation to determine, but knowing what it is would help
you know what to look for.


BTW, I have, or at least had C code I wrote that generated Absolute
Gray Code wheels in postscript and HPGL code to run a plotter directly
onto glass or circuit boards to be etched.

It's ugly, but works.

It could probably be modified to make quadrature encoders if
that is the goal as well.

I have printed absolute encoders at up to 8192 on desktop laser printers,
and they looked good enough to me. I never actually used one though.
They were large though.

The software had a variable that was set to the required resolution.

The wheels are going to work best at 2s power counts/rev.
128,256,512,1024.....

The idea is only one bid of a gray code changes at each step.
That resolves issues as to the exact time a bit may change, for example

000111111 incrementing to
001000000 could have 7 bit at any state during the transition, who
knows what it would read back as.

when only one bit can change at any given transition, the only risk
is you will read the old or the new value, nothing else.

Reflected binary gray codes roll over the 0 to max, and max to 0 the
same way, ie. only one bit changes, as long as you are at the values
mentioned.

If you build a wheel with say 3600 counts/rev, the transition from
3600 to zero, and in reverse, from zero to 3600, will change more than
one bit and lead to possible errors in position readout.

You could add an extra sensor for a zero transition point, and maybe
filter the error out in software though.

Marc