Position Encoding.

How so? Knowing immediately is obviously better, but - equally obviously - not worth the well-known costs of an absolute encoder.

You've effectively proposed that instead of the absolute encoder he can't afford, he should use a form of absolute encoder which would be harder to build, and which he'd have to develop himself.

If this is your idea of help, I'd hate to see you being unhelpful.

I like to make it clear what certain proposals actually entail - not a skill which you can claim.

-- Bill Sloman, Nijmegen

t t

ss

ve

We've seen how you put pieces together in other contexts. You might as well post random noise.

to

More of Jamie's random noise. I'm back on my home computer, after sharing my lap-top with my wife in Lyon, and spending most of Wednesday in trains from Lyon to Brussels and from Brussels to Nijmegen. Not activities that Jamie seems to be capable of registering.

-- Bill Sloman, Nijmegen

Tim Wescott is no immortal, but I have certainly learned something useful about pseudo-randon binary sequence generators by participating in this thread.

Search for "A W Sloman" on scholar.google.com There's not a lot there under my name, but one paper has racked up 14 citations (only two of them from me). Have you done as well?

-- Bill Sloman, Nijmegen

I don't understand your statement? These were absolute position encoders, I could get position information any time I needed it.

They didn't have to move. they simply wrapped around back to 0 when the position over flowed on the encoder wheel. The software knew exactly where it was at all times even if you repowered the system.

I used 16 photo sensors in an array with wide emitters to light up the back side. This generated a Gray code output that I had place in the transparent photo wheel, done at the film shop for me.

yes, they were a little bulky for the their time, photo detectors were not as small as they are now.

We drilled a holder array with slight over lapping holes and placed flats on the detectors so that we could get them in there close.

We had to use a computer graphics program on a C-64 to create the image on the printer. Back then, these programs were not available like they are now.

In any case, movement was very accurately tracked and just vibration of the machine cold be detected with this.

64k indexes is a lot of positions and the software trimmed off the lower bits in most cases (MOD operation) however, the lower fine res was used to indicate if we did have excessive machine vibration in the drive axes.

Maybe we are talking about something else here?

Jamie

Perfectly true. There are many more clever circuits that don't use a

555.

No.What I'm saying is that what it did in the 1970's is now almost always done - more cheaply and better - by other means.

The first time, it couldn't produce a particularly stable pulse width. Thereafter, it didn't fit into the design for one reason or another. I never had to devote much time to working out why I wasn't going to use it - there was always some fatal flaw. For a while I did have to answer the question "why aren't you using a 555?" but people stopped asking that sooner than they stopped asking "why aren't you using a

741?".

-- Bill Sloman, Nijmegen

Try doing the math--it isn't difficult. Decentration error is the main problem with encoders.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

e

Than the other candidates that you can think of, used in the way that you are used to using them.

There may be. I haven't seen one yet, but I'm not into 101 things a boy can do with a 555.

Phobic behaviour? I just point out that I got through my entire career without using it, and none of the people I worked with ever seemed to put it into any of the design I got to look at (and there were a lot of them).

Yes. You do seem to suffer from tunnel vision.

The bunch of detectors trying to see individual elements on that track,and the housing that stops them from seeing adjacent elements.

It's actually the track that your two quadrature detectors look at, through two different masks on the same static piece of glass or tranparent plastic. Neither of them need anything in the way of lenses or screens to block stray light.

Very ineptly.

Ignorance is bliss.

For certain - rather bizarre - interpretations of "reality" and "proof".

It's practicable in many more applications than its practical, and is

- nowadays - very rarely a component of the cheapest or best total solution, even if it still figures in the cheapest and best solutions that you can come up with.

But there are a lot more incremental encoders around than absolute encoders, so the applications don't seem to favour the absolute encoder.

-- Bill Sloman, Nijmegen

Phil, to be honest, I had to looked that up to see what you were referring to. It appears what i did, if I understand this correctly, years ago didn't have the effects you have in mind. The process we used just didn't suffer from that. Hours of flawless operations proved that.

If we used a non gray coded system, we then would have serious issues in implementing such an encoder.

P.S.

we did have a centralizing track on the out side to insure the encoder was centered however, we found it did not matter either way if we used that or not. all it did was perform a latched read in the serial shift register after a few usec of stable reading, which would indicate a locked position. But we found that if we simply queried the position when needed with a polling latch read, no matter if the encoder was still or moving, we got the same stable results.

I know you're way above me on photo technology.

I think we are talking about two different things here.

Jamie

If your "film" is off-center, it will give a position error. Think of a record (remember those round vinyl things?) with the center hole punched off-center. You get a "wow". The same would happen with your encoding disk.

Yes, but the position accuracy depends on how closely centered the encoding disk is.

accuracy resolution

Being cited 14 times is "doing well"? Pitiful.

John

Centration = shaft runout.

John

...

One way to minimize centration errors uses an image of the wheel 180 degrees opposed instead of a stationary mask. When one radius is long, the other is short, so the error largely cancels. Of course, for the same angular resolution, the disk needs half as many lines.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

