Position encoders

What are the advantages, disadvantages between using the motor encoder for position aquistion or putting an extra encoder on the outgoing axis of the gearbox?

Advantage: Increased accuracy. Relying on the motor encoder tells you only how far the motor turned, not how far the driven device actually moved. Properly used, the external encoder can compensate for slippage, backlash, and lots of other positional issues the motor encoder has more difficulty with.

Disadvantage: Cost and Complexity. The motor (if a servo) already has an encoder, but you must buy a separate one to mount on the driven unit, determine where and how to mount it, guard it from nasty encounters by people with fork-trucks, hook up and interface to it, etc, etc, etc. And it's one more thing to break in the system.

Resolution of position encoders

What resolution is ideal or minimal for position encoders?
In a machine we had done a retrofit on, a flying saw, where both the displacement of the saw and the length measurement of the material had incremental encoders of 5000 impulses, that corresponded for both at 10 pulses per mm.
The main reason I am asking this question is because we have to do another flying saw, but in this case the measuring wheel for length measurement will have much larger diameter, resulting in less pulses per mm (if we use the same encoder).
What resolutions have you seen already for position encoders? Do you know some rules of thumb?

Thanks

I have seen up to 20,000 PPR.

Positin encoders

Plc_User said:

What resolution is ideal or minimal for position encoders?
In a machine we had done a retrofit on, a flying saw, where both the displacement of the saw and the length measurement of the material had incremental encoders of 5000 impulses, that corresponded for both at 10 pulses per mm.
The main reason I am asking this question is because we have to do another flying saw, but in this case the measuring wheel for length measurement will have much larger diameter, resulting in less pulses per mm (if we use the same encoder).
What resolutions have you seen already for position encoders? Do you know some rules of thumb?

Thanks

Click to expand...

To specify my questions : suppose I want a precision of 0.1 mm, how many counts should my encoder then have for that interval of 0.1 mm?
Are resolutions of more then 5000 per round achievable for a quare wave encoder? If I want an encoder with more then 5000 impulses, should I better look for as sincos encoder or absoluut (SSI) encoder? In what situations should you prefer sincos or SSI or ENDAT encoders?

I've seen 250,000 ppr Canon encoders:

Is a square wave incremental encoder still a good option for those high resolutions. I point mainly at distortion of the waveform, and influence of noise. Is sincos encoder better option? Experiences?

SinCos is good but it will limit your options for motion controllers.

Good motion controllers count every edge so the counter per revolution is actually 4 times the advertised pulses per revolution or lines per revolution. I have customers with encoders over 500000 PPR on flying a rotary shears. I wouldn't be surprised if the SinCos technology was used inside or some method of interpolating between counts but to the motion controller the encoder looks like it has 500000 lines per revolution. The point is that you can get more than enough resolution with a standard quadrature encoder.

It isn't clear whether your impulses are lines or counts but I know you can easily get 10 times more resolution that what you have got with little money.

To specify my questions : suppose I want a precision of 0.1 mm, how many counts should my encoder then have for that interval of 0.1 mm?

Click to expand...

This is a common mistake. This is what I call thinking statically as opposed to thinking dynamically. At first glance if you had 0.05mm resolution you would be able to position easily to 0.1mm but the reality is that your shear is moving. This means that the motion controller must calculate accurate velocities and accelerations from the encoder. If the motion controller has a resolution of 0.05mm and a scan time of 0.0005 seconds the actual velocity resolution is 100mm/sec which isn't that good. What is worse is the actual velocity resolution is 200000 mm/sec^2 or 200m/sec^2 or over 20g!!!!

The derivative gain is multiplied by the error between the target and actual velocity but if the actual velocity is jumping around by 100mm/sec due to quantizing alone the derivative gain will not be very useful.

Obviously the master or reference encoder should be high resolution too since the slave is gearing to the position AND using the estimated master velocity and acceleration to calculate the feed forward values for the slave.
Without feed forwards is it hard to make a flying shear that can quickly synchronize to the line.

My advice is to alway get the finest resolution possible.
See this:
http://www.deltamotion.com/peter/Mathcad/Mathcad - t1p1 pid mrplc.pdf
I did this years ago to show how resolution effects the control output. One can see the derivative gain times the quantized velocity estimate makes the control output go wild. In reality the system wouldn't work as well as the simulation.

Too avoid hijacking another thread

-> You talk about 'sample jitter'. In my flying saw application with Siemens Simotion I experience this at the speed signal of the master encoder. From the outside the encoder wheel seems to run smooth but if I trace the speed I have high frequent fluctuations of the speed, and excesisve master accelerations.

Click to expand...

You can be fighting two problems. The jitter may be real. The line speed may be have jitter. Sprockets cause this. The jitter can also be caused because the sampling is done using software instead of hardware. Do not sample encoders using interrupts. There are varying delays when an interrupt occurs. The interrupts may be off for short periods of time but these off times will still cause interrupts. Also, software if full of if then statements so the code with in the interrupt will not always execute at the same speed. This results in sample jitter. The proper way to sample is to use a FPGA or some other hardware chip that can latch the encoder counts every time period without the software being involved.

