A new Arduino, and a major success!

Rather than spending unknown amounts of time trying to shave bits off code I don't know, I eventually got a more modern Arduino, an Arduino UNO R3. It comes in a card-deck box:) More importantly, it has 32K memory, enough to run Teacup comfortably. I was able to upload the Teacup firmware I had configured last time. Using ReplicatorG with the Teacup pre-programmed machine, I could connect and at least talk to it, even if it thought I was homing the wrong way and obviously miscalculated the duration of a simple print.

Some updates to the firmware:

• Makefile - changed to MCU_TARGET=atmega328p (though mine is atmega328, according to the specs)
• config.monster.h - tried changing to USB_SERIAL, but then it failed to upload. Setting it back didn't help. Setting the MCU_TARGET back to atmega168 didn't help either, suddenly I can't upload the firmware any more:(

After scanning this thread I realized it was ReplicatorG interfering. When that was off, it works nicely with MCU_TARGET=atmega328 and with USB_SERIAL.

I made a new ReplicatorG machine in reprap.xml with these settings:




Monster w/Teacup (115200 Baud)












   false
   true
   false
   
   0
   true
   115200







At first, I have changed only the parts I know of (size, speed, heat options) but nothing in the driver. Since this one seems to talk serial, I switched the config.monster.h back to serial and re-uploaded.

Using ReplicatorG, I can connect to the Arduino. Disconnecting doesn't seem to work, just puts it in a funny state. But I can use the control panel to move the motors! X and Y moves nicely, except that X occasionally stalls for no apparent reason. Maybe I need to adjust the potentiometer. Z doesn't move at all, nor does the extruder. Heat is totally whacky, says it's 2240ºC. And the extruder driver still overheats. Maybe I should use the little Fritzing one I got at Make Munich instead.

Update: The Z motor only doesn't move because I tried to move it upwards first. It doesn't allow me going below zero. That may make it tricky to use the controller to move them back. Not even uploading a config that has all dirs reversed changes that.

Fixed the X motor problems (apparently) by adjusting the potentiometer to give a little more power.

The temperature reading is perplexing. Running the bare-bones measurement shows 0 for a while, then it goes to 3840, almost as if... it's digital!  No, not even that, it doesn't drop again.

Reading through the temp.h file of the Teacup firmware, I notice that the thermistor analog read is done with the temp sensor number rather than the pin number. Changing to use analog pin 0. Didn't help.

Setting the Teacup min less than 0 allowed me to use the controller to move negatively, getting to a proper zero position. Also changed max speed and experimented with what the motors will take. Adjusting the potentiometer allowed me to find a fast setting that still doesn't overheat on idle. Got the X axis to 400 mm/s. Y axis potentiometer is harder to access. Z axis doesn't have to be all that fast. Extruder axis (once it works) will need a setting that depends on how fast I need the extrusion to be.

Next time: Find out what's up with the thermistor, why the PWM doesn't react to anything I do, and why the extruder stepper motor doesn't react either. I expect the latter is because it expects the target temperature to be set first, but maybe not.

All in all: "This was a triumph./I making a note here:/huge success!"

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.

Calibrating, and a new stepper motor library

Using the info from TriffidHunter and RichRap, I calibrated as follows:

X and Y stages: 1.5mm pitch (M10 threaded rod). 1.8º/step => 200 steps = 1 rotation. Total 200 / 1.5 = 136 steps per millimeter. Measured by running 13600 steps: 1 cm. Why am I off by an order of magnitude?

With a 10ms delay between each step, I get ~13mm. The Arduino stepper motor library appears to ignore all but the sign of the "number of steps" parameter.

It appears that what the library calls a "step" is just 1 of the 4 steps involved in a "real" step, as can be told by the two diodes turning on and off. But that doesn't explain why my 200-steps loop only does ~50 steps.

Odd. When I do 1 step at a time with a 1 second delay, it only changes LEDs every 4 seconds. With 4 steps per 1s delay, they change every second.

There is something I don't get about driving a stepper motor with this library, so I do the programmer thing: Use an abstraction interface. The AccelStepper library is not only much more advanced, it is also (gasp!) documented. Here is a minimal test program:



#include

AccelStepper stepper(AccelStepper::DRIVER, 4, 5);

