Non self replicating reprap 3d printer

The reprap is designed to be able to "self replicate" to a degree. If a part on a reprap 3d printer breaks then a replacement part can be printed and attached. Parts can evolve as new ideas come along. Having parts crack or weaken on a 3d printer can be undesirable though.

A part on this printer was a mix of acrylic and PLA, both of which were cracked. Not quite what one would hope for as a foot of the y-axis. It is an interesting design with the two driving rods the same length as the alloy channel at the back of the printer.

A design I thought of called for 1/2 inch alloy in order to wrap the existing alloy extrusion with a 3mm cover. The dog bone on the slot is manually added in Fusion 360 so it is larger than needed. The whole thing being a learning exercise for me as to how to create 2.5D parts. The belt tensioning is on a 6mm subassembly that is mounted on the bracket in the right of the image below.

The bracket and subassembly are shown mounted below. Yes, using four M6 bolts to tension a belt is overkill. I would imagine you can stretch the belt to breaking point quite easily with these bolts. The two rods are locked into place using M3 tapped grub screws. The end brackets are bolted to the back extrusion using two M6 bolts.

The z-axis is now supported by a second 10mm alloy custom bracket. This combination makes it much, much harder to wobble the z-axis than the original design using plastic parts.

Machine Control with MQTT

MQTT is an open standard for message passing in the IoT. If a device or program knows something interesting it can offer to publish that data through a named message. If things want to react to those messages they can subscribe to them and do interesting things. I took a look into the SmoothieBoard firmware trying to prize an MQTT client into it. Unfortunately I had to back away at that level for now. The main things that I would love to have as messages published by the smoothie itself are the head position, job processing metadata, etc.

So I fell back to polling for that info in a little nodejs server. That server publishes info to MQTT and also subscribes to messages, for example, to "move the spindle to X,Y" or the like. I thought it would be interesting to make a little web interface to all this. Initially I was tempted to throw over websockets myself, but then discovered that you can mqtt right over a ws to mosquitto. So a bootstrap web interface to the CNC was born.

As you can see I opted out of the pronterface style head control. For me, on a touch panel the move X by 1 and move X by 10 are just too close in that layout. So I select the dimension in a tab and then the direction with buttons. Far, far, less chance of an unintended move.

Things get interesting on the files page. Not only are the files listed but I can "head" a file and that becomes a stored message by mosquitto. As the files on the sdcard of the smoothieboard don't change (for me) the head only has to be performed once per file. It's handy because you can see the header comment that the CAM program added to the G-Code so you can work out what you were thinking at the time you made the gcode. Assuming you put the metadata in that is.

I know that GCode has provisions for layout out multiple coordinate spaces for a single job. So you can cut 8 of the same thing at a single time from one block of stock. I've been doing 2-4 up manually. So I added a "Saves" tab to be able to snapshot a location and restore to it again later. This way you can run a job, move home by 80mm in X and run the same job again to cut a second item. I have provision for a bunch of saves, but only 1 is shown in the web page in the below.

This is all backed by MQTT. So I can start jobs and move the spindle from the terminal, a phone, or through the web interface.

CNC Control with MQTT

I recently upgraded a 3040 CNC machine by replacing the parallel port driven driver board with a smoothieboard. This runs a 100Mhz Cortex-M mcu and has USB and ethernet interfaces, much more modern. This all lead me to coming up with a new controller to move the cutting head, all without needing to update the controller box or recompile or touch the smoothieboard firmware.

I built a small controller box with 12 buttons on it and shoved an esp8266 into that box with a MCP23017 chip to allow access to 16 gpio over TWI from the esp mcu. The firmware is fairly simple on the esp, it enables the internal pull ups on all gpio pins on the 23017 chip and sends an MQTT message when each button is pressed and released. The time since MCU boot in milliseconds is sent as the MQTT payload. This way, one can work out if this is a short or longer button press and move the cutting head a proportional distance.

The web interface for smoothie provides a pronterface like interface for manipulating where the cutting head is on the board and the height it is at. So lucky that it's open source firmware so I can see the non obfuscated javascript that the web interface uses. Then work out the correct POST method to send gcode commands directly to the smoothieboard on the CNC.

The interesting design here is using software on the server to make the controller box meet the smoothieboard. On the server MQTT messages are turned into POST requests using mqtt-launcher. The massive benefit here is that I can change what each button does on the CNC without needing to reprogram the controller or modify the cnc firmware. Just change the mqtt-launcher config file and all is well. So far MQTT is the best "IoT" tech I've had the privilege to use.

I'll probably build another controller for controlling 3d printers. Although most 3d printers just home each axis there is sometimes some pesky commands that must be run at startup, to help home z-axis for example. Having physical buttons to move the x axis down by 4mm, 1mm and 0.1mm makes it so much less likely to fat finger the web interface and accidentally crash the bed by initiating a larger z-axis movement than one had hoped for.