Good filtering can help remove the jitter due to sprockets. Another possible problems that the act of cutting can move the metal. This causes a feedback problem where the shear affects the line speed that in turn affects the shear.

In my system I have for master and slave a final resolution of 10 encoder pulses per mm (encoders are square wave incremental 5000 ppr). This master jitter results in a very aggressive slave gearing. How is this 'sample jitter' caused?

Click to expand...

Jitter is caused by the master. The slave is simply following the master.

-> For a new comparable system I am considering higher resolutions. Final precision will be again 0.1 mm. Material speed is 100 mm/second. What encoder resolution should you advise?

Click to expand...

The more the better. Currently at 100mm/second and 10 counts/mm there are ONLY 1000 counts per second. THIS IS NOT ENOUGH!!!! THINK ABOUT THIS!!! That is only one count per millisecond! Most of the time the master is moving one counts per millisecond but due to sample jitter there will be 0 counts some times and two counts other times. How can one compute the speed with this low resolution. What about the acceleration?
If you increase the resolution by 100 times the resolution be 1 micron and the number of counts per millisecond is now 100 counts on the average. Sometimes 99 some times 101 but now the error is only 1% and the estimated velocity is now 99mm/sec ti 101mm/sec and this can be used by the derivative gain.

Can I choose the final precision of the master preciser then the slave (f.i. 0.05mm) or do I need an 1 to 1 ratio?
For higher resolutions should you advise sinuscosinus encoders or other types in spyte of square wave incremental encoders?
Thanks.

Click to expand...

Don't think in terms of gearing counts but instead of gearing positions. Any decent controller will gear by positions.

Peter Nachtwey said:

I wouldn't be surprised if the SinCos technology was used inside or some method of interpolating between counts but to the motion controller the encoder looks like it has 500000 lines per revolution.

Click to expand...

Yaskawa's Sigma-V servomotors come with 20-bit resolution encoders. I also am not sure what is actually inside, but to the motion controller it looks like there is 1,048,576 pulses per revolution.

Originally posted by LadderLogic:

I also am not sure what is actually inside, but to the motion controller it looks like there is 1,048,576 pulses per revolution.

Click to expand...

It's very likely a 512 cycle sine/cosine encoder with 2048 count interpolation per cycle.

This is the same way the encoder manufacturers get the kind of count levels Peter is talking about.

Keith

'I wouldn't be surprised if the SinCos technology was used inside or some method of interpolating between counts but to the motion controller the encoder looks like it has 500000 lines per revolution.'

Would that be a motivation to use sincos encoders?
I also know that a lot of servomotors have resolvers instead of incremental encoders, is these because resolvers have a waveform composed of sincos waves and so a larger resolution can be obtained? Is there some good literature on using sincos encoders?
Thanks

You really want to use SinCos encoders don't you?

What we are pointing out is that the encoder may or may not use SinCos internally but it should make no difference to you as long as you can get 500000 counts per revolution. Does your current motion controller support SinCos? If not then you will need to buy a new controller too and then go through the whole setup process and programming again.
The key is the resolution. You don't really care how it is done do you? I wouldn't get too excited about the technology just what it can do for you and how reliable it is.

I need to make a hyperface-SinCos interface some time and learn about what it can and cannot do. I don't know how the sin() and cos() are generated. In resolvers an excitation field induces a signal on the sin and cos windings and the decoder must use a arctan function.
I am interested in how susceptible the analog is to noise.

Keith I would rather use more counts and do a coarser interpolation of the angles.

It's been a while since I checked into this but I think there are (were??) manufacturing reasons to keep the fundamental count down. The two waveforms are generated by a rotating grating interfering with light transmission. I think as the fundamental count gets higher the manufacturers have a harder time keeping everything lined up.

I'm not sure how they do the decode function in the encoder. If they are just putting out the fundamental count they simply run the waveform through a comparator. But with the real high counts I don't know what they do.

But Peter is right. Don't get hung up on how you get 500000 counts. Just get 500000 counts in the format you need.

As for servomotors I think the whole resolver thing was based on the resolver being an inherently absolute position device with very high durability that could be used almost directly for brushless motor commutation. Now that everything is controlled digitally the choice of feedback is a little more wide open.

Keith

kamenges said:

It's been a while since I checked into this but I think there are (were??) manufacturing reasons to keep the fundamental count down. The two waveforms are generated by a rotating grating interfering with light transmission. I think as the fundamental count gets higher the manufacturers have a harder time keeping everything lined up.

Click to expand...

If that is so then how do they keep the sine and cosine waves perfectly in phase?

I'm not sure how they do the decode function in the encoder. If they are just putting out the fundamental count they simply run the waveform through a comparator. But with the real high counts I don't know what they do.

Click to expand...

I know they do some sort of interpolation. I don't know if it is SinCos though.

As for servomotors I think the whole resolver thing was based on the resolver being an inherently absolute position device with very high durability that could be used almost directly for brushless motor commutation. Now that everything is controlled digitally the choice of feedback is a little more wide open.

Click to expand...

It was necessary for commutation. Now they have Hall effect sensors