Fanuc ABS encoder data transmission not complete

Do you know if the return data starts relative to the leading or
trailing edge of the request pulse? ( its been years since
I figured out the protocol and wrote the firmware )

I won't have access to the scope and encoder until monday, but according to some old pictures, the tx begins ~5us after the trailing edge of the request pulse.

Also the pictures are of the scoped tx from a different aA64 encoder and it drives the line correctly, no weird disabled state, I'm thinking the robot encoders might just be weird or custom since they are designed to be used with a custom amplifier.

Monday I can do some tests to see if the tx start is in relation to the rising or falling edge of the request pulse.(I'm almost certain its the falling edge since a request pulse that is too long won't trigger the data transmit)

Did you know that these encoders can be programmed to continuously output data?
They in fact do not output continuously, they can be switched to 2 wire rs485 mode which I thought was just the encoder outputting but it actually stll had a request signal from the controller.

I did not know that they could continuously report data

The driver disabling makes me wonder if your encoders are really
RS-485 2 wire types running with 4 wires for some reason.

I have some RS-485 types I shoud try to get working
(2 m count/turn and 2.048 MHz data rate instead of 1.024 MHz)

ExcessiveO wrote:

I won't have access to the scope and encoder until monday, but according to some old pictures, the tx begins ~5us after the trailing edge of the request pulse.

Also the pictures are of the scoped tx from a different aA64 encoder and it drives the line correctly, no weird disabled state, I'm thinking the robot encoders might just be weird or custom since they are designed to be used with a custom amplifier.

Monday I can do some tests to see if the tx start is in relation to the rising or falling edge of the request pulse.(I'm almost certain its the falling edge since a request pulse that is too long won't trigger the data transmit)

Side note, do you know if all A64 encoders can be configured to continuously output data? The robot's servo amplifier sent config streams to all the encoders that caused them to output at set intervals without a request pulse. I have no idea what all can be configured but it seemed potentially useful.

did you figure this out?  I am currently putting a fanuc 21T control quick reference manual and with every sentence i write on it I hate it even more.  would love to retrofit it but have been told that the fanuc servos and drives would not work with linuxcnc due to a proprietary communication type?  is this resolved now?  and if so is it fanuc model specific?

Thanks!

Chris

I have yet to fix the error but it only gets displayed once and doesn't effect the encoders actually working. Depending on the encoders(currently only A64 are supported) and how the drives are interfaced it may be possible. If its a fanuc protocol from the computer to the drives then you'll have to get new drives, if its just an analog input the linuxCNC will have no issue as long as it can still get the encoder feedback.

I am controlling a robot with linuxCNC and needed to completely replace the servo drive. I ended up using cheap odrives to run the servos, however they can only run the motors at ~15% of their rated speed. Its end purpose is to be a CNC router so that speed is hopefully acceptable. Ill make a more detailed post on everything once its complete. In general Fanuc stuff is pain to get working with anything but fanuc specific parts.

So I have ran into more issues. I got the A64 encoders I have working with the standard configuration(request pulse then data out on separate pairs). Unfortunately the robot only has connections to the request pair. This ended up adding quite the challenge. I am thinking the encoders are designed to be backwards compatible and therefor still work with the regular request pulse. I looked at the captures between the original fanuc controller and the encoders and now realize it only uses a single pair to communicate both directions(so rs485) and it uses 2Mhz instead of 1Mhz. I believe the controller still needs to send a request signal but it is instead ~8 bits rather than a single pulse.

I'm thinking the easiest fix would be to connect the rx and tx lines of the encoder together then modify the existing fanuc configuration to handle the drive enable pin. Other than that, I'd either have to find a way to output a custom request byte and change the data reading format, or run a bunch more wires through the robot, neither of which I am too excited to do...

I attached the logic analyzer output which shows the encoder data pins on the top and the encoder request pin on the bottom. This is the very beginning when everything is turned on.

The scope picture is of the request lines after everything is running, notice the signal goes back to floating after the first few bits, this leads me to think the first few were from the controller and the rest are the encoder data.

Any suggestions on what would be the best way to go?

I think I have a similar FANUC encoder (though its 2 million count/turn) but 2.048 mbits/sec and RS-485. I bought it years ago to add support but never did. It should not be terribly difficult to add support. It looks like the request data is perhaps a single byte with a start bit
and stop bit.

The needed firmware things would be:
Request char send /RS-485 drive ENA logic
RX data masking during request

Driver changes would be to enable the RS-485 mode
and set the request char

After a few days of messing around with the .vhd file, I have successfully made zero progress

Is there any resources or documentation on the fpga firmware? I pretty much only have experience in c++ so the vhd files are quite a leap. I've looked at the reference for it but haven't been able to make much sense of the firmware files.

I was able to get the fpga to MOSTLY copy what the original controller did, however, I am still not getting any response from the encoder. I am thinking I am not handling the transition from 4 wire to 2 wire mode correctly, specifically the drive enable. Unfortunately, I dont have a scoped view of the transition, and the logic analyzer view is digital, so it won't show where the signal goes floating. Any Ideas what to look into next?

Also Is there a signal in the fanucabs.vhd file that I could use to run something each time linuxcnc is started? It currently only initializes the encoders the first time after the fpga is reloaded which is a bit inconvenient.