LinuxCNC/Machinekit, BBB, and Python

Background

My original computer controlled microscope ran LinuxCNC on an old laptop:

You can see AXIS running on the laptop to the left along with a scan pattern.

Unfortunately, it was difficult to make this system compact and reliable.  Laptops aren't really that great to run real time software because ACPI gets in the way.  Desktops can work but they are bulky and still need to be somewhat carefully selected.  My Sherline mill compromises by using a mini ATX motherboard connected to a laptop.  That way the laptop does all the display, keyboard, and mouse in a compact form factor while running all the real time tasks on a purpose built PC.

But this was still too big and costly to generally deploy.  Instead, I made "pr0ndexer" which runs on inexpensive STM32 dev boards.  The firmware was written in an afternoon and seemed to work well to get the job done.

Or did it?

After a while one of my motors started to slip.  Evidently lack of acceleration was wearing out gears in the linear stage.

Oops.

So I patched up the software with some crude acceleration and production continued to hum along.  But still it was still pretty crusty:

• Pulses are generated with sleep statements instead of timer ISRs.  Receiving serial characters (or other tasks) messes up the timing
• Only one axis can be moved at a time

Towards the BBB

While this was happening it was brought to my attention that LinuxCNC had been ported to run on Beagle Bone Black (BBB) by the Machinekit.  At this point though things were working well enough that I decided not to pursue that.

Fast forward to 2015.  I'm building more robots and need to decide what the next control system will look like.  I decided to revisit Machinekit/BBB which I'm just going to loosely call BBB.

For most of these systems I'm moving some number of stages and doing some sort of image capture.  There are two ways the system could be used:

• Run LinuxCNC on the BBB and also do image capture (ie through the USB port)
• Use BBB as a remote control drone and run image capture on a laptop

For a variety of small reasons  I decided to continue controlling the setup on laptops and use BBB's as control drones.

linuxcncrsh/emcrsh API

When you start LinuxCNC there are a variety of frontends you can use to interact with it with AXIS probably being the most common.  One alternative is the rsh frontend which launches a sort of telnet command server instead of a GUI.  The developers make no claim that its a robust interface but note that it may be good enough for quick and dirty projects.

Seeming to be the easiest way to use in a drone fashion, I started with this.  I ran into a few snags though:

• Axis homing takes a long time.  My theory is that this has something to do with the way that poll() works (see later) but I'm not really sure
• No position feedback: a command is either running or completed

Still, I was able to control things and get running pretty quickly using pyexpect.  Here is my python interface to it.

Python API

Unfortunately while I could get a quick PoC, rsh didn't seem to give enough control for what I wanted to do.  So next I tried the python API which is considerably more powerful.

Although this API is much more complex, it is well documented and I was able to get it working reasonably quickly.  The API is much richer and allowed me to do everything I wanted to (ex: getting position feedback). For example, the Python API is aware of fine points like the target position vs the actual position from servo feedback.

Remote python API

Unfortunately above only works locally (at least as far as I can tell).  To use the BBB from a remote system I decided to use XML-RPC since I've used it before and its pretty easy to use.  I instantiate a linuxcnc object that looks just like the linuxcnc module.  This allows programs written against the normal Python module to nearly seamlessly my remote version.

To make it run smoothly I do the following:

• Copy LinuxCNC .ini file to BBB (SFTP)
• Launch LinuxCNC on BBB using .ini file (SSH)
• Copy XML-RPC server to BBB (SFTP)
• Launch XML-RPC server on BBB (SSH)
• Create SSH tunnel from BBB to localhost
• Connect to BBB using XML-RPC client

I'm using the paramiko API to copy files over and launch remove processes.  Although I'm not using rsh, its still convenient as I can wait for the rsh port to open to know that linuxcnc is ready.  There might be better ways but this was easy and seems to work.

The core linuxcnc remote interface client and server are here.  The wrapper to remotely deploy it can be found here.   Here's an example program using the wrapper.

Polishing

I'm using the  CRAMPS configuration as a base.  This unfortunately has a lot of stuff I don't need and causes it to take a long time to start up.  I've started stripping down the config but there's still a lot to strip out (ex: thermal management).

I'd also like linuxcnc to launch automatically at start up which probably isn't too hard.  I'd also like my config files to get versioned which may just mean I check out the uvscada git repo to the BBB.  This eliminates most of the above steps.

XML-RPC has a lot of overhead: it creates a connection for every function call and XML isn't terribly efficient.  Fortunately I'm not doing anything super performant so this is probably okay.

Applications

I have several new imaging systems coming online.  This project was primary driven by my x-ray scanner:

which I'll do a post on in the near future.  I'm also planning on deploying this to existing systems like pr0nscope and k2scope.

Summary

The Beagle Bone Black is a very compact platform to run LinuxCNC from.  The rsh API is good for very simple remote control applications but you should use the Python API (or C API) if you need better control.  I've provided some wrappers to use the API remotely almost as easily as the local API.

For the amount of work put into this it came out pretty good.  There's still a lot of room for improvement but its mostly better than my pr0ndexer board.  The main disadvantage so far is that the BBB takes several minutes to start up where my board was ready in under a second.  For most of my applications this isn't a big deal.  That said, I'm eventually going to look into ways to cut down startup time.