Fanuc brushless motors with serial encoders

I've been working on this for a long time, but I finally hooked a Fanuc motor to
my servo amps, my encoder converter and LinuxCNC. The later Fanuc motors
have serial encoders, which report absolute position when interrogated.
So, I built a board to convert that to quadrature, but it still needed commutation
(Hall) signals for the servo drive. I finally got the preliminary code for the
commutation working today, and ran a motor for the first time. There was some
concern that with the encoder being periodically interrogated, the motion
might be jumpy or the PID hard to tune. Well, the encoder is interrogated every
100 us, and it doesn't seem to be any problem, with a 1 ms servo loop.

I do get a bump every time the commutation steps to the next winding, this
is expected with a six-step drive. But, the bump is pretty small.

Just thought I'd give an update on this project.

Jon

This post by akshaykumarvyas disappeared for some reason, I am reposting it
so I can answer it. (If a moderator moved it to a better place, sorry.)

---

i just dont understand one thing . if linux is open source and if it has built in PID then why people are spending money in buying servo/stepper controllers. they can use EMC2 as their controller. this will make it very cheap with the requirement being only the ampilifer for the motors. but still people buy controllers . WHY????

Well, the problem is speed. If you want to produce PWM via sortware, the base-thread
speed limits the frequency and time resolution. For instance, with my hardware PWM
generator, the clock is 40 MHz, and the frequency for my servo amps is 50 KHz.
So, the PWM period is 20 us, and I can set pulse width in 25 ns increments. At
50 KHz, I get 800 steps of pulse width, or a granularity of 0.125%.

Now, making some assumptions, let's say the base-thread is dispatched at a
25 us period. And, assume you want a 20 KHz PWM frequency, or 50 us
period. Well, your available PWM duty cycles are 0, 50% and 100%, and
that's all you can do. Clearly not enough resolution for velocity control.

So, that's why hardware servo control is pretty much required.

The other area of concern is encoder count rate. Again, assuming the
base-thread is 25 us, then you can count one encoder count every 25 us,
or 40,000 counts/second. This is RIGHT at the edge of disaster, as if the
motor ever exceeds this speed, even by a few counts/second, it will probably
cause a servo runaway. So, how fast is 40,000 counts/second?
Well, assume a 1000 cycle/rev encoder, which gives 4000 counts/revolution
in quadrature. That limits you to 10 revs/second, or 600 RPM. Now, a lower
resolution encoder allows higher speeds, but it still is a limit.

The hardware counters on my newest PWM board has a settable digital filter
that can accept several million counts/second on the highest speed.

Jon
Jon

JON,
i think u should take a look at these videos ,





these vidoes show servos driven by EMC2.

andypugh wrote:

Have you tried using the "bldc" component to commutate in HAL? I am not saying it would work better, it would almost certainly work worse, but it would work differently.

No. My drives need commutation signals from the motor to select the
correct winding/polarity, and there is no simple way to send 3 PWM
signals to it. I COULD make a version that does this, but then I'd
need 3 PWM channels per motor. Even if I did a redesign of my PWM
controller, I could only get 8 channels out of one board, which would be
good for only 2 axes.

I bought some Copley amps a while ago and may use bldc to drive those
with two analog current command outputs for a redo ob my
Bridgeport.

Jon

andypugh wrote:

I was meaning use the bldc component to convert the encoder position to three bit-value hall sensor signals, then pass these back to the drives.

Well, the Fanuc serial encoders have a number of quirks. The high resolution
output is not absolute unless you provide battery backup to the encoder,
and promise not to move the shaft while on battery power. The absolute
version of the encoder has a separate position readout that is absolute,
and that is what I'm using for initial commutation info. But, that is a low-res
track, only good enough for commutation purposes. But, anyway,
if you convert this to quadrature, then there is no alignment to the motor
poles until you have passed the index mark. So, that's why I don't
think bldc would work well with these encoders. Also, it would tie up a lot
of I/O pins.

Jon