That encoder stuff.

Hi,

No one has come up with any good answers to my question, - those
zig zags. So I am left with my initial thoughts about it. I just
share this with you.

Bertho says: You will have a varying light from 0 to 50%, - (for
short.)

Okay, this means that if you had a linear light sensor, then you
should have a sine output. I am not sure, it could be a
triangular shape.
The other thing is that a semiconductor photo sensor, is non linear.

So what I always have thought is that - if you calculate the
transfer function and you would like a sine, then you offset parts
of the gratings to match the transfer function. In computer terms,
it like having a lookup table. Say that you rotate the disk by 1/4
of line spacing. You would think that the amplitude should be 25%
of the max. value.

But to have a sine, that is 45 degrees. The amplitude should be (
0.5 * 2^0.5 ) ( I don't have a calculator nearby - that's why I
wrote it this awkward way - but I think it should be 0,7 something )

So I believed that the gratings was offset so that the light
intensity -> to electrical amplitude was modified by these "zig
-zags". This has just been what I thought myself, but I raised the
question because I am not sure. All I know is that it is difficult
to get a sine wave that keep it's shape independent of the angular
velocity.

The L290 chip from SGS is a 14 pin dip package that will give you a
tacho signal from an encoder, but in order to have it linear, you
have to use encoders with a perfect sine wave. I have not been able
to get it correct with the encoders I have.

But here is something else:

Bertho, - you suggest a micro controller servo, and you would like
to get rid of the tacho generator. Well, when I just wrote this,
then another solution appeared. If this chip was read with ADC and
you used lookup tables, then you might be able to correct it for an
"off the shelf" encoder. But that doesn't look like any good
solution - when I think of it.

What would be the fastest way to read the velocity ?

tmp = read_encoder_cnt;
current = tmp - previous;
previous = tmp;
velocity = look_up_table( current );
?
I just don't like it. The dynamic range you need is very large,
the response has to be rapid, and you also need direction info.

I made a digital servo like this, with a 68HC11. I generated the
PWM and everything, and had a command interface similar to LM629.
The stupid thing I did, was to use some encoder inputs with very low
resolution, and this may be some of the reason that the whole thing
did not behave as I had hoped for. I also had PID filtering, and
the thing was quite okay when it was running in mid range - say you
were to run it at 50% speed, then change it to 75%. The trouble
came when you came down to a crawl or changed direction. It was
difficult to get a linear transfer function, and good stability at
the same time.

It is several years ago, and I lost the code and my measurements due
to a disk crash. All I am left with, is some of the impressions I
have of it. I may have done several things "wrong" - but with out
the data, I can't tell what this might have been. I just remember
I tried several things to get a good velocity response, and I
disliked all the time it took to do the calculations - in order to
get it as I would like it. Then several other things made it
complicated, that was to close the position loop, - the trajectory
calculations, etc.

I then tried out something on a 8051 variant, but came to the
conclusion that I needed several things done with digital / analog
circuits, and less software. I never finished this attempt. Then I
made some ISA boards with LM629's, but that is another story.
But at the present moment, I don't have much of anything left - due
to the disk crash.

By the way, I also did something with dac/adc boards, and did the
servo controll in the PC, but this was not servo drives for
machining.

//ARNE