Six-axis industrial robot arm running as a CNC machine

Oct 26, 2026 Last reply: 1 day ago 4 Replies
Jump to replies (4)

When everything is powered up, this converted robot arm carries out coordinated six-axis movements under the control of LinuxCNC's kinematics module. The base machine is a surplus Fanuc R-2000iA/200F, a 1.5 ton arm that still wears its RO8 stencil. Excessive Overkill took hardware that most of us would walk past and turned it into something that moves like a proper multi-axis machine tool.



The path there was anything but simple. The original Fanuc controller carried mismatched firmware, which produced incorrect joint scaling and kinematics errors, and the answer was to move control over to LinuxCNC running on a Dell PC with a Mesa FPGA expansion card. The whole controller lives in a yellow rugged case, with Allen-Bradley safety relays and cooling inside, plus four 12V server supplies alongside two 24V units. Motion runs on open-source ODrive controllers refreshing at 300 Hz.



The detail that stands out most to me is the encoder work. The maker reverse-engineered the serial signaling with an oscilloscope and a logic analyzer, worked out that it was a two-wire half-duplex RS-422 scheme, and then wrote custom VHDL so the Mesa card could decode the two-wire Fanuc encoders directly. That link runs at 2.7 Mbaud with an 8 kHz request rate, and servo PID following errors came in at up to 0.2 degrees, which sounds tidy for hardware this size.



The one open trade-off is speed. Right now the top speed sits at roughly 10%, since the 48V supply is a long way below the motors' standard rating of around 200V. That leaves a lot of performance on the table, but even at a crawl this is an impressive piece of work.



Project by Excessive Overkill. Watch it on their YouTube channel:

formatting link


This is a great conversion. I am curious about the encoder side of it. How did the maker actually work out the signaling format for those Fanuc encoders before getting them to talk to the FPGA card?

The choice to put the encoder decoding into custom VHDL on the Mesa card strikes me as the cleverest part of the whole build. Handling the two-wire serial scheme in hardware keeps that timing-sensitive work off the PC, and it means the arm's own encoders stay useful instead of being replaced. Given the 0.2 degree following errors, it clearly paid off.

If the maker ever wants more speed out of this, the obvious lever is the supply voltage. The motors are rated for around 200V and the current 48V supply caps things at roughly 10% of top speed. Moving to a higher voltage supply on those ODrive controllers, or whatever drive hardware suits that rating, would unlock a large chunk of the arm's original performance.

That part is documented. The maker reverse-engineered the serial signaling using an oscilloscope and a logic analyzer, discovered it was a two-wire half-duplex RS-422 communication scheme, and then wrote custom VHDL to add two-wire Fanuc encoder decoding to the Mesa FPGA card. So it was a proper reverse-engineering effort rather than guesswork.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required