Familiar with FANUC servo drives? Reverse engineering serial encoder.

[Yansi]

Hello,

I have a FANUC servo motor type "A06B-0117-B855#0049", that I would like to interface to a custom servodrive. However, this is the newfangled stuff, with an encoder with a serial communication line.  There are only six pins on the encoder available: A power supply 5V pair, backup battery supply pair and a communication pair of pins called "XPRQJ6 and PRQJ6".

I have stumbled upon this thread on CNCforum: https://www.cnczone.com/forums/fanuc/127192-need-serial-pulse-coder-info.html

After reading through that thread, I attempted to send a 0xFF byte to the encoder at 1Mbaud (or 1.024Mbaud), but got no response from the encoder.

Also after trying to bombard the encoder with some random bytes, it seems to respond weirdly at times with a sequence of about 45 zeros. But weirdly enough, it even starts transmitting before my byte gets fully output on the bus. If you look below on the scope capture (looking directly at an A line), it seems to start transmitting even before my byte ends. (I have sent 0x09, it starts transmitting over me at the bit 4 position).

I am not sure what the exact part number of the encoder is, but it seems it should be "A20B-8200-045" part number, according to some googling around.

What I am not  even sure, is what the polarity of the differential pair is. Which of the XPRQJ/PRQJ pins should be the A and B of the RS485 bus?  Of course, I have tried sending the 0xFF both polarities, but still nothing.  I could probably look into the electronics more in detail to figure out which of the two may be the A and B. Will report later on that.

But does any of you have any experience with these? Any hints about the protocol? Any suggestion what to test?

Thanks,
Y.

[capt bullshot]

The HW interface could be of the Tamagawa type - this is a common encoder protocol for Japanese and Chinese motors, it is copied by several other manufacturers of encoders. Alas, I don't have a protocol description readily available.

Edit: Sanyo Denki also is a common protocol matching your HW interface. Maybe it's even the same as Tamagawa. One can find some documents (e.g. google for "S5094873B") describing the protocol. It says 18 bits per frame asynchronous  Not just a simple case for an UART. Data from encoder consists of 3 or 4 fields of 18 bits.

[Yansi]

No problem, I can fight the protocol with an FPGA. But first I need to know what I am fighting against 

However thanks for a very good tip of what it may be.  Also, if I measure the long pulse of zeros I get from it sometimes, it seems it is log about 51.7us, which noticeably corresponds to 128 bits at 2.5Mbits per second.

Unfortunately I can locate the document only on an untrustworthy paywalled service. 

[capt bullshot]

Looks like it's behind a paywall. You might find this document interesting.

[capt bullshot]

And maybe this.
And this.

[Yansi]

Already downloaded even the S5094873B document you have referenced. 

That seems a lot of reading! Many thanks! I will try to get through and verify if I can get the encoder to respond with anything sensible.

[Yansi]

So a bit of progress here, but no response yet. 

I have cobbled together an 18bit 2.5Mbaus 485 transceiver. Result can be seen in the attachment below. I've tried to send the sequence described in the S5094873B document, page 14 top:



The resulting waveform on the bus is here. Polarity of the A-B lines were connected as such I get logic 1 on IDLE. That means PRQJ6 = A line, XPRQJ6 = B line.  DE line (transmit enable) is driven 1.2us before the start bit, as per the S5094873B  document, timing chart on page 17.




What may still be wrong, that it does nothing?

[Yansi]

I've just noticed ... isn't it supposed to be NRZ encoded?  How the hell?

Looked through the verilog code you have shared, seems no NRZ coding there. Same stuff transmitted as I do as far as I can tell.

//EDIT: Seems they mean that the RS485 itself is NRZ or what.

I also am guessing the encoder address i 0. It may be different, so may be the baudrate, which seems it can be either 2.5 or 4Mbps.

Too much variables to control at one time. :-/

[Yansi]

After looking through a catalogue published on a Tamagawa website, I have found this section on page 57:
https://www.tamagawa-seiki.com/assets/img/downloads/pdf/rotaryencoder/1228N59EJ.pdf



So I have tried sending  "0010100001" at 2.5Mbd, but still got nothing out.  Below is the transmission:



Any suggestions what else to try?

[capt bullshot]

Sorry, no more ideas now.
I've tried to find some information on what type of encoders Fanuc uses, but no success.
I don't think they're using Hiperface (that's a RS485 based protocol by Sick Stegmann, you won't find this in Japan). Most other protocols use a Clock and a Data pair.

