[Alon Harpaz]

@jmelson,

Not sure if looking at the same Encoder (a bit new to this...). From my analysis, Bit 5 corresponds to presence ('0') or absence ('1') of Battery Voltage. Nominal Voltage is 6VDC according to documentation, the Switching Point seems to be at ~4.7VDC.

Regarding the Checksum or other Integrity indicator - do you have anything regarding CRC with such Encoders?

Thanks, Alon Harpaz

[jmelson]

@jmelson,

Not sure if looking at the same Encoder (a bit new to this...). From my analysis, Bit 5 corresponds to presence ('0') or absence ('1') of Battery Voltage. Nominal Voltage is 6VDC according to documentation, the Switching Point seems to be at ~4.7VDC.

Regarding the Checksum or other Integrity indicator - do you have anything regarding CRC with such Encoders?

Thanks, Alon Harpaz

OK, the way I tested it, the battery supply pins were fed from the same supply as the rest
of the encoder. If you don't have a brake on the motor during power down, then the
battery is saving a position that no longer exists, so I didn't see the point.

The cyclic redundancy checksum is 5 bits long, and is one of the standard polynomials used. I'm not going to describe it farther than that as I am planning to make a commercial product
to convert signals from these encoders.

Jon

[tc429]

OK, the way I tested it, the battery supply pins were fed from the same supply as the rest
of the encoder. If you don't have a brake on the motor during power down, then the
battery is saving a position that no longer exists, so I didn't see the point.

The cyclic redundancy checksum is 5 bits long, and is one of the standard polynomials used. I'm not going to describe it farther than that as I am planning to make a commercial product
to convert signals from these encoders.

Jon

Fanuc serials count "live" with battery power...if the screw moves, it's correct at control boot up- maybe the battery just keeps it "live" and stores the count internally in real time, sending it with the next req?

Once you get it reading, try increasing rpm- I was told resolution was 1million at low speed, but low as 2048 at rapid. Disk is only 2048 line, guess they interpolate analog transitions to "get" the million lines...kinda reminds me of the old 15-a advertised as zero following error till the truth came out

I don't recall the bits, but the rotor positions were kinda readable in the middle- I seem to remember the pattern totally flips at reverse direction?
Tim

[jmelson]

Fanuc serials count "live" with battery power...if the screw moves, it's correct at control boot up- maybe the battery just keeps it "live" and stores the count internally in real time, sending it with the next req?


Tim

No, the LED is only powered by the main control power, the battery only retains data in
a memory. That's how the tiny battery can maintain several encoders' position for
months.

Jon

[PCW_MESA]

No, the LED is only powered by the main control power, the battery only retains data in
a memory. That's how the tiny battery can maintain several encoders' position for
months.

Jon

Actually tc429 is right, the aA64 encoder (and probably other Fanuc absolute serial pulse coders)
_do_ keep count on battery power alone! I was quite surprised by this
and assumed they just left the brakes on and ignored a few lost counts at startup
until the encoder got another index.

What I think it does is low duty cycle power cycling of the LED and sensor circuits
when on battery power. The ones I have draw about 20 uA from the battery when idle but the battery
current goes up (in proportion to the shaft speed) if you rotate the shaft (up to many mA)

[ernestop]

Hello,

I've been trying to simulate the Fanuc serial protocol, I have a fanuc servo controller with REQ and DAT signals for Absolute Fanuc encoders. I am doing so because I'm trying to controll different servomotors (ABB Servomotors) I don't have any fanuc encoders or servomotors at this moment.

-> I get a REQ signal at a frequency of 8 kHz
-> I am feeding data using a SN75176 differential driver.
-> Signal is generated from an mbed microcontroller at 1.024Mhz, which is 977ns per bit
-> The Controller gives me the following error: SRVO-068 SERVO DTERR for each of the six axis,
-> After a Feed the signal i get two extra errors:

SRVO–068 SERVO DTERR alarm (Grp:%d Ax:%d)
Cause1: The axis control PCB sent the request signal, but did not receive serial data from the pulse coder.

SRVO–069 SERVO CRCERR alarm (Grp:%d Ax:%d)
Cause: The serial data from the pulse coder changed during communication to the axis control PCB.

SRVO–070 SERVO STBERR alarm (Grp:%d Ax:%d)
Cause: The communication stop and start bits are abnormal.

-> I am using Ulis serial capture: it has 79 bits, altough the stream is supposed to have only 77, maybe start and stop bits, also last bits are constant?

This a snipped from the telegrams from a slowly turned Pulsecoder:
UHU Pulse(de)coder 0.9 (c) Snr: 1
01110010010110011100101000000000001000000000000000 00100000011111000001011101111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010010011100101000000000001000000000000000 00100000011111000001100001111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111

From this I am assuming |0| start bit and |101| as encoder ID: 5,

Atached is a photo of the output of the microcontroller to the SN75176.



Any help with this will be greatly appreciated.

Attachment 204194

[PCW_MESA]

My first guess (assuming everything else is correct) is that you have
the DAT polarity reversed, this would account for the abnormal start bit complaint.

Heres what I know about at least one encoder type (start bit ignored so 76 bits of data)
Note that the data is sent LSb first but the CRC must be calculated MSb first.

