Encoders? Karl?

The servos on my mill have sinusoidal encoders which are not compatible with most CNC control stuff.
I am looking at various options.
One is to make a converter to convert sinusoidal to quadrature. It is a pain in the butt to do due to lack of documentation on what wire does what.
Another one is to reuse a converter board from the existing Heidenhain controller. Same issue as above. (and I do have documentation, it just does not say what is what).
I have opened up one of my servos to see the shaft. It is a 10mm shaft.
For that size, US Digital has suspiciously cheap encoders E7P:
http://usdigital.com/products/encoders/incremental/rotary/kit/e7p/
They seem like they will fit, however, I am slightly surprised at the price.
I Wanted to know if anyone has any suggestions, as I do not want to go a wrong way.
i
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus21167 wrote:

Those are pretty low resolution, only up to 720 CPR. The encoders on the CNC machines I used to work on were all around 2,000 CPR. You have to do the math with your ballscrew pitch to figure out what the final movement resolution is, but I expect it will be far too low. Also since this is a servo setup, the minimum servo error with such a low resolution encoder could equate to an unacceptable position error at the cutter.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Well, on the back of the envlope calculation is: ball screw pitch 1/8" (0.125"). Pulley ratio 1:2. So, 720 CPR results in
0.125"/2/720 = .0000868 inch per cycle OR 0.002mm
That would be acceptable to me.
i
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus21167 wrote:

.0000868" per count * servo error tolerance of +/- 128 counts (256 count window) = 0.0222208" error which is very significant and would not be acceptable to me.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

that sounds bad!
i
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus21167 wrote:

Bingo! That would be why the "big boys" use 2,000 CPR or better encoders.
What is the CPR on your current encoders?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I am confused.
Your accuracy number for my example was 0.02".
If you increase the count by 3 times (as in your mention of 2,000 CPR) then the accuracy only improves to 0.006", also an unacceptable number.
Something is not right.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus21167 wrote:

I think the issue is encoder "lines" vs. "counts". The encoders on the machines I worked on were 2,000 line encoders, which as Karl noted could provide 8,000 counts per revolution. The US digital site uses counts, so presumably the 720 CPR encoder is 180 line?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The terminology on this is terrible. Multiply the USdigital number by four to get counts that your control will see.
karl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Karl Townsend wrote:

Lines = Number of physical lines on the encoder disk
Counts = Lines * 4 (leading and trailing edges of the two quadrature channel signals)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

yep... and I have some cheap motors from old TI printers that have 720 LINE encoders. These are from the mid-80's, and they were not high-end expensive equipment like CNC mills or lathes.
LLoyd
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Lloyd E. Sponenburgh" wrote:

The resolution (within reason) isn't the expensive part, the rugedizing to survive a machine tool environment is.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

could
so
If, in fact, that's the case, then it's a huge difference.
But still, that only gets you to roughly 11:1 better than the .02 error... and a thou in CNC work is NOT good enough!
The thing about a servo missing up to 256 counts in a full-excursion run is nuts. My OLD R2E4 doesn't do that sort of thing. Newer, more capable servo drivers and faster encoders couldn't possibly miss that bad.
LLoyd
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Lloyd E. Sponenburgh" wrote:

+/- 128 counts isn't the same as missing by 256 counts.
Some servo drives will have much tighter tolerance, and that is the limit under load, not normal. I used +/- 128 in the example since that is the max error of the popular Gecko servo drives, more than 128 off and it will generate an alarm to stop the control.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Thanks for doing the math, Iggy.
Bingo! You win the big teddy bear.
If a servo misses re-positioning 128 (or 256!) times in a full stroke of the machine, it's undersized, or being driven too fast.
I have a couple of machines that would upchuck if they detected TWO missed steps in 38".
LLoyd
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Lloyd E. Sponenburgh" wrote:

You're confusing cumulative error in a stepper system with the non-cumulative following error in a servo system.
A servo system needs fine encoder resolution so that the servo loop can function properly and hold position against loads. The max following error is the point that the servo will alarm and shutdown. If the system is designed correctly, 128 counts should translate into something like 1/10 of the nominal position resolution of the system, like 0.0001" if you expect to utilize 0.001" positioning.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Pete C." wrote:

For a home machine, I would want accuracy at least to 0.001", so the normal servo error window would need to be ~0.0005" or so to be acceptable. The big commercial machines hold much tighter accuracies, to the extent of using liquid cooled temperature stabilized ballscrews, double servos with glass scales on the machine, etc.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pete C. wrote:

FANUC's latest "off the shelf" nanometer resolution rotary encoder technonogy runs at 16 million CPR. The cheap stuff, what you'd see in a 0i is a million and it really is inexpensive.
--
John R. Carroll



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 4 Jun 2010 12:27:41 -0700, "John R. Carroll"

We've got some linear enocoders that are 100nm resolution, over fairly long scales. That's four millionths of an inch.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Spehro Pefhany wrote:

That's pretty good. It's easier to up the ante with a rotary unit than it is with linear measuring. 100nm is exceptional in a linear system. Probably costs a pretty penny.
--
John R. Carroll



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.