Fanuc encoders

I've recently bought a Harrison Alpha 330 with a broken computer. I am
going to convert this lathe to linuxcnc using my own motor drives.
 
Since this lathe was using a Fanuc controller and I could not find
sufficient information about the Fanuc encoder protocol, I decided to
try to reverse engineer the protocol. And it seems I have succeeded and
would like to share what I have learnt about the protocol, in case anyone
else wants to re-use their Fanuc encoders.
 
The motors present are beta1/3000 or A06B-0031-B077 (X-axis) and
beta2/3000 or A06B-0032-B077 (Z-axis)
 
First of all the code can be found in
github.com/mark-v-d/motor_control/tree/fanuc
 
Both the file software/xmc4400/src/encoder.cpp and
software/xmc4400/src/crc_lut.h should contain all
the information necessary.
 
/* Fanuc***********************************************************/
   Datarate is 1024kb/s. Send a positive pulse on REQ (pin-5) of 7..9us
   to get a response.  The response is 4 frames of 1 start bit, 16 data
   bits and 1 stop bit.  After the 4th frame the CRC is transmitted,
   without a preceding startbit.  The way to capture it, is to change
   the word length of the 4th frame to 16+1+5 bits.
 
    1st status
        0xe000  3-msb changes, reason unknown
        0x0100  index seen
        0x0005  always there so-far.
    2nd 16-bit counter within revolution
    3rd revolution counter
    4th absolute
        0x8000  Always set?
        0x03fc  Commutation angle? After index the same as 2nd>>4
    5th 5-bit CRC
 

andypugh wrote:

Is this the serial protocol, or the 4-bit gray code?

I think that _some_ Fanuc serial protocols are supported by Hostmot2:
linuxcnc.org/docs/stable/html/man/man9/h...html#Fanuc%20encoder
 

Mark's message gives the details of the serial protocol.  I don't know why he had to duplicate the effort, I have already deciphered these encoders and have a protocol converter product.  But, now, Fanuc has a "High speed" encoder line that is incompatible with the older ones.
Jon

It could very well be the same, but I'm not sure. This is for the beta and not the alpha series of Fanuc. Like I said, I could not find the details of the protocol anywhere, but that could also mean I did not look in the right place.

I've verified the vhdl and c code, and hostmot2 is indeed dealing with
the same protocol.

But at least now you know how to interpret the CRC, because that is not
done in hostmot2.

And I have learned where the batt_fail bit is (not that there is one on
the incremental encoder) They also don't seem to know what the purpose of
those 3 changing bits is. Maybe I'll figure that one out eventually.

mark-v-d wrote:

It could very well be the same, but I'm not sure. This is for the beta and not the alpha series of Fanuc. Like I said, I could not find the details of the protocol anywhere, but that could also mean I did not look in the right place.
 

I never found any document on the data format, but I managed to insert a pulse and get the encoder to send data.  Then, I looked at it on a scope, and created an FPGA to read the data and send it to a computer via the parallel port.  I then spun the encoder by hand and wrote programs to extract the data.  The hardest thing to crack was the CRC.  I took some of the extracted data, and ran it through a program that tried many different CRC polynomials until I got a zero result from every data pattern.  Then, I coded that up in VHDL and put it into my converter product.
Your description looks JUST like what I deciphered.

One note,  There are absolute and incremental versions of these encoders, at least on the older Alpha series.  The absolute ones have extra data at the end that provides a 10-bit resolution absolute position immediately at power-on.  The incremental encoders power-up assuming rotary position zero, and then the position count jumps when they pass the index position.  So, you can't get any reliable commutation out of them without battery backup.
Jon

I have the incremental encoders in my lathe, they are the beta versions
however. On these encoders the 10-bit absolute position is there and
accurate enough to use for commutation right from the start. There is
a step in this data however once the encoder passes the index.

The control computer had a backup battery, the battery connection of
the encoders was not used. So I assume the computer was responsible
for remembering the position. There are no homing sensors on the lathe,
so I guess they ran the lathe to its endstops when the battery failed.

For me the hard part was to get the encoder to respond. It wants a
positive pulse on the REQ line, and initially I was trying a negative
pulse. After that, verifying the encoder position was simple enough with
a scope indeed.

The nice part about the CRC is that there are only 32 possible
polynomials, so bruteforcing works like a charm

I hope my information helps someone, but if not... nothing is lost.
I doubt reading the VHDL and C code of hostmot2 would have been faster
than what I did, but I certainly would have tried it, if had known about
it. On the other hand, the microcontroller I use can only capture frames
up to 64 bits, so knowing the padding are actually start and stop bits
was crucial.

On all the encoders, after power-on, there is a step in the high-res data when the encoder passes the index position. But, there is NO step in the low-res absolute data. My converter board FPGA makes the high-res step disappear as it converts to quadrature. I know WHY Fanuc went with the serial scheme, the quadrature count rates become insane when you start thinking about 1 million counts/rev, and so converting those to quadrature is not practical at full resolution.
Jon