From some more googling I found this
http://openservodrive.com/fanuc-serial-pulse-coder-support-argon-servo-drive/
and some other hints - Fanuc have most probably their own protocol and are not using one of the ones I mentioned.

[Yansi]

I think hiperface does not even fit due to being just 2 wires, serving both as power supply and data.

That link on the openservodrive.com I also found - there's a link in the text I have linked in my first post too. Unfortunately, that does not work either - or I did not do well enough.

I kind of doubt Fanuc would (or even could) go down the rabbithole of making their own custom LSI silicon, optical sensors and such.

Even though the PCB in the encoder is silkscreened FANUC and contains at least couple of chips marked as FANUC, we all know it is way too easy nowdays to obtain custom labeled parts, especially ICs.

Also, from looking in the Tamagawa catalogue I linked in my previous post, some of the encoder PCBs have very familiar layouts with the rows of test-points  round the perimeter of the PCB.

[capt bullshot]

As I found some more encoder manufacturers mentioning the "Fanuc protocol", to me it's plausible they've got their own protocol.
Anyway, in this business manufacturers do a lot to lock others out  , so Fanuc having their own ASICs is also plausible to me.

[Yansi]

It would greatly help if someone would have the access to an original servopack, or even a working LR mate 200 iC Fanuc robot, to sniff it out of it.

However, that chances are I guess pretty slim.   

[jmelson]

I make a converter for some Fanuc encoder models.  The ones I support send data at 1.024 mbit/second, and the data block is 77 bits long, with a CRC at the end.  it has a start bit, a couple bits of encoder status (like low battery, battery failed, encoder overtemperature) and then a binary count of encoder angle, then a binary count of number of full turns, then if it is an ABS encoder, it gives a 10-bit count of angular position that repeats in 4 quadrants.
The NOn-ABS encoders just give a position count that starts at zero from where they were at power-on, and then this count abruptly jumps to zero when the index position ir reached.  (A status but flips at that time.)  So, these encoders MUST have battery backup as there is no way to provide motor commutation without proper alignment after the battery power is lost.

The ABS encoders can give commutation info immediately on power-on, so we can run these without the battery.

The older units in this series take a REQ differential signal on one pair, and reply with the serial string on the SD differential pair.
Some of the newer units use the bi-directional differential schem on one pair, but will also respond to the REQ on the other pair.

There is a new series of these encoders which I'm told send data at 2.73 MBits/second, and use just one differential pair for the command
and resopnse.  Sounds like you might have this type.

Fanuc definitely has their own proprietary format, but a few encoder makers make linear encoders that follow the Fanuc protocol.
I do think they have a start bit/stop bit scheme, but they seem to have 16-bit charaters between start and stop bits.  I just used the
first start bit and then assumed the two crystals were close enough that I could stay in sync.

Jon

[jmelson]

Any suggestions what else to try?

Forget the Tamagawa document, that is for yet another proprietary encoder.
On the earlier serial pulsecoders, it took an 8 us true pulse on the request pair to trigger a readout.  So, you might try an ~ 4 us differential true pulse and then select the driver off so you can sense the response.  Vary the width of the pulse a bit until you get a long transmission from the encoder.  Your 51.7 us
sounds about right if the encoder clock is turned up from the ones I have worked with.  Once you have it sending after every request, you can count off the data bits and accurately measure the bit clock.  By turning the encoder shaft, you can watch the bit fields count up/down and figure out what fields hold what data.

To really crack it, what I did was make up an FPGA board connected to a computer and log a bunch of data to a file.  Then I could pick through it and determine the fields.


Jon

[Yansi]

Thanks for your insight. 

My encoder has only 6 pins:  Supply voltage pair,  battery backup pair and a data pair. Neither there is any clock pair, nor there is a dedicated REQ pair as I have seen with other encoders.  The motor came from a LR mate 200 iC robot, which is not that old (I think 2007?)

I have an FPGA hooked already, as I have tried bashing the encoder with the A-format and T-format commands.  The A-format uses 16bit UART frames (start bit + 16 data bits + stop bit). Have tried both at 2.5 and 4 Mbaud to no avail. (these should be the standard com rates for these two standards).

2.73 Mbaud sounds quite strange of a frequency. But it seems it is a 1/9 of a 24.576 MHz (a standard crystal osc). If that is the case, I should be able to look at the encoder electronics and look for a clock that has to be a multiple of this baudrate. Will check. (...you sure about the baudrate?)


Already made a measurement, the only crystal osc at the encoder board is running at 16.3615 MHz (as measured by my spectrum analyzer with an antenna near the crystal not to disrupt the oscillation).   That 16.3615 is almost exact  6 times the 2.73 MBaud.  We seem to be getting somewhere!