void setup()
{  
   stepper.setMaxSpeed(1000);
   stepper.setSpeed(1000);
}

void loop()
{  
   stepper.runSpeed();
}

This just runs the motor at full speed (the library is currently limited to a max speed of 1000 since anything higher would use microseconds, and the author is concerned that those overflow after a matter of days). I will start with this because I don't need speed for calibration. The library also supports going to specific positions, which is nice. It gives a much better run, fast and even with little effort. I'm not sure that the acceleration part is really necessary here, but the basic example works smoothly, so I'll go with this, reading more documentation at home.

Quick test: Since the stepper motor driver is set to half-step, and the motor has 1.8º steps, 400 steps should be one rotation. And it is! Then 4000 steps should be 15mm... it is! Quite precisely. Y stage does the same. Z stage - I had some problems lifting the entire extruder + holder - but it, too, is precise. Beautiful.

Getting late now, so I'll calibrate the extruder motor and heater later. It seems the temperature "calibration" is just finding out what measurements melts the plastic, accurate measurements are apparently tricky, and there are variations in the thermistor.

Next time: extrusion calibration and tightening the Z stage holder: Just found that I can store the entire thing in its little corner without necessarily tilting the Z stage.

Make Munich report

Make Munich 2013!

The first maker faire in Southern Germany (or possibly in all of Germany) was Make Munich this weekend. I went Saturday, because I also wanted to start the sword fighting season this weekend. There was a lovely mix of 3-D printers, electronics kits, vintage computers, upcycling jewelry, guerilla gardening, textile hacks, and more. A very dangerous place to go, but I managed to not buy stuff for more than €80 - a POV spoke kit for my bike, some cute pieces for Mickey, and a tiny stepper motor driver. I was quite tempted by the LED strips, though, as you will see below.

The big star of the show was the 3-D printer, of course. It was everywhere, in all manner of styles. Fabbster was there with about 10 of their modular systems, which look very simple and useful. FabLab had a one-cubic-meter one that even I hadn't seen before, unfortunately new enough that it didn't work yet. The group shown on the left had a more-printed-than-usual RepRap, the little yellow one in the front.

There were also a number of companies who would print your things for you, shouldn't you not want to handle the care and feeding of new, mostly-experimental systems. What surprised me most was the number of different materials you can get prints in. On the right, i-Materialize's "Periodic Table of Materials", including steel, titanium and gold! These are essentially made by having a powder of the material, heating it to just below its melting point (so don't try this at home, kids!), then shining a fairly weak (couple of watts) laser at it to fuse a bit together. The amount of detail on these was quite amazing, one figure had a magnifying glass in front of it. On the lower right you can see a resin print in clear resin, very lovely surface, and the things in front are MineCraft-style models:)

Of course the main local maker space, FabLab München, was represented with a goodly chunk of the upstairs section. They showed off a lot of the things they'd done over time, but didn't bring that many 3-D printers (which was fine, since there were so many already). They brought Bazinga!, the 30W laser cutter they were lucky enough to get donated, and were able to let people use it. They also had a number of kid-oriented activities, which was quite cool.

Several small companies (or not-quite-yet-companies) were showing their products, from modular rail systems over kits to useful programs and services. One company was showing off their 3-D finishing product, which essentially ensured that a model was a proper volume by turning surface-defined models into volume-defined ones. A pretty specialized system, but from personal experience, I can say it's useful. Another company, Fritzing, provided low-cost PCB production, and demoed their program for PCB design. I quite like it, essentially you can work on the same model in a virtual bread-board, a logical diagram, and a PCB layout, and the other ones get updated appropriately. While still in beta, it looked quite useful, and their prints were just beautiful, lacquered white with black print.

There were many more things, like the local ham radio group, retro-computing groups, a Pac-Man board game, and what-not. The audience was extremely varied, with lots of families with little kids (some less-than-10-year-olds and their dads were soldering together). I managed to get interviewed twice, once by Welt am Sontag, once by a camera crew from I-know-not-where (if anyone sees it, let me know; I did it in my best German, which is not that good).

More pictures and descriptions on the photo album. Sorry about the image quality, I wanted to have my hands free to play with things, so I didn't bring my SLR.