Description
Adding USB connection, drivers and a new postprocessor to a low cost CNC mill (Roland MDX-15 / MDX-20).
Features
- Adding USB interface to main PCB
- Custom FTDI driver
- HTML post processor
- Batch files to control mill
Development
During my parental leave it is a somewhat bigger project for me to use the professional CNC mill at work. Since I have a miniature CNC router at home I don’t use anymore, I figured now would be a good time to improve it. The reason that I don’t use it is mainly due to the ultra crappy software that Roland provides. Each time I have to mill something, I have to spend a lot of time tricking the software to do things that it originally doesn’t support, which is time consuming, frustrating and usually results in several trials until it works. The fact that the mill doesn’t have support for G-code means that you most likely can’t use the CAM programs that you prefer (some third party options exist, but I haven’t found any worth the money). On top of that the mill needs a RS-232 serial connection and doesn’t work directly with an usb2serial cable (with default drivers)… These are the reasons that the mill has been collecting dust on my attic for the last six years. This is a pity, because the mechanical hardware is actually quite good.
Adding USB interface
I hate cables and connectors that fall apart almost as much as I hate running back and forth between the mill and the PC. Therefore I wasn’t so fond of adding an usb2serial adapter at the end of the long serial cable. Instead I added an FTDI usb2serial (TTL) chip inside the machine. Now I can just plug it in and it will work. Any FTDI chip that has Rx, Tx, RTS, CTS, DTR and DSR will work. I used a Sony Ericsson dss-20 syncstation which has all the necessary components, but a standard FTDI breakout board will work just as well. The mill has a very limited memory for storing commands and therefore uses hardware flow control for the serial communication. To support this I soldered a wire between RTS and dsr and one wire between CTS and DTR on the FT232BL chip. Then four cables were attached to Tx, Rx, GND and to the CTS/DTR wire. 
I hoped that I could attach the cables to the secondary side of the DS14C238 chip on the main PCB in the mill, but it didn’t work. Instead I attached them directly to the primary side of the MAX238 clone.
- Rx to pin5 (Din1)
- Tx to pad under pin6 (Rout1) **
- DTR/ CTS to pin 19 (Din3)
- GND to pin 8 (GND)
** please observe that pin6 has to be lifted from the pad to release the signal to the main H8 CPU (solder the cable on the pad under the pin, make sure the pin isn’t attached). When all the cables were attached I used hot glue to mount the USB board above the main board inside the mill. I also secured all the cables between the boards (see photo). A small hole was cut in the cover of the mill to attach the bend protection on the USB cable.
The USB to serial adapter mounted inside the mill (the small board above the main board)
Adding custom FTDI drivers
If you search for mdx-20 and USB adaptor you will find that a lot of people have failed using a USB to RS232 adapter with the mill. They explain that the mill needs an old pc with a real serial port, since the USB protocol (package length) doesn’t work with the hardware flow control. – This is a myth! They are right that a USB serial cable doesn’t work with the default drivers. But you can find custom drivers on the Roland web site that works with a FTDI adaptor.
Reverse engineering a new postprocessor
With my USB connection for the mill, the hardware was up to date. The next thing to fix was the software. I really don’t like the Roland software package (modela, dr engrave, 3d engrave) that was already out of date when it was released 12 years ago. I didn’t want anything to do with the programs or the drivers, so I figured it was best to communicate directly to the mill itself. (It will then also work on all platforms, Linux, WindowsXP/7/8 etc). I created a fork of html-cam, which allows you to convert mill paths from a very simple neutral file format to g-code (also works on all platforms). See more details here. Instead of generating g-code the new versions now generates a Roland CNC mill file that can be sent directly to the serial port. I ran into quite a few problems during the development. To reverse engineer the protocol, I generated some simple curves and printed them with existing software. Instead of sending the file to the mill, I printed it to a file. Then it was a matter of understanding the generated code. The syntax is quite weird, but after a printout and some study with a highlight pen I got it to work. The only problem was that all the mill movements were too big. I guessed it was related to a mm to inch conversion, so I divided all the lengths with 2.54. Better, but when I measured some samples more precise, they were now slightly too small instead. I realized that a division of 2.5 gave a perfect result. Since the mill doesn’t handle decimal places the right coordinates of a position in mm has to be multiplied with 40 (100/2.5). I guess this is just the ratio of the stepper motors and have nothing to do with imperial/metrics conversion… Finally I got the 2D conversion to work and I quickly converted the drill operation as well. I can now export my mill paths from Rhino3d (using this script) to the neutral file format and then paste them in html cam (MDX version), set cutting parameters and generate mill code that can be directly sent to the com port.
Setting up the com port
Sending data from html-cam to the printer is really simple. First you need to make sure that the port is configured correctly (with the right custom drivers if you use a USB adapter, see above). Then the com port needs to be set up using the following command in a dos/command prompt:
“mode com3:9600,n,8,1,p”
Then all you need to do is copy the generated file to the port:
“copy /b mill.txt com3”
To make it even easier I have made some batch files to automate it for you. (download further down)
Manually moving the mill
When I set up the mill it is very useful to be able to move the router to an exact position. To do this I created another batch file with the following syntax:
movemill p,x,y,z p: com port (default=3) x,y,z: Coordinates * 10 "Example 2.55mm -> 25"
It moves the mill to the exact position that you specify. Please make sure that no obstacles are in the way of the spindle movement.
Example – make a PCB
Here is a step by step guide for how a PCB can be milled with the Roland MDX-20:
- Design the PCB (can be done in Rhino – see this guide for more details)
- Fixate FR3/4 substrate on mill (using double sided adhesive)
- Power on mill and leave “view mode”
- Mount engraving tool in mill
- Prepare and export mill paths for the PCB (in neutral file format)
- Move engraving tool 4,4 mm (x,y) over PCB using the batch file “movemill 3,40,40,0”
- Set Z=0 using the down key on the mill (press down repeatedly until you have contact – listen to the a change of sound)
- Paste engraving mill paths in html-cam and set cutting parameters: 1mm clearance 0mm cutting depth (-0.1 if the cut is too shallow) 2mm/s engage speed 4mm/s cut speed
- Press generate key and copy generated data to a text file named mill.txt
- Run mill.bat (configures com port and copies mill.txt to com port)
- Lean back and enjoy a PCB being made
- Repeat steps 4-11 if you need to drill the PCB and finally for cutting out the release path.
Caution
Use the files with care. I have tried them with good result, but I don’t take any responsibility if they generate any error. I recommend that you set z=0 above the workpiece first and mill in air to make sure everything goes as expected. When it works, reset zero and redo the operation. Make sure that the indata is correct and doesn’t contain any strange characters.
Documents
See also
Licensing 
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
great job I like the idea, I recently bought Sekonic SPL-470 8 pen printer that i dont know how to find driver for it i had to buy printer port for my i7 motherboard nothing seem to work I cant find such solution arround me nor hardware i guess what you did can be usefull for others i have seen plenty of ppl strugeling to have this way, I even thought of replacing the whole board with a CNC like but as I said I am not able to find those items closer to me I need to import from USA and try it.
Gr8, I hope that it works.
Let me know how it goes!
Thx for the instructions.
Now all I need to do is to find a used MDX-20 (been trying for a long time but none for sale here in Sweden) and use your instruction to alter it.
Or is yours for sale?? :P
No, mine is unfortunately not for sale, (I’m quite satisfied with it since the update).
You can also check out their latest model – imodela, you can get a new one for less than 6000SEK!
http://www.creativetools.se/imodela.html
Good luck finding one!
I have an MDX-15, with comes with some kind of ME-US3 cable from Roland. However, when using it (especially on laptops) the mill at random times go crazy and off into any direction it wants, ruining the model, and material stock.
With the serial cable on an old laptop, it works fine with the same file.
Roland tech support cannot help with this. can anybody? is there a usb to serial cable /driver combo that works?
I encountered a similar problem lately. It happens when you use standard drivers for the USB to serial adapter. The problem occurs when data is lost during transmission due to the USB buffer size. Even with a minimal buffer size of 64 bytes there will still be some problem… You need to install the custom drivers from Roland site to solve this. I don’t know exactly how it works, but I guess I don’t have to ;)
Maybe a windows update overwrote my driver files since they worked earlier. Anyway, I uninstalled the old USB to serial drivers and installed the Roland driver and now it works again!
Hey Johan, do you have any more information about the buffer problems when using FTDI USB-Serial cables? I’m using linux to talk to my MDX-20 and running in to buffer problems at times. Is the FTDI compatible driver you mention the same as the “me-us3” one?
I’m using the MIT Fab Modules code (http://kokompe.cba.mit.edu/) to generate tool-paths. I’ve had trouble getting in touch with the people working on it, so I have my own fork on github (https://github.com/thatpixguy/fab).
I’ve made a python program that can convert the SVG produced by pcb2gcode into the internal “path” file format used by the Fab Modules, which can then be converted to RML. I also have a program to convert Excellon drill files to paths.
Currently I’m having some problems with alignment between the two toolpaths but I should have that fixed soon.
Hi
Yes it is the me-us3 driver that makes it work (for windows). I don’t know how they have solved the problem with the usb buffer, but it doesn’t work without the driver and it works once it is installed. You can read more about usb buffers and handshake in this document (and maybe find a solution):
http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf
I have tried to modify the buffer size manually. A minimal buffer creates fewer problems, but it still creates errors.
FTDI also has some software tools like ft_prog and USBView that you can find here:
http://www.ftdichip.com/Support/Utilities.htm#FT_Prog
I hope that it helps, even if I don’t have a solution…
Good luck with the buffer and the tool path generation!!!
Hey,
It wasn’t until I started looking in to how to fiddle with the FTDI buffer sizes, that I realised that my cable was actually a PL2303 chipset, and not FTDI. I just recieved an FTDI based cable that I ordered, and now I’m getting much weirder behaviour. With the PL2303 chip, passes would just crash mid-program, but now I get random moves starting somewhere in the middle of a long pass. I guess this is the behaviour you have been getting all along.
Now I’m looking how to mess with the buffer size in the linux ftdi driver (there is a library for messing with the ftdi chip, so that is promising).
Our Hackerspace backed the OpenViszla USB-analyser kickstarted compaign eons ago. If that ever actually produces a product (it has been very delayed), we can use it to see how the ME-US3 driver is configuring the FTDI chip.
pix
Gr8 work! let me know how it goes.
/j
No amount of buffer changing can fix the problem; it’s the *mill* buffer, not the PC buffer, that’s overflowing (and when the PC doesn’t check the hardware flow control and keeps sending anyhow – that’s when data gets lost).
The data going out over serial is RML-1 commands, and if it sends any command that takes the mill time to complete (eg: move the head a long way), then your computer will overflow the buffer IN THE MILL.
This is why random erratic behavior happens – because the mill buffer got full, the PC kept sending more (which gets lost) then the mill uses up some buffer (making more room) and the PC sends more data still… so you get a whole bunch of movement and milling commands executed where others got lost – which generally means the head is not where it should be, and all crazy stuff goes wrong next.
Here is the programming info for the original MDX-20 instruction set:
http://wiki.fablabbcn.org/File:RML1_Command_GuideENVer100.pdf
I am guessing that the mod described on this page will break the ability of the MDX-20 to be a scanner?
From my experience – when the scanner head is plugged in, the machine no longer identifies itself as a milling machine (that is – it almost certainly speaks a completely different protocol, and not RML-1 anymore).
No, it doesn’t affect the scanner possibility. With the right drivers the machine will still be able to work as a scanner (together with the Roland scanner software).
/j
I need to change the FTDI buffer size to 64 bytes. I was wondering anyone knows me an “easy” way of twiddling the current buffer size of an FTDI device under Linux. Ideally it would be an existing command-line tool would be great
I changed the motor for a dremel.
That’s a good idea, especially if you have the 6mm spindle and want to use smaller cutters!
It is probably quieter too…
/j
Hi Johan,
The link for the Roland USB drivers doesn’t seem to work anymore. What should I be looking for on the Roland website? Also, do you know if the internal IO of the MDX-20 is 5V or 3V3?
Thanks!
Johan
Hi Johan
The driver is still on their site; look for the ME-US3 serial cable driver. The mill I have is so old that 5V was default (and the DS14C238 has an operating range for VCC around 5V). Measure on your board just to be safe…
Good luck!
/j
Hi Johan!
So I have a little question about Roland. I’m currently using the MDX 15 (not the 20, unfortunately) and I’m supposed to write a Labview program that can send an image to Roland (it has to carve it into a piece of wood).
It seems that the problems mentioned by the others is the one I have: when I send the picture to Roland, I think that there is a buffer problem because it always begins as planned but then does weird stuff (often, it just carves a diagonal line and that’s it).
The problem is that we are required to work on a Mac (I’m on a Macbook Pro mid 2010, Mountain Lion), and I’m not finding the driver on their site. Any idea where I could find it?
Hi Valentine
Yes, that problem seems very familiar… Unfortunately i don’t know where you can find mac drivers (unless you can find in on the Roland site (bootcamp? ;)
Good luck!
/j
Well, thanks for the information!
Unfortunately, I’m required to make it work for OSX so bootcamp isn’t really a solution!
But thanks anyway!
Just to let future mac users what i did to make it work:
So, the problem is that the buffer is overloaded with information when we don’t have the corresponding driver. Therefore, my teammate and I have forced our program (in Labview) to send the information as “blocks” (3 points at the time). This is a good way to let Roland enough time to process everything, but it’s kinda slow. So we optimized the image in such a way that all the redundant information is removed.
Search for the source code for my “Roland Commander” program in perl: I “bypassed” the buffer issue somewhat by programming my code to understand how long each RML-1 command takes, and never sending data so fast that the mill hasn’t finished the last command before it gets the next one.
it’s here:
http://www.societyofrobots.com/robotforum/index.php?topic=16493.0
Before all thank you for your tutorial!
I’m trying to resuscitate my MDX-20.
I saw your pin configuration to connect a USB-serial adapter directly to the cnc milling but I notice a mismatching between your circuit schematic and your photo posted.
especially for the missing connection between pin 1 and 3 of the MDX board.
can you explain, please?
I find mismatching between your photo and the circuit diagram posted above. Like the short circuit between pin 1 and 3.
Can you explain please?
The photo doesnt show the backside… The schematic should be correct.
Are you running it on windows 10? (i have not tested it since win7)
/johan
Hi, I was using Roland MDX 20 to cut modelling wax for the last 14 years. I am using windows 7 to run software. I had to change motor and a spindle a few times…but never had problem with drivers or software….now, I have this problem …..After I click the view button the machine brings cutting needle to the zero position/…than I press down button to bring a needle down/ to have a contact with cutting material…..and immediately all lights on the machine starts flashing off and on…..? At that moment the machine is frozen, does not except any gcode file…and it cannot start cutting. Do you have any solution for this problem ?
Regards Steve
Hi
It worked for me in previous windows versions, but not in windows 10…
I tried to use a raspberry pi as a printersever but got the same problem there. After quite a bit of investigation i realized that it’s the timing of the serial interface that is the problem (modern computers being too fast).
My solution was to use an Arduino as a serial proxy (with a tiny delay for the hw control of the serial interfase). I can now communicate to the arduino with software flow control and the arduino translates the communication to hw control. It works great for me, but i’m not sure if it would work for you (depending on the software you are using)
/johan
i am looking for an mdx 20 scanner head any ideas
Hi
I guess that you don’t have the scanner head that comes with the MDX mill/ scanner?
It is built around a piezo speaker, but there is some electronics in between to amplify and filter the signal.
A microswitch is easier to implement, but not as accurate…
/johan
Hello this thread seems a bit old but anyway, I have a MDX 20 that is gathering dust. I though an easier approach might be to remove the pcb and replace with an arduino mega and a stepper drivers. Anyone attempted this?
Thought about it but used an Arduino as serial proxy which solved my problems. About to post details soon…
/j
Here is the post describing the serial proxy I mentioned yesterday:
https://vonkonow.com/wordpress/2019/12/solving-roland-mdx15-20-serial-interface-problems-once-and-for-all/
/j