Sunday, January 19, 2014

I picked up a 3-axis beefy NEMA-23 stepper kit from ebay for around $240. It comes with a Longs Motor DM542A stepper controller, which seems to be more or less identical to a lot of other brands.

The kit came with a board that takes commands from a PC parallel port (driven by eg., linuxcnc), and apparently the timing is such that USB-parallel adapters don't work well; you need a hardware parallel port.

I wasn't particularly excited to track down a machine old enough to have a parallel port and lug it around with my project, so I looked into whether the GPIO pins on my Raspberry Pi would be suitable to drive the DIR (direction) and PUL (pulse / step) pins directly. I found some general discussion, but not much that was concrete.

I think I originally picked up NOOBS to put on the SD card, but it's been a while and I don't remember exactly. But it came up with a menu and I picked the recommended option of Raspbian wheezy, which it downloaded and installed. Installation was a breeze, and the machine has been working great for me. (I'm writing this post on it, even, although it's pretty laggy if I try to open multiple tabs in the browser).

Most of the skepticism I saw about using the GPIO pins centered around the need for an RTOS to ensure that the process toggling the pulse line can do so at the required intervals without getting held up for extra milliseconds. When I ran "uname -a", I noticed "PREEMPT", which means that it already has some (but perhaps not the most extreme variety?) kernel patches for hard timing. Awesome!

Voltages were another concern: the stepper driver wants 5v logic inputs, but the raspi runs at 3.3v. Fortunately, this doesn't seem to be a problem either; the driver board seems perfectly happy with 3.3v input.

At first I though my driver wasn't working right when I wired it up -- I got no power light. But it turns out the ENBL line needs to be pulled down rather than up for the board to work.

I also found that the board doesn't seem to have the - side of each input tied together, so I had to wire up the ENBL-, DIR- and PUL- inputs all to ground.

I looked over the pinout for P1 on the raspi to figure out which GPIO lines to use, and didn't find any major reasons to use any particular ones; seems like almost all of them have alternate uses that I mostly don't think I'll need. So I used pins 1, 3, 5, 7 and 9, corresponding to +3.3v, GPIO-0, GPIO-1, GPIO-4 and GND on my rev. 1 board.

My first stab at controlling the stepper used the python example code. Note that this code uses board pin numbers rather than the GPIO numbering:

This worked just fine, although as expected, it'd glitch every few seconds, audible as a stuttering sound in the stepper. Glitching got worse when I loaded down the system by doing things like loading web pages.

Next I tried the C example code to see if it'd do better. It might have been somewhat better, but still had noticeable glitching.

So it looks like the principle is sound. The remaining task is to get it integrated with some sort of g-code interpreter (update: I ported grbl to raspi), at which point we'll have a $35 CNC controller with HDMI output that can drive step/direction pins on stepper controllers directly, without having to use parallel ports and adapter boards.

Hi there, have you got any updates on your tests? I've picked up your idea,I have a similar set, and soldered a db-25 to a ribbon cable and tried to test the comms betwen the rpi and a driver trough the interface board. That way I could use my hardware setup, with parallel interface, and plug it to the Pi without changing anything. Electronicaly I think it's possible, and you get 3,3v turn in to 5v to control the drivers, but I got stuck in the C language programing...