Thursday, August 30, 2012

Roland MDX-20 with Linux

I've been setting up a Makers' lab at work recently, and one of the bits of kit we have there is a Roland MDX-20, it's a great little CNC mill for the price (it comes with a piezo scanner attachment too, for all of your object duplication needs), however, as is often the case, the software provided by the manufacturer only runs on Windows.

One of the provided programs is something called the Modela Player 4, and this is what loads in your 3D model, generates the corresponding tool paths for the loaded model, and spits those out to the MDX-20 ready to carve out your Star-Trek communicator badge (or whatever it is you want to make).

Rather than having to deal with the extra baggage that having a Windows machine often entails, I thought that there must be some alternative path we could follow, and started looking around.

It turns out that the MDX-20 uses a language called RML-1 rather than the more commonly seen g-code, and because RML-1 is a little obscure and is not really used much elsewhere, a lot of the alternative software options don't support it.

(For the curious, there's a document describing the RML-1 language available here.)

Tempting as it was to immediately disappear down the rabbit-hole of RML-1, what we really wanted was to get the mill up and running so that people could use it ASAP, so an obvious thing to try was to get the Roland provided software running under WINE.

I installed the various bits of software that came on the CDs in the box, and then downloaded and installed the updates from the Roland website, here: http://download.rolanddg.jp/en/3d.html#mdx1520.

It turned out that the software runs reasonably well under the version of WINE I tested (1-4-0ubuntu4.1 running atop Ubuntu 12.04 LTS); the 3D model display worked, and the various dialogs seemed fine, and, apart from a couple of lockups that I couldn't really nail down to any particular cause, it seemed like we were on to a winner.

A little more about the set-up, software and hardware:  the MDX-20 itself only has an old-school 25-pin serial port for communications with a computer, so I used the supplied 25-pin to USB cable which appeared as /dev/ttyUSB0 as you would probably expect;   the Modela Player 4 software treats whatever mill it's talking to as though it were a printer (RML-1 is not a million miles away from HPGL so you can see why that happened).  WINE uses the host's CUPS printing system so after a short bit of fiddling to add the mill's USB serial port as a local printer under CUPS the mill appeared in the mill config screen of the Modela Player 4 software.

So I tried a test mill... oh boy, what a disaster.

The tool head was moving about all over the place, so fearing damage to to the milling bit I killed the job and reset the mill.  Double checking that I'd configured CUPS in what seemed to be the correct fashion I tried again, got the same result, and sat back with no small measure of sadness, more or less resigned to the fact that I'd have to relent and accept that my immediate future now included looking after a Windows machine in a shared lab.

That evening, while doing something entirely unrelated I had a thought:  the random tool head movements I'd witnessed earlier seemed to be getting slowly deeper with time (before I stopped it), what if what I'd been watching was the mill skipping through to later parts of the tool path ?  Like, say, if there was a buffering/flow-control problem between the host computer and the mill - that might explain it right ?

So I double-checked the serial port settings with stty but hardware flow control was allegedly set, thinking that perhaps the mill's internal buffer was overflowing (reasoning that the perhaps the Roland Windows driver had some other magical way of handling flow-control) I tried using pv (PipeViewer - awesome little util by the way) to rate limit the RML-1 program as it was sent to the mill.  Neither of these things made any difference whatsoever.

The last thing I tried was to ditch the USB cable entirely and just use a Real serial port instead...
...bingo: Now the mill is behaving sensibly* doing what it's told !  (* more on that in another post.)

Making it work for you too

So, the steps are:

  1. Throw the USB serial cable in the recycling-bin and use a real serial cable (you may have to buy a PCI/PCI-E serial card for this if you don't have one on your computer).
  2. Add a local serial printer to your CUPS setup, pointing to the serial port to which your mill is connected.  Set the serial port options to baud=9600 databits=8 parity=none flow=ctsrts.
    I did this step via the gnome printer entry in the control panel.
    When you add the printer entry, make sure to configure it as as a Raw Queue device - we don't want CUPS trying to make our RML-1 files look pretty before sending them to the mill !
  3. Edit /etc/cups/cupsd.conf and add the following line to it:
      Timeout 0
    This should help CUPS cope when you pause the mill for an extended period of time (otherwise CUPS will think the job has stalled and abort it.
  4. Edit /etc/cups/printers.conf and add/modify the ErrorPolicy line to say:
      ErrorPolicy abort-job
    otherwise CUPS may 'helpfully' decide to retry the whole job if you pause the mill.  The previous line should really obviate the need for this change, but we don't really want CUPS doing the retry under any circumstances.
  5. Install WINE if it's not already installed.Instructions for this vary by distribution, but for apt-based distros it's
        sudo apt-get install wine
  6. Install the Roland Modela Player 4 software from the provided CDs using WINE
  7. Download and install the update patches from the Roland website
  8. Run the installed Modela Player 4 software, configure the mill to use by selecting the new 'printer' you just added to cups


With a bit of luck you should now be up and running and ready to mill as many Star-Trek communicator badges as you could possibly want.