I first started fooling around with the Fabio 1.1 microcontroller board from makeyourbot.org because it was a small board with very tight traces that I could use to test the Mantis 9.1 mill that I built. Plus, it was right there on the same site.
After cutting and soldering up a few I’ve become intrigued with it as a very minimalist Arduino-compatible microcontroller. The component cost is only $6-7 per board, and it’s an Atmega 168. So, I’ve been fiddling with it as a way of learning a little more about arduino-compatible microcontrollers.
Initial corrections: there are some problems with the info at http://makeyourbot.org/fabio-1-1.
First, the xls file for the Bill of Materials lists a 499 ohm resistor for R1 and R2. This is the correct resistance for those LED resistors, but the cat # given is
RK73H2BTTD4992F, which is actually a 49.9 k resistor. It should be
Also, you may notice that R4 (10 k) is not shown on the parts layout diagram. There are pads for it though, just below the ones for C6. This resistor just ensures that the Reset pin on the 168 stays high (until you connect it to ground with the reset button to reset the chip.)
Once I got a couple of them soldered up, I noticed a couple of peculiarities about the board. First of all, the power must be supplied through the FTDI serial header. The 6 pin ISP header does not supply power; the vcc pin is not connected. Likewise, the reset pin on the ISP also is not connected. These two omissions appear to have been necessary to maintain the simplicity (and cheapness!) of a fab-able, one-sided, no-through-hole board.
ISP note: if the ISP header had a plastic shield around it, the notch in it would have been at the top of the 2×3 block as you hold the board in a readable position. So the bottom 3 pins are Ground, MOSI, Vcc (not connected) and the top three are Reset (not connected), SCK, and MISO.
From left to right, the 1st and 3rd pins of the FTDI header are gnd and vcc respectively.
Supplying power through those pins, I was able to hold the reset button down and ping the board through avrdude with avrdude -c usbtiny -p m168 and release the button right when I hit enter, which got a response from the chip.
The next thing to figure out is how to write a bootloader for it. The issue is that other 3.3v, 8mhz bootloaders for the 168 all set the fuses for an external oscillator. The Fabio 1.1 uses the chip’s internal clock. So I’ve got to get the uncompiled bootloaders and get straight on the syntax, then recompile one for the internal clock.
That’s if I want to make it compatible with the arduino IDE, which I do.
Looks like I haven’t been posting for a while, mostly due to fussing with my 2nd makerbot and getting it to work as Splatspace’s official printer.
It appeared to be working fine with Ruttmeister’s stepper extruder mod, about which I had posted before. Then it suddenly developed problems. I thought at first that the extruder was stalling due to lack of torque, but I eventually realized that it wasn’t stalling, it was actually turning off. In fact, the green power LED on the stepper board was intermittently turning off, which meant that it was not getting power at all. I traced it to a bad molex power cable splitter, which I now need to re-solder.
After that there is some more tweaking to do to the Reversal settings. Updates and hopefully pics later. Also, I have made some progress with the Fabio 1.1 boards that I was milling out a while back. More on that tomorrow.
I printed out and installed TwoTimes’s Lowrider upgrade for Big Red. Files are here: http://www.thingiverse.com/thing:4213
It uses the original belts and rods, but replaces the rest of the X and Y stages with printed parts, plus small bearings in place of the nylon linear bushings.
Result: lower motor power needed, smoother operation, markedly less bot noise, and the platform sits about 1 cm lower. Also the Y rails are farther apart for more stability.
I don’t have endstops so that wasn’t an issue, but I do need to drill a hole at the right front and rear corners so that I can use small cable ties to secure the heated platform wiring and the Y motor cable.
In related news, I have officially put my other Cupcake “Baby Blue” into Splatspace. I am training folks to use it and it will be the Space’s printer for the forseeable.
I have two members interested in building Mantis mills so I should be starting to post build videos soon.
(For posterity and to aid others, as usual, so please excuse it if it’s too basic for whoever’s reading.)
Tuesday night at Splatspace’s Sparkfun visit I attempted to get my junky old Dell laptop to run the Mantis. (I was using my newer laptop to run Big Red.) So I documented the process carefully in case others have some difficulty.
(I neglected to document all the pitfalls the first time I did it- it’s easy to fall into the “open source crappy documentation” trap, which I complain about all the time- thus this post)
The Processing sketch “gctrl” is used to talk to grbl to jog the XYZ axes, zero the axes, and stream a gcode file, but Processing has some issues in talking to Arduino Uno’s on an Ubuntu machine. On the software page for MIT’s Snap mill
I believe this must refer to an older version of Processing, because that is NOT where that file is located now. In Processing 1.5.1, it is located and well-hidden in
Processing1.5.1/modes /java/libraries/ serial/ library
so go there and replace that .jar with the one from the Arduino download.
Then after downloading gctrl with:
git clone https://github.com/damellis/gctrl.git gctrl
you move the gctrl folder to the “Sketchbook” folder for ease of use (this makes it pop up in the “Sketchbook” entry on the Processing menu).
GIT NOTE: if you don’t have git installed and you try downloading gctrl with the git command as above, the terminal will prompt you with a suggested “sudo apt-get….” command to fix that. Go ahead and do it.
When running the gctrl.pde sketch, you first have to comment out the line
String portname = null by adding slashes like so:
//String portname = null
and then un-comment the line //String portname = “/dev/ttyUSB0” by removing the slashes and change it to
String portname = “/dev/ttyACM0”
ACM0 is the port for Uno’s running on Ubuntu. That last digit is a “zero,” not an “O.”
Make sure you save those changes to the sketch.
After all this, when you have your Uno (loaded with GRBL) attached to the USB port and you run the gctrl.pde Processing sketch, you should see the correct prompt show up in the Processing window, something like
Type $ to dump current settings”
I can’t remember the message exactly, but that’s the gist. If you see that, Processing is talking to your Uno just fine and you should be able to jog the axes around and stream a gcode.
One last note: for some reason the sketch takes a moment to register a keypress. So if you for instance type a “g” to get the dialogue window to choose a gcode to stream, don’t just tap it; hold it down for a second. Otherwise the window will pop up, but not populate, and the whole thing will hang.
That’s it. If anyone reads this and something isn’t clear (or if it happened to save your butt) please let me know.
On Saturday I attempted to mill out a parallel-port connector board for a different set of Mantis electronics:
I used cad-opt.py because it made the FabI/O boards so much faster. Alas, the final product looked awful, which is too bad since it’s actually a very “coarse” board- few traces, and they’re all pretty wide.
On Tuesday I did enough of another one with cad.py to determine that it was fine; I had to stop because of time but it got all the traces outlined and they were clean and precise. So, I’ve got to finish one with cad.py and then try another with cad-opt.py to see if it really is a problem with the Gcode or if it was just a fluke.
In related news, cad.py is making me NUTS when I try to use it for drilling. It’s something about how Python is using floating-point numbers, I think. It’s my own fault for using (and clinging to) an obsolete program, I guess.
D. at Splatspace says that Fritzing is a good pcb design alternative to Eagle, so I need to look at that and hopefully we can work out something to get our own boards to gcode without using cad.py.
But some of these online designs are still only available as .pngs, plus I have other graphics applications for the mill, so I still need to work out an alternative for those.
I printed out Ruttmeister’s stepper motor adapter that I referenced in the last post. It seems to work great so far- I used Big Red’s extruder stepper board to control it just to check the movement, and it seems smooth.
Last night I disassembled Baby Blue’s hot end as well and tightened the various components. I added teflon tape to the stainless steel tube’s threads because I think that’s where the minor PLA leak was coming from. It’s all back together now except for insulation (all of the insulation was destroyed in disassembling it because that minor leak had soaked it all with melted PLA.)
Work remaining: make the jumpers for the 4th stepper board, wire it up, and start messing with the firmware to get it to actually run.
Holiday shenanigans have kept me from doing much lately, but I had a few successes.
First of all, I fixed the Z-axis problem I was having with my second Makerbot (“Baby Blue”) – it just needed a new belt.
Long ago when I was first building one, the standard belt was not available, so I subbed in a heat-resistant model. It turned out to be substantially thicker and less flexible than the original neoprene one, which has caused no end of problems.
So, I finally bought a proper replacement, and that solved the problem.
I’m continuing to print parts for a low-rider XY axis assembly, and after that I’ll print a Z-rider. More urgently, I have identified upgrade parts for Baby Blue’s extruder- I’ll be using Ruttmeister’s stepper adapter for the MK5 extruder. That way I can keep the MK5 drive system and hot end, which has been working quite well for me, while upgrading to a stepper driver. I have a spare stepper motor and driver board, so once I get these parts printed I should be good to go.
On the Mantis front, I bought a single-point 90 degree diamond bit from Dremel. The first one was defective and failed instantly- the diamond just popped out. Dremel replaced it for free, and the new one arrived Friday.
It works great! Spinning the bit at high RPMs makes it engrave just as well as a vibratory engraver, apparently. A Z height of -0.005 gave very fine lines on glass; I think I can probably back that off to -0.003 or 2.
When attempting to engrave acrylic with carbide bits, a higher feed rate did result in less melting, as did more aggressively toothed bits. This is to be expected. I still haven’t found a proper feed rate to fix the problem entirely. It may be that a pot. wired into the spindle motor could decrease the spindle speed enough to help as well.
The problem of course is that this isn’t a true spindle so it won’t maintain its torque at lower speeds. Does not hurt to try, though; I really don’t know how much torque is needed to engrave acrylic.
Pirate Box- no movement lately.