[jmelson]

just re-reading, are you running encoder from just a supply? how are you sending the 'send data' to the encoder? I think its more than just a continuous call, varies with a lot of things.

I reprogrammed the FPGA of one of my controller boards to send the request and read back the serial response. Right now, I am sending an 8 us-wide pulse on req, and then reading 80 bits of data. (There are some extra bits on the end that don't do anything, but that makes it an even 10 bytes.)

So, I have a program that sends the command on the REQ lines, then waits for a serial response and prints it out on the screen.

I found out the actual bit rate is 1.024MBits/second, not 1.000 even. I was able to adjust my FPGA code to accommodate this. I still am not completely sure I am reading the data right, there seem to be some gaps in the fields, but maybe that is how it is designed.

I saw that there were C1 C2 C4 C8 signals among the test points on the encoder board, but the report given by the 8 us REQ pulse doesn't seem to give those. I am assuming there may be other commands that give different reports. Also, when I power it up, I may sometimes be getting a different report format, so there may be a mode select command that needs to be sent, and I'm getting a random selection at power on.

So, what I am planning on doing is changing that fixed 8 us pulse to an 8-bit command word that can be sent to from the computer to the encoder, and trying all possible combination and recording what the encoder does.

I kinda assumed it had to run from a fanuc controller...I had put a 0-C rack in my office 'test control' when I was playing around...maybe rotor position only sent/recieved when proper data in/out is there?

Well, I am simulating at least part of what the Fanuc control does, but probably not all of the functions.

if you could, please share the timing/data youve got so far- I dont think we even have a scope here anymore, maybe some night I can drag my old test control out and try to take a peek at it again...you mentioned a logic analyzer- whats needed(make/model?) might start watching ebay for one...they had quite a lab here, odds are they might even have one put away here- theyd bought a lot of crap they never used at this plant. We never had anything at our old shop, but made money...hmm...anyway...

I snagged a $130,000 Tektronix logic analyzer on eBay some years ago, it is the size of a microwave oven, and draws about that much power. But, there are little USB pod analyzers that could handle this job, there are only two signals of interest, REQ (from control to encoder) and SD (from encoder to control). There are also USB pod digital storage scopes that could also do it, and might be a more useful device to have around. I have an ancient Link unit that works off the parallel port.

Jon

[jmelson]

Here's a little data I have derived from working with this serial encoder so far :
Fanuc serial encoder format (aA64 encoder)
bit # 0 is first data bit after start bit. Data bits are 976.6 ns long (1.024 mbits/sec)

This is result of true req signal of 8 us duration. Assuming similar serial code, that would be a
start pulse follwed by 7 ones.

Bit # Function
0 1 encoder ID
1 0 encoder ID
2 1 encoder ID
3-7 ? 0 encoder ID ?
8 1 = encoder not indexed
. 0 = index located
9-17 0 possibly lowest order bits of higher res encoder
18-31 angular count for 1/4 turn (14 bits)
32-33 0
34-35 angular quadrant count
36 0
37-51 signed count of rotations (15 bits)
52 1
53 0
54-63 low-res position count (10 bits)
64-68 0
69-70 11 (two one's)
71-75 checksum

[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

[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.