//EDIT: Seems that 16.3676 MHz is a standard manufactured crystal frequency, although not that frequently used (no pun intended).  That is even closer to the target. So the exact baudrate hence may be 2.72793 MBaud. 
But what to send it to get anything out of it?

//EDIT2: Or could it be 16.384 MHz crystal? That way the baudrate would still be still almost spot on 1/6th of the crystal frequency.

[texaspyro]

FANUC -> Fricking Americans No Understand Contraol   

[Yansi]

Well, I would like to stay on topic, but to add little more oil to the fire: Fanuc is even known in our country for numerous illegal advertising banners placed around highways. Even reading people's comments on their facebook page is quite the fun 

[jmelson]

2.73 Mbaud sounds quite strange of a frequency. But it seems it is a 1/9 of a 24.576 MHz (a standard crystal osc). If that is the case, I should be able to look at the encoder electronics and look for a clock that has to be a multiple of this baudrate. Will check. (...you sure about the baudrate?)

I have never had one of these encoders in hand, the frequency was reported to me by a guy in China.  He did get a scope trace, but I'm sure his
measurement on site was better than what I could get from a photo.  He scoped the signals while connected to a Fanuc control.  Unfortumately, he
did not give a picture of the request pulse.  On the older encoders, it was just a 7-bit plus start bit pulse, so 8 us.

//EDIT2: Or could it be 16.384 MHz crystal? That way the baudrate would still be still almost spot on 1/6th of the crystal frequency.

That would be in line with the previous version, which was 1.024 mbit/second, so sounds like a power of two crystal frequency.

I'd love to get one of these encoders for devlopment, but the prices on eBay now are totally INSANE!  I got a selection of Fanuc motors years ago for ~ $75 each.

Jon

[Yansi]

I have googled around a bit and could not find any single mention of the baudrate (2.73M). Good you have contacts in China. But we need more!  As all I can find round the web are the old encoders with either separate REQ pair, or CLK+DATA pairs, which seem to be easy and well (or at least tad better) known how they work.

So the older encoders still had crystal running at 6times the baudrate? Or what exactly have you meant by the "being on par"?

Any possibility to obtain more info from your contact? Would be awesome if someone could go around and sniff the bus from a running robot.  I know a lot of places round here where they run FANUCs, but getting there to measure anything on it is I'd say pretty much impossible. Even though the measurement can be pretty non-invasive and chances of any harm almost none.

If on the older encoders the "request pulse" was an 8bit long one, I can try transmitting 2.93us long pulse (8/2.73).

[Yansi]

So a 7, 8 or 9 baudots long negative pulse  (at 2.73MBaud) does nothing.

Just a note: The expected idle state of the bus should be logic 1 I guess (as that seems to be the case, PRQJ pin of the encoder is positive, XPRQJ is negative; biasing network already builtin to the encoder. Also, 120 ohm termination is present in the encoder). 

[smooker]

Try CC4 on Tamagawa to be a parity.

I have the reverse situation - Panasonic Minas LIQI drives and servo motors with pure incremental encoders.

https://www.amo-gmbh.com/wp-content/uploads/2020/05/Evaluation_result__AMO_scales_130809_AMO.pdf

https://www.heidenhain.de/fileadmin/pdb/media/img/1078628-22_Interfaces_en.pdf

According to the last (page 7) there are 3 fanuc protocols.

[Yansi]

Ping!  Anyone got anything new, any progress with this stuff? I still could not get a visit anywhere, due to the damn covid thing.

Reverse engineering it by having just the encoder (bus slave, which sends nothing) seems impossible. 

[MotorControlNut]

(Apologies for raising this ancient thread from the grave)

Thanks for all the information in this thread! I just got a Fanuc encoder to respond, based on your information, plus some experiments.

For my encoder, I need to:
- Send pulses of around 3.3 us (seems to correspond to 9 bit-times at 2.7-ish Mbit)
- Keep repeating these pulses at 8 kHz
- ... for up to 27 seconds (!) before the encoder starts to respond. I have no idea why this is. Guess luck was on my side to figure this out.

The encoder then responds with a block of data, which has a bit-time of ~362 ns, indicating a baudrate of 2.76 Mbit.
The response is about 104 bits long. I have not decoded any of it, but the data changes as the motor is turned by hand.

Can anybody give any hints on what the format of the response could be?

(edit: added screenshot)

[cnc_freak]

Hope those helps.

https://youtu.be/81FcFzC9GNc
https://github.com/rene-dev/stmbl