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
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!!!!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?
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.-> 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.
Jitter is caused by the master. The slave is simply following the master.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?
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?-> 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?
Don't think in terms of gearing counts but instead of gearing positions. Any decent controller will gear by positions.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.
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.
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.
If that is so then how do they keep the sine and cosine waves perfectly in phase?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 know they do some sort of interpolation. I don't know if it is SinCos though.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.
It was necessary for commutation. Now they have Hall effect sensorsAs 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.