if I turn the encoder exactly 180 degrees I get 32768 , and at 90, 45 degree increments they all partition on the mark. Zero index was repeatable. And repowering the system will return the same encoder position at all times until we move it again, be it with power on or off.

And test done between that also showed this. The film shop was able to resize and enhance the image to get what I would consider back then a near perfect round encoder image.

Lets put it this way, we laid that image onto a clear form that was cut for us with in 0.001 and the image edges on all four sides dropped in on target. Eccentric run out was virtually not measurable. This part of the encoder was done in a machine shop by a friend of mine.

I don't understand the skepticism ? Its been done and used heavily for a few years until the machines gut upgraded totally and switched over to fiber optic ABS encoders. Those I can say had issues. For what ever reason, you did not want too much machine vibration with those, they'd lose their 0 position. Also, the way they behave would indicate they didn't have an ABS disc in them. They acted like nothing more than A,B encoders with internal counters to a fiber converter. But the resulting data was a 12 bit information packet. I've seen incremental encoders not to steady under vibration and if you don't have the proper type of directional decoder circuit, it turns into a nightmare.

THe most simplistic scheme I've used for this is a pair of D-FF working with each other. I guess not every one does it the same way.

Jamie

How did you measure the exact 90, 180, 270 degrees, etc? A theodolite? An autocollimator? Another encoder?

I have no doubt that you got exactly 32768 pulses per rev, but that isn't the issue. Say for argument's sake that the rotation axis is fixed at a distance R from the sensor, that the sensing area is vanishingly small, and that the wheel consists of 32768 perfectly accurate triangular sectors, alternating black and white. If the centre of the wheel coincides with the rotation axis, all is as in the Ukrainian rowboat(*)--each tick corresponds to exactly the same rotation, because the width of each sector passing under the sensor is exactly W=2*pi*R/32768.

Now imagine that the wheel is mounted R off centre. Pick the angular origin so that an angle of 0 degrees means that the centre of the wheel is on the opposite side of the axis from the sensor. Set the shaft rotating slowly.

Near phi=0, the width of the stripes passing under the sensor is

2*pi*(2R)/32768, i.e. twice as wide as they should be, because that point is twice too far from the wheel's centre. The detected rotation rate is half the true rate.

Near phi=180 degrees, the width of the stripes goes asymptotically to zero, so the detected rotation rate goes asymptotically to infinity.

For intermediate-sized decentrations, you can calculate the error by figuring out how wide the sectors passing under the sensor are as a function of angle. It's simple plane analytic geometry.

Cheers

Phil Hobbs

(*) i.e., hunky dory.

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

Software

A synchro/resolver is a really, really good angular position sensor. Resolutions go to arc seconds, and they are very rugged. I'm designing a synchro simulator board now, and with mere 16-bit ADCs and DACs, I'll be at the low end of the accuracy market.

John

Phil, I think I follow you now, but I think you also have assume what I have not done.

First of all, we used a passive detector, not a reflective. I don't know if that really makes any difference? Secondly, we used 16 rings on the wheel plus a out side index ring for the 16 ring center row alignment. Thirdly, we use gray code for which these 16 rings do not line up, they over lap. The outside index row can aid in that how ever, like I said before we didn't need to use it. It didn't seem to give us any advantage.

The LSB (least significant bits) were on the outside and MSB on the inside. With the track alignment as it was, the worse case you'd get was bit 0 being a little shaky, Your output would alternate +/- 1 click but never lost position.

Calibration was verified on a CNC rotary vise and verified to match before we did the rest of them. The machine shop with their tools verified the rotation calibration. They also did the construction that held the optic disc with the precision drive bearings.

The disc was 6 inches in diameter, back then it was hard to print out and photo correct images that precise. Also like I said, putting 16 photo detection diodes in a array is tricky.. These had focus optics which worked out nicely. I am sure you've see them before.

The track width for each was more than wide enough to account for even a sloppy drive shaft or miss center. We just placed the detector array in the mean center.

When I left that place, years ago, they had updated the machines completely using fiber optic encoders which apparently didn't work out as they had hope for. They learned to live with the problems. THey had to, the big shot had already signed off on it. It was done via contractor instead of in-house due to work load already for other projects at the time and engineers leaving for more money..

I had to trim this post down, hope you don't mind..

Jamie

Well, he proved that Jamie hit the nail pretty square.

I haven't read the entire thread, but how is this different from a simple serial self-clocking encoding of the position? If you encode say 64 positions using a Manchester encoding of a 6-bit word, with appropriate start bits and parity, etc as needed, then you only need to rotate 1/32 rev before you have an absolute position; and the individual bit positions gets you better than 1/512 resolution from there.

I was thinking whether there was a more cunning way to do a continuous bitstream of BCH-encoded words, with the words chosen so as to *overlap*. Not sure how to choose the words (other than brute-force), but that would additionally give you error correction with a minimum rotation before getting the absolute position. I'm sure there exists some cunning plan like that anyhow.

Clifford Heath.

Wrong. They are separate. AND a moire would require two intersecting screens of slots, not two detectors, Nice try though, ya dope.

They (the detectors) get set so that their leading a trailing edges trigger in step, not synch, such that it can double the resolve normally associated with that particular slot pitch, and determine direction of rotation.