I see LL sells a beast of a servo with "quad encoder", etc. If one were to DIY some kind of controller for this, how would they go about reading the encoder signal? Is it simply a square wave signal? Say if it had 100 PPR does that mean I would see 100 high pulses for each revolution?

Does the servo require a PWM DC voltage based upon how fast you want the motor to turn?

Can someone fill me in on the inner workings, and concepts of a servo motor with encoder?


MotoMan

A PMDC servo is a gentle brute of a motor with a lot of windings and big magnets for smooth motion. There are numerous ways to control the power and speed of the motor, but PWM is the current favorite for DC motors, since PWM can maintain high torque at low speeds. Rather than using resistance-based speed-control concepts which necessarily lower the available power to the motor; a PWM drive can maintain the V and A while "chopping" out some of the DC "line signal". Imagine precisely controlling the on/off switch on a flashlight at say 1000hz. The "off time between pulses" is the typical variable that is controlled. The less "off time", the brighter the light, even though the switching frequency stays constant at 1000hz.

About the encoding. Any motor's position can be tracked by numerous types of "encoders", which are methods of counting degrees of rotation, or positions in a coordinate space. A rotational "quad" encoder is an optical disk with a series of precise lines positioned in an equidistant axial distribution about the disk, and uses one of a few methods to increase the encoder's signal to quadrature; yielding a 4bit "word" for each possible single bit of axial-rotational information.

A micro-controller (or computer) is used to count the quadrature and compare it to the "expected position", and if the motor is say, slowed by the work, the controller will decrease the "down time" of the PWM output signal, increasing the power/torque to the motor needed to "make up" the loss in expected space position. This is called "closed loop positioning" and is highly desirable for the power and fluidity that this "analog" approach brings over stepped drives.

The servo-"amp" is an H-Bridge amplifier which simply receives the PWM signal from the MC and "switches" a much higher V-A in proportion to the PWM signal; ie an "amplifier".

Does anyone know of any papers that tell you how to "read" the output of this encoder based upon spindle location? I'm trying to see how fast of equipment is needed to accurately read the encoder at "full operating" speed. I would like to use a small computer to run the motor (adjusting code is easier than it would be with a PIC).

I can extrapolate from basic variables:

Motor RPM @ desired IPM (screw-threads; tpi/unit/RPM)
Number of disk segments
Method of encoding w/compression (quad)

For the "papers", can you say what you'd like to do?

I was going to look into DIY-ing something to read the encoder with a computer. Something were I can write a program on the computer to read the encoder signals, and then output the PWM to the motors. I know they have fancy controller boards to do this, but I just like to know the inner workings of it so I have the option of doing something myself. But first I need to know what to expect from the encoder. How the signal is constructed, voltages, frequencies, etc.

Before when I was thinking about using steppers, I had made a way to run multiple steppers off of the parallel port of the computer, and programs to turn models into a form of code I could send out to the printer port, then printer port to motors.

I was seeing if I could do something similar with the LL servos. I'm set on using servos simply for their speed and strength.


(Blame this on the obsession to DIY)

A quadrature encoder provides a clock signal and a direction signal and sometimes an index signal (goes high once per revolution). But the clock and direction signals aren’t directly available, they need to be extracted from the two connections. Its operating frequency will be device specific, brainchild might be able to enlighten you with the specifics of his encoder (max RPM expected, pulses per revolution).
From the electrical point of view. From what I understand there are at least two types. Full TTL output, high and low can source and sink equal current. This is the easiest to interface, simply connect it directly to the logic device. And open collector output. This type sometimes has an internal pull up resistor for the high state. If it hasn’t got the pull-up resistor then you’ll need to add one to your interface. Sometimes it’s a good idea to add one in any case, it’ll help with the rise time.
Now to the logic. There are two connections, A and B. to extract the data, clk and direction, you need to look at the wave form:

Click to view attachment


This is actually called grey code, there is only change in one connection for each pulse.
This is the way I’d envisage its operation in logic:
Reading the encoder
On a change of state, invoke an interrupt.
Read the state of A and B.
Compare A and B to the previous states to determine the direction of travel since then.
Add or subtract from the motor total count.
Check index signal and make any adjustments.
Outputting data
If the motor total count doesn’t equal the system total count, turn motor in the correct direction.


I’m not too confident that you’ll be able to use a PC directly in the loop. The latencies may be too high to get good results. You may need to consider using a microcontroller to keep track off the motor count and then read this data back into the PC.

DJ

Ok, so the encoder works just like the old ball mice (well kinda-sorta). Depending on which signal is high first (A or shows the direction, and each change in High or Low counts as a step (counter + 1). I see where the computer's baud rate could be a problem here. I think your right, a microcontroller looks like the only way.

Well it was still worth asking. Thanks guys for your help with this, very useful!

David

One more question tho.... If the LL servo has 1440PPR, does that mean I can count 1440 steps per rev of the motor?

So one could get a 1 thread per inch ACME, and have nearly 1200 inch per minute movement (Max RPM of 1200RPM) with sub .001 step accuracy?

If this were true, then sounds better to get a 2TPI ACME. Still 600IPM is still a good clip!

You'd be using a ball-screw (no, not that!) with just 1 TPI, but yes, 1200 IPM...stand back! Actually there's 'enough' bandwith on the PP (16mbps) to count and drive servos, I've seen it done, lemme find the link...

http://lukecole.name/parallelport_pwm_driver.php

It's not common though, as latency is a factor. The Pluto P fpga is an easy and fast implementation of a quad counter.

That PP I/O board looks Cool! I might just go the easy way out and get a prefabbed controller with USB or something. Anyone know to find one to run the LL servo?


Now back to the other question. Does 1440PPR mean 1440 counts per revolution? Does this mean (aside from any other source of slop) that the step counts, when using a 1TPI, have a step of .0007 of an inch?

That'd be 00069444444".

Yes, that's it. Most hardware drives damp the error rate to about 125p, meaning 125 pulses in a row before the 'error stop' is generated (drive fault). Increasing the screw tpi increases resolution.

Oh yea...EMC2 can't work over USB for the signal output (but accepts USB input). A large emphasis of EMC2 is real-time control, whereas a ser/des adds latency over USB. Other softwares support it though....

Com'on brain....use your sig-digs!




So wait, does that mean if I were to run the router from one end of the table to the other, I could be off by .008 per inch? how would one go about removing this error. I dont want to have my final hole be off by a 1/4" from the first hole!!! And I dont see running it at 15IPM really worth it either.

could someone use redundant encoders to help with this?

No, just means that's when the drive "faults" (stops the job).