Fanuc data format (76 bits): So far just for Aa64 (860-360-xxx)
bits 0..4 constant : encoder type?
bit 5 1=battery fail
bits 6,7 unknown
bit 8 1=un-indexed
bits 9..17 unknown, perhaps for higher res encoders
bits 18..33 16 bit absolute encoder data (0..65535 for one turn)
bits 34..35 unknown
bits 36..51 16 bit absolute turns count
bits 52,53 unknown
bits 54..63 10 bit absolute commutation encoder (four 0.1023 cycles per turn)
bits 64..70 unknown
bits 71..75 ITU CRC-5 (calculated MSB first)

[PCW_MESA]

My first guess (assuming everything else is correct) is that you have
the DAT polarity reversed, this would account for the abnormal start bit complaint.

Heres what I know about at least one encoder type (start bit ignored so 76 bits of data)
Note that the data is sent LSb first but the CRC must be calculated MSb first.

Fanuc data format (76 bits): So far just for Aa64 (860-360-xxx)
bits 0..4 constant : encoder type?
bit 5 1=battery fail
bits 6,7 unknown
bit 8 1=un-indexed
bits 9..17 unknown, perhaps for higher res encoders
bits 18..33 16 bit absolute encoder data (0..65535 for one turn)
bits 34..35 unknown
bits 36..51 16 bit absolute turns count
bits 52,53 unknown
bits 54..63 10 bit absolute commutation encoder (four 0.1023 cycles per turn)
bits 64..70 unknown
bits 71..75 ITU CRC-5 (calculated MSB first)

A little addendum:

I was loaned a Aa1000 encoder (860 - 370 - Txxx) and its format is identical to the Aa64 encoder
with the exception of the encoder type and an additional 6 bit field of lower order encoder bits
(bits 10..15). Bits 10 and 11 are noisy/not monotonic but bits 12..15 are 4 more useable
low order bits giving 1048576 counts per turn.

[Xerxes]

Interesting topic! Has anyone got that CRC working? I played around it and could not get a matching CRC from telegrams posted by ulihuber.

I generated CRC calculation code with https://ghsi.de/CRC/index.php?Polyno...ssage=E100CDFE by using ITU CRC-5 polynomial. I tried tried removing bits from beginning and/or end of input data and modified the code to walk through input bits backwards without any luck of getting matching CRC.

It's easy to experiment with this code online at:
Compile and Execute C online

Any suggestions?

This code walks through input bits backwards:

// ==========================================================================
// CRC Generation Unit - Linear Feedback Shift Register implementation
// (c) Kay Gorontzi, GHSi.de, distributed under the terms of LGPL
// ==========================================================================
char *MakeCRC(char *BitString)
   {
   static char Res[6];                                 // CRC Result
   char CRC[5];
   int  i;
   char DoInvert;
   
   for (i=0; i<5; ++i)  CRC[i] = 0;                    // Init before calculation
   

//   for (i=0; i<strlen(BitString); ++i)//walk forwards
   for (i=strlen(BitString)-1; i>=0; i--)//walk backwards
      {
      DoInvert = ('1'==BitString[i]) ^ CRC[4];         // XOR required?

      CRC[4] = CRC[3] ^ DoInvert;
      CRC[3] = CRC[2];
      CRC[2] = CRC[1] ^ DoInvert;
      CRC[1] = CRC[0];
      CRC[0] = DoInvert;
      }
      
   for (i=0; i<5; ++i)  Res[4-i] = CRC[i] ? '1' : '0'; // Convert binary to ASCII
   Res[5] = 0;                                         // Set string terminator

   return(Res);
   }
// A simple test driver:

#include <stdio.h>

int main()
   {
   char *Data, *Result;                                       // Declare two strings
   //raw telegram: 0101001001001001110010100000000000100000000000000000100000011111000001100001111
   Data = "0101001001001001110010100000000000100000000000000000100000011111000001";
   
   //should get 10000?
   Result = MakeCRC(Data);                                    // Calculate CRC
   
   printf("CRC of [%s] is\n [%s]\n", Data, Result);
   
   return(0);
   }

[PCW_MESA]

The CRC is ITU5 calculated MSb first of 76 bits (75 to 0)
(note that the data is sent LSb first)


freeby.mesanet.com/fabsread.pas
has a hacky but working crc check implementation

[Xerxes]

The CRC is ITU5 calculated MSb first of 76 bits (75 to 0)
(note that the data is sent LSb first)


freeby.mesanet.com/fabsread.pas
has a hacky but working crc check implementation

Thanks, working example is the best aid I can wish! I'm waiting one Fanuc motor to arrive so I can begin testing. I'm planning to write Fanuc encoder support to Argon servo drive. The solution will be open source C++ code.

Any more details of the environment where this .pas code works could be very helpful too

[PCW_MESA]

The Pascal code was just a hack to check our FPGA implementation of the Fanuc encoder interface (for the linuxcnc hm2 driver)
freeby.mesanet.com/regmap has the FPGA register map for all modules including the fanuc (Fabs) module
the register map might make the code a bit less mysterious. The FPGA source is here: freeby.mesanet.com/fanucabs.vhd

Note that the first bit is a start bit and not included in the CRC calculation (and discarded by our firmware)

I have a type 2 Fanuc absolute encoder (16M counts/turn!) I need to decipher,
it uses a half duplex link so only a single data pair.
I think its a higher baud rate but thats all I know so far...

[Xerxes]

Thanks a lot! Useful stuff.