[aubreyj]

Hello all:

My setup:
-10x22 heavy ball screw milling table bolted to and taking up one half of my 10x49 Bridgeport to which I'm performing a Z-axis ball screw conversion. The other half is reserved for manual milling.
-3 Glentek DC brush-type servos part #GM3320-22 rated at 7.5 lb-in (120 oz-in) continuous and 37.5 lb-in (600 oz-in) stall at 22amps. 3000rpm max and 22v/1000rpm.
-Drivers from cncdrive rated at 80volts and 20amps per servo.
-Antek power supply rated at 67volts and 22.4amps.

A few points of confusion about encoders:

My X and Y servos currently have 500cpr encoders. My understanding is that the drives work in "quadrature" which I believe effectively multiplies the cpr by a factor of 4. So, 500cpr x4 = 2000 lines per revolution. At 3000rpm max, the line count will be 6 million lines per minute or 100,000 lines per second (0.1mHz). My drives are rated at 1mHz, so I should be okay.
My ball screw lead is 5mm on all 3 axes.

Question: My Z axis servo does not yet have an encoder. I found a new US digital encoder for cheap which I could make work without too much effort. However, this encoder is rated at 200cpr, which by the same logic above would produce 800 lines per revolution. With the 5mm ball screw, each revolution would be about 0.197" or approximately 1 count per thousandth, 4 lines per thousandth in quadrature. I've read that even with servos, occasionally line counts are not always super exact with the encoder/driver interface. So +/- a few line counts will make the better part of a thousandth error which may or may not be significant. I would like to minimize all of my sources of positional error. So my question is whether a 200cpr encoder with a 5mm lead will be sloppy with enough lines to be a significant issue with positioning accuracy/repeatability?

Any experienced wisdom would be gladly appreciated!

[Bubba]

#1 Generally, the encoder is mounted on the servo and not the lead screw so you also need to take into account the reduction of the servo to lead screw. Generally servos do not do direct drive. So if you have a 2:1 reduction you need to multiply your figures by 2 (resolution will increase by a factor of 2)
#2 If I have done my math correctly, using a direct drive and the 200 line encoder would give you 0.000246 steps per inch which is accurate enough for most of us.
#3 While your drives are capable of the step count, What about your controller? Will it output at that high rate??



Just my 2¢

[SCzEngrgGroup]

You've got that exactly backwards. CPR is 4X the line count. So, if your encoder is really 500 CPR, then it is 125 lines, not 2000. My guess is your encoders are really 500 lines or 2000 CPR. There is little point in going any higher in resolution, as the mechanical resolution of your machine will be FAR less than the theoretical resolution dictated by the encoder.

There is a BIG difference between the calculated resolution and accuracy of these machines, and their real accuracy. In the real world, getting a machine to even 0.001" accuracy is *extremely* difficult, and requires accurate feedback from linear encoders on the table. With shaft encoders on the motors, you will never reach that kind of accuracy, due to the many factors (friction, stiction, thermal expansion, lead errors, etc.) that work to reduce accuracy. Errors due to thermal expansion alone will FAR exceed 0.001" on all but the very smallest parts.

Regards,
Ray L.

[Al_The_Man]

An encoder is specified in the basic counts/rev of an encoder, this is the basic (90°) quadrature count, this quadrature count has nothing to do with specifying the final resolution, other than the following, when it is done at the option of the end user, as to whether their design takes advantage of increasing the resolution by x1, x2 or x4 of the basic quadrature count.
This is done by detecting the various edges of the two quadrature wave forms.
Al.

[aubreyj]

Thank you all for your input!

Bubba:
By "controller" I assume you mean the software and not the driver?
I will be using Mach 3 or EMC2 -I haven't made a definite decision yet. My X & Y axes are set up as direct drive, but my Z axis is set up as a 2:1 gear multiplier. So that's a good point you bring up which halves the potential for error. Incidentally, the figure you calculated (2.5 tenths/count or line) is identical to my figure gotten by multiplying the CPR by four (4 counts or lines per thousandth).

HimyKabibble:
I checked the specs on my current encoders (Cleveland Motion Control DataTorque RS23s) and they are spec'd as 500 CPR. The US Digital spec sheet also rates the encoders in CPR.
I guess I'm not really that clear on the difference between a LPR and CPR?

Al_The_Man:
So it looks like what you're saying is that the basic CPR specified in the encoder documentation IS the "quadrature" count?
Is the optional multiplication performed by the software or the driver board?

Thanks again!

[Al_The_Man]

Al_The_Man:
So it looks like what you're saying is that the basic CPR specified in the encoder documentation IS the "quadrature" count?
Is the optional multiplication performed by the software or the driver board?

Thanks again!

Yes, if you specify an encoder in a system when designing or purchasing, the basic or quadrature count is always used.
The device designer opts on the final resolution, there are some that allow the option of choosing x1,x2 x4 by parameter etc.
e.g. a 1000 count/rev encoder could be used at 1k, 2k or 4k resolution.
Al.

[Joe NH]

I don't get it.
When I look up various encoders on the US Digital page, their literature lists one line for example, as 64-2500 CPR / 256-10,000 PPR. Doesn't this mean that the PPR is the quadrature count?
Joe

[Al_The_Man]

The problem is there is a wrong definition out there for the term quadrature.
Quadrature refers to the two basic pulses which are 90° apart (quadrature) which consist of the basic pulses/rev.
So if you see an encoder advertised as 256 counts/rev, this is the basic count, it is then possibly multiplied by the controller or drive by the factor of x1, x2 or x4.
Al.