MDF framed pick-n-place moving

Last week, we hacked together an mdf-based pick-n-place frame. Actually, it's just a bog standard x/y cnc axis, but it's going to form the basis of our pick-n-place machine, so that's what we're calling it. We hooked up our stepper motors to some L298N based (dual H-bridge) driver boards and using a bit of investigation, worked out the required coil-activation sequence (by putting power onto each of the IN1, IN2, IN3 and IN4 pins on the board, in sequence, until the motor rotated smoothly without jumping).

Once we had our coil-activation sequence (in our case, it was IN2, IN3, IN1, IN4, to get smooth, single-step rotation) we simply cobbled together some firmware which would accept serial data, and activate the stepper motors.

Our principle of moving is simple:

The PIC microcontroller (we went with a massive 16F877A because a) we had loads hanging around and b) they have loads of i/o pins, which gives us scope for expanding and using limit switches, parts feeder and so on, without having to expand the mcu) accepts serial data in the format -

zero byte (start of message marker)

command byte (value of 0x01 tells it what follows is position data)

parameter data (changes depending on the command byte sent).

When we send a command byte of 0x01 (positional data) the mcu simply compares the incoming data (the destination co-ordinates) with the currently stored x/y/z data. If the destination value is different to the current value, for each of the axes, the mcu drives the stepper motor one step closer to the destination value (updating the x/y/z position values along the way).

While any of the x/y/z destination values are different to the actual x/y/z positions, the mcu displays a "busy" indicator (for our example, we use a red LED). When the controller sees all axes are in their appropriate destination positions, it lights a "ready" indicator (a green LED) and sends a single byte (0xFF) back to the controller - like a "clear to send" indicator.

The video below shows the CNC being tested with the serial-based firmware

During the video you can see the command sequence

00 01 02 00 02 00 00 00 being entered

This tells the mcu:

00 - start of message

01 - position command

02 00 - set the x axis to 512 (the two byte value represents a 16-bit integer)

02 00 - set the y axis to 512

00 00 - do not move the z axis (we don't actually have one attached yet)

When the data is sent you can see both axes move at the same time.

As they are both increasing one step at a time, they both move together.

It is possible to update just the position of one axis - in this example, we changed the value of the y-axis and the x-axis remained in it's unchanged position (we also got the wrong steppers connected to the x/y pins: we tend to think of the bed as the y-axis and the gantry as x, since we normally position the cnc with the gantry going "across" our viewpoint, but seeing them the other way around is equally valid, depending on where you consider your x-axis).

At the end of the video, you can see the y-axis crash into the end of the gantry, and hear the belt slipping. This was a mistake in the data entered - we set the y-axis to 0x2000 instead of 0x0200 (in decimal, that's the difference between telling it to move 8,192 steps, and 512 steps!). The video ends just as we pulled the 12V supply from the motor controllers, to avoid damaging or stretching the belt.

We're only using single stepping (activating the coils in a simple 2,3,1,4 sequence) rather than microstepping. Whether or not this gives us the accuracy for placing components we need remains to be seen - 512 steps seems to move the carriage quite a distance (though we could go from 4 single steps into 8 micro-steps, using the "inbetween positions, by activating two coils together, to give better accuracy if it's needed).

From testing though, it looks like the next job is to add some limit switches on the end stops!