Fritzing an Arduino shield

No, I haven't burned any components recently. But as previously mentioned, my Arduino daughterboard bird's-nest contraption failed to connect GND properly, and besides I realized I could use the analog I/O pins for opto endstop input. So having so liked the Fritzing boards and app at the Make Munich conference, I took this as an opportunity to try a more serious design with it.

The Fritzing app is available for Mac, Windows and Linux, and as a source tarball (it's a Qt app written in C++). It's an open-source program (under GNU GPL v3) developed by Interaction Design Lab Potsdam, and buying from them supports further development.

Its main view can be changed between a breadboard view, a schematic view, and a PCB view. Changes in one are reflected in the others, which is pretty sweet. I designed my board in the schematic view, where I totally didn't have to worry about placement, just doing the right connections. Then I changed to PCB view to place the components and do autorouting. It was pretty crappy at first, until I figured out that the GND pins should not be connected, but just be marked as GND fill seeds. By then, it made the design below with just three vias. 

4-stepper-motor shield, autorouted

Perusing the layout, I was able to not only remove two of the vias, but also make it prettier: 

4-stepper-motor shield, final layout (w/o copper)

Since this was a fairly simple diagram that just happened to have a lot of wires, I didn't use the breadboard view at all. Maybe next time. They also include a lot of elements to use on the boards, here I used an Arduino block to get the correct placement of the shield (including the slightly too small gap on the right side that Arduino is now stuck with).

I don't know how this program compares with other similar ones available, but I quite enjoyed this. It took me a couple of hours to get used to how it worked and design this board, not bad for an inexperienced designer. The boards can be ordered from within the program, and they make them with a very nice white coat and black silkscreen. I want to make more of them!

The Rainbow Machine and its firmware

For the lack of a daughterboard, I used some nice male-male wires that were in the electronics drawer in FabLab. That's one of the nice things about being in a makerspace, you're likely to find the pieces you didn't know you needed. I'll put them back as soon as I have my nice Fritzing board.

Plugging black to GND, green to Step, yellow to Dir, red to Opto-Endstop, blue to temperature, and orange to heat, I now have a nice rainbow-colored setup. It's a bird's nest of wires, so I hope I don't have to change too much around. Swapped out the poorly-soldered thermistor wires with more of the ready-made ones. I should get some of my own for at home.

Having tested all motors, heating, and temperature sensor, it's time to try some GCode interpretation. My options are ReplicatorG and a plain GCode interpreter like XXX.

ReplicatorG comes with a RepRap 3G driver, which is made for integrated motherboards that use a special communications protocal, and a serial pass-through driver which just sends the GCode. For the latter, I would need a GCode interpreter anyway. So, plain GCode interpreter for Arduino it is.

The obvious start is the interpreter on RepRap.org. Several links claim to have an updated version, but mostly lead to the GCode spec page. Ignore them.

But Ha! It's not so simple to get some GCode firmware, the RepRap solutions are with fancy interfaces and ... don't run on Mac. The most basic thing seems to be the 5D GCode on github, but even that requires C++ compilation. I could try the PronterfaceX Mac build, except my corp laptop's security restrictions forbid running this.

Back to RepRap. There's a simple-looking set of instructions that don't require extra software, but... it's been obsoleted and the file is now gone, superseded by Mendel. Only .hex files are left.

At long last! The teacup firmware appears to just need the Arduino software that I already have, and has a config that's just a bare Arduino with pin settings.

Made the following changes:

• Copied config.default.h to config.monster.h and made config.h an alias of that
• Made Makefile an alias of Makefile-AVR
• In Makefile-AVR:
• Changed MCU_TARGET to atmega168
• Changed TOOLCHAIN to /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/avr/bin/
• Might have problems with the -P flag since the USB port changes every time I plug it in.
• In config.monster.h:
• Changed STEPS_PER_M_{X,Y,Z} to 266666 (fits my previous measurement)
• Changed MAXIMUM_FEEDRATE_{X,Y,Z} to 226 after measuring max AccelSteperr speed
• Changed X_MAX to 140, Y_MAX to 80, Z_MAX to 55
• Changed to ACCELERATION_REPRAP
• Changed pinouts to: 
• X_STEP_PIN DI04, X_DIR_PIN DI05, X_MIN_PIN AI05
• Y_STEP_PIN DI06, Y_DIR_PIN DI07, Y_MIN_PIN AI04
• Z_STEP_PIN DI08, Z_DIR_PIN DI08, Z_MIN_PIN AI03
• E_STEP_PIN DI02, E_DIR_PIN DI03
• What is PS_ON_PIN for?
• Set pin in DEFINE_TEMP_SENSOR(extruder) to AI01
• Set DEFINE_HEATER(extruder) to port PB3 (==DI011) and pwm 0. 
• Copied ThermistorTable.single.h to ThermistorTable.monster.h and linked ThermistorTable.h to it.
• Updated ThermistorTable.monster.h to values that should correspond to my thermistor (100K plus 1K resistor to measure against. Command line: ./createTemperatureLookup.py --r0=100000 --t0=25 --r1=0 --r2=1000 --beta=4066 --max-adc=1023. The use of a smaller counterresistor appears to give me a better resolution at high temperatures.

Well guess what: MacOS "aliases" are not softlinks, they are binary chunks of what-not. Looks unhappy when the Arduino IDE tries to compile them. Replaced with softlinks.

Fails to compile usb_init(). I guess the ATMega168 isn't USB-enabled, even though the Arduino is. Changed to non-USB, and it compiles... but is too big: 17,512 bytes (of a 14,336 byte maximum). Posted to RepRap.org forum asking if this is fixable. Otherwise, I might (gasp!) have to get a larger Arduino.

TODO:

I will need to mount the opto endstops for the X and Y minimums properly, right now they're just using taped-on cardboard mounts.

So my maximum volume with this machine is 14x8x5.5 cm. Important to know when designing, and small compared to the 20x20x20 of the Ultimaker, not to mention the 40x40x40 of the big machine some of the other FabLabbers is making (it's outer dimensions are 65x65x75, while mine is 50x60x65 - my machine is wasting a lot of space). The big machine has 20% working volume, while mine has 0.3%! Of course, mine is a more open design, so it doesn't fill a whole cube, but still... I may have to go for the 60 times more volume next time.

Trouble in paradise

After last time's success with calibrating, I was hoping to get at least to primitive printing, but no luck. First I had to slice a piece off the plate under the extruder to not have it stuck on the edge of the Z frame. That's bother enough to take on and off. Then I made some little cardboard pieces to hold the roller skater bearing under the Z rod in place, but they still move back and forth. I think the rod is warped.

Most worrisomely, when I tested the Z stage with these new bearing holders, it moved erratically, as if it was skipping half the steps randomly. At first, I though it was a problem with the new holders, but it persisted when I took them out again. And when I tried on the Y stage. And the X stage. And when I unplugged everything but the X stage. And when I swapped out the power supply. And when I tried a different driver, or no driver.

Only when I took off my homemade shield and connected directly with little bits of wire did it work nicely again. While trying to set that slightly differently, I accidentally removed the ground connection, and it did the jerking skipping motion again. Aha! It's caused by not being properly connected to ground. As opposed to the simply switching rapidly back and forth in place, which is caused by wiring Step and Dir wrong. Luckily, FabLab has a set of small but high-quality wires compatible with the Arduino, instead of the random little bits I've been using that keep falling out. So until I get a properly constructed shield from Fritzing, I will have to make do with setting up wires every time I want to use it. So, in the end, I got very little progress today.

Calibration

Calibrated X, Y, Z, and Ex stages by running them back and forth while turning their potentiometers down until they stopped moving, then slightly up again. This cut down the idle heating quite a lot, to where it doesn't appear to be an issue anymore.

Trying to calibrate the extruder motor this way I had to heat the extruder first, which required reading the temperature sensor. Must remember to not set pinmode for analog pins! And that the yellow wire is for +5V, while the blue one is the actual measurement.

The extruder stepper motor driver behaves oddly -- where the other ones run nicely with the AccelStepper library, that one only moves when changing direction. Turns out I have swapped Dir and Step in the shield. Updated old pin description.

700 seems to work as a starting extruder temperature.

The Z stage wobbled back and forth when changing direction. Need to loosen the roller skate bearings.

The Ex stepper motor driver still gets too warm after a while of idling, but the Y driver is fine now. Hopefully the Ex driver will be ok since it'll be moving most of the time. Some stress-testing of the Ex driver alone shows that it can keep going for quite a while (minutes, at least) without getting overly warm.

After loosening the roller skate bearings, the Z stage wobbling persists. It is probably caused by the slight movement of the rod-bearing roller skate bearing, which should be held in place with a properly cut piece of cardboard. However, since the Z stage moves so slowly I will consider that a minor problem for now.

While checking if the extruder head really comes just down to the printing surface, it turns out that the back edge of the plate holding the extruder is still hitting the frame, holding the whole extruder mount about a centimeter above the surface. I guess I need to slice off a few millimeters more.

But apart from that, everything seems to work smoothly:) So for next time, I will look into the higher-level software and how to make it work for my parameters.