Very nice :)

I have an offer from a forum member to go and take a look-see at his machines, and a general chat, so I'm going to take him up on his offer. Think I will feel much better once I've seen a DIY-constructed device, then make a decision.

Breaking out onto a separate topic a little.... on the electronics side of things... the stepper drivers and the motion controllers. Just want to check my understanding; is the following right?

Motor Drives

These are really nothing more than stepper driver ICs, of which obviously there are a plethora out there with various ratings in terms of voltage, current, stepping capability and safety features. Bolted on to that are the relevant amount of heatsinking, protection/filtering but ultimately they take a low-voltage signal from a microcontroller or parallel port - with appropriate optical isolation - and move the motors as requested. One tick = one unit of movement (in the appropriate direction, of course).

There are differences in terms of matching them to the motor (number of wires for unipolar, bipolar) and you can get analogue and digital ones, digital ones being better all-round but presumably more expensive. There are trade-offs with how you drive the motor in terms of microstepping, torque, heat generation and so forth. So you need to know your motors in conjunction with your drivers, and also what you're going to use them for (what's most important - torque or speed).

You can get ones with direct parallel port drive (so no motion control; driven straight from PC) but then the honus is on the PC as the controller, hence all the requirements in terms of it being able to keep up. Each pin on the parallel port controls a function, which limits you somewhat to the number of axes/functions you can make use of.

Other alternatively you can get drives controlled from a separate motion controller in between the drivers and the PC.

Motion Controllers
These do the interfacing between your PC (via parallel port, USB or ethernet port) and the motor drives, but instead take a proprietary protocol and convert that to the native signals for each axis drive (they don't take G-code). The benefit of these is they can layer on all sorts of fancy stuff like inertia concepts, but the big gain here is really offloading the requirements from the PC to keep up with the frequency of signals needed to instruct the drivers directly. The motion controller interprets the movement commands (move X from 0 to 100) to how many steps that needs on which axis, at what speed, and then takes on the job of reliably hitting the driver with the requisite clock signal and appropriate-timed control signal.

You potentially gain some speed/reliability on your machine and generally it's the way forward unless you just want to have a play at slow speeds direct via parallel.

When you guys refer to BOBs (Breakout Boards) you're generally talking about motion controllers, although you can get BOBs that combine both of the above.

It strikes me that keeping them separate gives more flexibility as the drivers need to match the motors; if you get a combo BOB you'd need to be sure that the drivers side of it matched your requirements and they weren't going to change.

Point, laugh, poke the shit out of the above where I've got it miles wrong :)