There’s an overall workflow for carving anything with a CNC machine. The three basic phases of this workflow are:
- Create a drawing in a drawing program. Save it in a vector format.
- Convert this vector based drawing into machine commands, known as gcode. Usually this is done with a Computer Aided Machining or CAM program.
- Interpret this gcode into actual pulses and steps for the motors.
When I started on this path, I didn’t know which interpreter I would use. The four friends I had at the hackerspace convinced me that I should go with LinuxCNC running on a PC instead of using a gcode interpreter based on arduino (GRBL). While LinuxCNC is a bit more complicated, it’s very powerful. To drive the motors, LinuxCNC is a hybrid between the Linux kernel, and a real time kernel. The Linux kernel yields control to the real time kernel when real time deadlines need to be hit. For something to be classified as a real time system, it needs to have the ability to respond to an interrupt, or to hit deadlines (like setting a signal high or low) within a very short time window. This requires an interface capable of being toggled in real time, and that happens to be the trusty old parallel port. Why can’t we use a USB interface? Why do we have to use an actual parallel port and not an adapter? USB just can’t offer a real time response capability because USB is considered “Isochronous”, which means “equal time”. USB has timeslots that are assigned to the endpoints attached to the bus. This means that an endpoint won’t get data until the timeslot for it comes around. If your real time signal fires, and it has to wait because it’s timeslot passed by, then by the time the timeslot comes back around you’ll have missed the deadline.
Timing is only one aspect. The pins of the parallel port can’t drive a stepper motor directly, it simply doesn’t have the power to do so. This is where a stepper motor driver comes in. It is a module that takes a few inputs, like “direction” and “step”, as well as some others like “enable” and “microsteps”, and turns it into pulses out on four wires. It makes driving a stepper easier, especially if you’re doing any sort of microstepping. While we could hook the pins of the parallel port directly up to the stepper driver boards, that would be somewhat foolish because it would expose the CNC controller PC to potentially hazardous (for it’s health) electrical transients. Usually when interfacing any type of logical signal to the dirtier world of electromechanical signals, you want to use some sort of isolation. Optocouplers are the right choice here. Luckily, I have a friend from my hackerspace who designed his own carrier board for Pololu DRV4425 driver boards. It comes with optocouplers to connect the output pins to the drivers as well as the input pins for the limit and home switches to the input pins on the parallel port. I have four of these drivers to plugin to the carrier board. For my build, I need a driver for the X and Z, and two drivers for the Y axis. These are the ones I am currently using:
He gave me one of the blank boards and the BOM shopping list at Mouser, but the rest was up to me to assemble it. Armed with my trusty Metcal soldering station and my newly constructed redneck-fume-extractor, I got to work.
You always need to double check your boards. There were two defects that caused me problems that should have been caught in electrical test. I don’t think my friend paid for that level of service though. The first defect is a missing plating on a drilled hole. One of the holes for the DB-25 pin connector wasn’t plated, and was effectively electrically unconnected. While I could attempt to load up as much solder on that pin as possible and see if it would connect, the simplest answer is simply to figure out where it should connect and solder up a small jumper wire.
The second defect was far more insidious and took 3 weeks of time to find and fix. The problem was that the direction pin for the Z-axis motor controller didn’t seem to be connected to the stepper controller. In tracing out the signal with the oscilloscope, I discovered that the signal went into the optocoupler but didn’t affect any change on the output pin for that signal. My first thought was that the optocoupler had either been defective from the start, or that I fried it with a static charge. I try to be cautious about static, but I’m also not paranoid, so it’s possible that it got fried by a bit of my easy going attitude. An order into Mouser and a week later and I had a new optocoupler. I plugged it in and…. nope. No change in signal.
It hadn’t occurred to me initially that it was a circuit board issue. Not until I tried the new chip and it didn’t work that I removed the board and started actually metering out each connection with a continuity check. Turns out, the copper trace for that signal connected up to the stepper driver, but didn’t attach to the pin of the optocoupler. This too required a jumper wire fix. I’m happy to say that’s all that was wrong with the board.