Tweaking the G-Code

One of the things I'm not crazy about on the MM2 is the time it takes for the heated bed to get to 70c (which is the temp we're using to print PLA on).  Even at 24V the larger bed takes quite some time to get up there.

I also suffer from a rather short attention span (as many people will testify too).  I'd get my G code all ready, get it loaded into Repetier and manually turn on the bed and extruder.  Invariably I'd get bored waiting and would wander off and get distracted doing something else, only to return 20 mins later to a pool of PLA that had dripped from the extruder.

I'd been looking at various G-Codes and noticed that there is a code that waits for the bed to reach a target temperature.

The M190 command will wait for the bed to get to your target temperature, while M109 will wait for the extruder to get to the target temperature.

With this, I added the following to the Printer Settings/Custom G-code in Slic3r:

M190 S[first_layer_bed_temperature];
M104 S[first_layer_temperature];
G28 X0 Y0;
M109 S[first_layer_temperature];

The first command will turn on the heated bed and wait for it to get to the first layer temperature you've set, while the second command just starts the extruder heating.  I then home X & Y and when that's done I wait for the extruder to reach the first layer temperature with the fourth command.

Now I just hit 'Run' and the printer will do the rest.  No more drippy PLA for me!

Note: You can swap the order of the M104 & M190 commands, the extruder will start to heat up and then the printer will wait on the bed to heat up.  This will reduce the time spent waiting, but you will also have the extruder at temp for most of the time the bed is heating up.  This will probably reduce the amount of PLA in the extruder once the print starts.  Just something to be aware off.

Installing a bootloader on a Sanguinololu Part 2

I've finally got to the bottom of the issues I was having, and my the FUSE settings on the ATMega1284p where different from the settings I was seeing on a variety of other sources.  I also installed a bootloader that works correctly with the 1284p.

See my first entry on how to setup an Arduino (Mega2560 in my case) as an ISP.  That is still valid.  Do not buy the Sparkfun ISP Pocket Programmer - it cannot handle a chip with more than 64K flash, so it won't work with the 1284p (the bootloader sits in the upper 64k) -- I learnt that when I tried to use it.

I ended up grabbing the bootloader from https://github.com/jmgiacalone/sanguino1284p.  I'm running with the Arduino IDE 1.05 and that bootloader seems to work with it.

I did end up modifying the FUSE settings to match what was on the old ATMega1284p -- in my case, the Sanguinolou board has a 16Mhz crystal on it, and not a Ceramic Resonator.  That's why my FUSE settings are different.  You can see from the pictures below the differences:

Top view of my board - no resonator...

Underside of my board - metal Xtal Oscilator

From reprap.org - the blue 3 wired part is a ceramic resonator

I ended up with the following values for the fuses:

High Fuse: 0xDC, Low Fuse: 0xD7, Extended Fuse: 0xFD

I modified my boards.txt file and added an entry specifically for my board with the crystal oscillator.


atmega1284.name=Sanguinololu W/ ATmega1284p 16mhz

atmega1284.upload.protocol=stk500v1
atmega1284.upload.maximum_size=129024
atmega1284.upload.speed=57600

atmega1284.bootloader.low_fuses=0xd7
atmega1284.bootloader.high_fuses=0xdc
atmega1284.bootloader.extended_fuses=0xfd
atmega1284.bootloader.path=standard
atmega1284.bootloader.file=ATmegaBOOT_1284P.hex
atmega1284.bootloader.unlock_bits=0x3F
atmega1284.bootloader.lock_bits=0x0F

atmega1284.build.mcu=atmega1284p
atmega1284.build.f_cpu=16000000L
atmega1284.build.core=arduino

I found this FUSE calculator page useful in understanding what the different bit combinations actually mean -- http://www.engbedded.com/fusecalc/  -- the one thing I might go back and work on is the boot time -- right now, the board takes a long time to connect to Repetier Host, and I think that's down to the timeout delays in the Boot Loader I'm using. However, I've other things that need sorting first.

Nylon

Colin has been flooding the blog with a lot of technical posts lately, so I thought I'd jump in with a puff piece.

I finally got around to printing some nylon again. The last time I tried printing with nylon there was a lot of steam and I couldn't get anything to stick to the bed. The nylon filament sucks up a lot of moisture from the air. (Not implying that was the main reason it wouldn't stick but I'm sure it didn't help.) It's been sitting forgotten in a zip lock bag with desiccant for the past few months which probably helped dry it out a bit. I also put down a strip of blue painters tape across the bed. Ended up printing at 235C. Success!

Here's the Stanford Bunny http://www.thingiverse.com/thing:3731 shrunk down to 50mm height.

Installing a bootloader on a Sanguinololu (see part 2 for the completion)

While most of the story is described below, part 2 contains the final resolution.

I received my replacement ATMega1284P's from Mouser just before the holiday weekend.  At the same time, I ordered the replacement chips, I ordered a nifty chip puller from Amazon -- it was pretty cheap and with prime, arrived on the same day as the replacement chips.

With everything in hand, I figured this would be a pretty straightforward fix -- boy was I wrong.

I removed the old ATMega from the Sanguinololu board with the chip puller.  I then did something I don't normally do - I thought ahead - and added a sticker to the top of the chip that came out of the socket, that way I can tell it apart from the two new ones... smart eh?

I dropped one of the new ATMegas into the socket and made sure it was correctly seated.  Job done, right, just flash the latest Marlin and off to the races.  Nope - the Arduino IDE would not connect to the Sanguinololu board.  The USB device showed up, but it would never connect.  A little digging on the internet and I discovered that a factory new ATMega1284P does not have a 'boot loader' already installed.  With out the bootloader it's not possible for the Arduino IDE to communicate with the chip over USB.

In order to install a bootloader, I needed to program the chip with a ISP (In System Programming) programmer.  From what I could see, I could buy something that would do the job for me, or I could use another Arduino board to act as an ISP device.  I chose the latter option.

To make this work, connect your Arduino board to your computer and from the Arduino IDE, select File | Examples | ArduinoISP -- this will load a sketch that you can send to your arduino board and let it behave as an ISP device.

From within the loaded sketch, you can see which pins will be used for which purpose.  I was using a Mega2560 board, so the SPI pins where 50,51,52, & 53.


Using jumpers, I connected the Mega2560 directly to the small expansion header labeled SPI/ISP on the Sanguinololu board as indicated below:



The 3 SPI pins and the Reset pin all connect to sockets on the large double rowed digital socket on the ATMega.  I used the ground connection at the end of this connector, along with the 5V pin from the power socket.

I also wired 3 LEDs (as suggested by the Sketch) through a common resistor to ground, with the anode of each LED connected to a single pin on the PWM socket block (7,8, and 9).  The LED connected to pin 9 will pulse off and on when the ISP sketch is running on the ATMega.

Also, when the ATMega resets, each LED will blink quickly in series before settling to the heartbeat pulse.  With this you can see when the ATMega resets, as the 3 LEDs will quickly blink shortly after reset - this turned out to be important.



With everything wired up (and the Sanguinololu disconnected from everything but the Arduino ISP) I had my heart pulse LED, my power LEDs on the ATMega and the power LED on the Sanguinololu all lit up.

Now with the Arduino IDE, I selected the board type as Sanguino w/ATmega1284P 16Mhz and kept the serial port the same as previously.

This is an important note - at this time, you are selecting the type of chip you are installing the bootloader on to, but the serial port is the port the Arduino ISP is connected to.  Only the Arduino is connected to the computer.

<At this point, I suggest you read the section below on modifying your boards.txt file, and don't plough on like I did, only to discover it doesn't work exactly as you want it to>

Now from the Tools menu of the Arduino IDE select Tools | Programmer | Arduino as ISP.

With that done, select the Burn Bootloader from the Tools menu.  This will start burning the selected bootloader onto the ATmega1284p that's connected via SPI to the Arduino board.

It will take a few minutes and you'll see the LEDs you connected to the Arduino flash as the sketch and Arduino IDE do their work.

When complete, the Arduino IDE will indicate success and the heartbeat LED will be pulsing again.  At this point the ATmega1284p will now have the new bootloader installed and you'll be able to upload the printer firmware.

This is where I ran into problems, and hopefully if you're reading this then you can avoid the extra hours of headache I had trying to figure this out...

So it turns out that the default bootloader settings include default FUSE settings.  I've learnt that in micro-controller speak, FUSEs are not what you'd find protecting your toaster oven from setting fire to your kitchen, and that these FUSEs can be 'blown' and then un-blown.  In fact, FUSE is pretty much a crappy name for these things -- if anything they're just a few extra bytes of EEPROM or NVRAM, basically you use them to configure the chip with the ISP.

Furthermore, the ATMega1284P maps the JTAG port onto the GPIO C port when JTAG is enabled, and the C port standard GPIO functions are disabled.  The default FUSE settings leave the JTAG enabled, so your printer firmware will not work.  The axis endstops and x-axis direction pin all share space with the JTAG.  In order to make this work for a printer configuration, you'll need to update your FUSE settings.

The easiest way to do this is to reconnect everything as before so the Arduino is setup to act as a ISP device for the ATMega in the Sanguino board.  However, before programming the device, you should modify boards.txt and update the FUSE settings as follows:

• low fuse = 0xD7
• high fuse = 0xDC
• extended fuse = 0xFD

You'll find boards.txt in the Sanguino folder under hardware.  Go to the bottom of the file and change:

atmega1284.bootloader.high_fuses=0x9A to atmega1284.bootloader.high_fuses=0xDC

This will set bit 6 of the high fuse, which will in turn disable the JTAG function and return port C to your control.

Initially, I investigated the FUSE settings using AVRdude, a command line program that lets you talk to the Arduino and see what's going on under the hood.  For some reason, I had a hard time getting this to work with my Mac, but it worked fine on Windows 7, though this required stopping the auto-reset.

On an Arduino, when you connect to the USB serial port, the device will normally reset.  This was causing the AVRdude problems connecting to the ATMega.  I solved this by connecting a 10uF capacitor between ground and reset (pin 3 on the power connector socket).  This basically acted as a low pass filter stopping the reset pin from going low.

Now when I connected with AVRdude, the ATMega didn't reset and things seemed to work.  One other magic ingredient was the inclusion of '-b 19200' as a parameter.  This allowed AVRdude to actually talk with the Arduino using the serial speed that was set in the ArduinoISP sketch.

I was able to set the FUSE with the following command:


avrdude -p m1284p -c arduino -P com6 -v -b 19200 -U hfuse:w:0xDC:m

-p for the part we're trying to program (a ATMega1284p in this case)
-c for the ISP programmer (an Arduino here)
-P for the com port
-v for verbose mode, so you can see what's going on
-b to set the baud rate (really important!!!)
-U is the actual write command to update the high-fuse.

If you want to test the connection from AVRdude to your target chip, you can leave off the -U and add a -n which will just give you info on the connection but not perform any writes.

Anyway, after sending that command I got the following output:

While this worked, and I was able to get the printer firmware up and running, I'd recommend editing the boards.txt file and setting the hfuse value before the initial flash.

Some photos of the wiring I ended up with:

LEDs, Sanguino & Mega2560

Sanguinololu ISP connection

  

Mega2560 ISP connection

Mega2560 Reset Circuit

Close up of Mega Power connection (white line is reset)

Update:  When I actually tried the board in my printer, it didn't work as expected - Repetier Host was getting a lot of comms errors - I tried messing with the baud rate, and no luck.  Did some more searching and discovered that the FUSE settings I had didn't take the crystal clock into account correctly.  I decided to re-plug in the old working ATMega1284P chip (the one with the dodgy X/Y endstops) and read the FUSE settings from that.  Here's what I got:

As you can see, this is different from what I'd set -- similar, but not the same.  Looking at these bits and the ATmega1284p data sheet, I see the following changes:

For the low fuse: I had a 0xFF and it should be a 0xD7.   This means bits 5 & 3 should be reset. Bit 5 along with bit 4 control the startup time (SUT1,SUT0), while bits 3..0 (CKSEL3...CKSEL0) control the clock source.  In this case a startup-time of 01B with a clock select of 0111B configures the ATMega for a full swing crystal oscillator (which is what is on the sanguinololu board).

For the high fuse: I had 0xDA and it was 0xDC.  In this case, bit 2 is set and bit 1 is reset.  This controls the Boot Size, and while I didn't notice anything different I set it to the previous setting just to be careful.

For the extended fuse: I had 0xFF and it was 0xFD, basically bit should be reset.  This controls the brown out detection level and I did notice a warning when connecting to the Sanguinolou that there had been a brown out reset, which I hadn't seen before.

So to set these new FUSE settings, I could have edited the boards.txt and done it through the Arudino IDE as before, or I could use the following command for AVRdude:


avrdude -p m1284p -c arduino -P com6 -v -b 19200 -U hfuse:w:0xDC:m -U lfuse:w:0xD7:m -U efuse:w:0xFD:m


With this done, I reconnected the sanguinololu up to Repetier host and... (see part 2)

MXL Belts & Pulleys

The printer has been using T5 belts with printed pulleys, and they've been working pretty well.  However, we decided to investigate some other belt/pulley options.

The folks at OpenBuilds sell a belt & pulley combo at a pretty reasonable price, so we ordered some up and tried them out.

MXL belt & pulley. The belt pitch is 2.03mm (actually 0.080 inch)

The kit they sell uses an MXL belt, and obviously the pulley to match.  MXL has a belt pitch of 2.03mm, which is the distance between the center of the teeth.  The pulley has 20 teeth, so one revolution of the pulley will move the belt 40.6mm (not 46mm as I had calculated due to my inability to enter 2.03 correctly into a calculator, but enough about that).

We use a stepper motor with a 1.8 degree step angle, so that's 200 steps for one revolution.  The stepper driver is set to 1/16th micro-steps, which means on our setup, 3,200 steps will move the motor one complete revolution.

The firmware we use (Marlin) has a configuration entry for steps per unit:

DEFAULT_AXIS_STEPS_PER_UNIT = {64,64,2560,470};

This was setup for the T5 belt & 10 tooth pulley.  With these, we have 50mm per revolution, and at 3200 steps per revolution, this gives 64 steps per mm.  (3200 / 50 = 64).

The MM2 uses the GT2 belt & pulley.  Here you have a 2mm belt pitch and a 20 tooth pulley, so the steps per mm works out at 80. (3200 / 40 = 80).

With the MXL, we need 78.81773399014778 steps per mm. (3200/40.6 = 78.81773399014778).

I plugged in the new number as the 2nd value (they're in x,y,z,e order) and checked out the results by printing a couple of 20mm x 20mm boxes as vase.

I measured them with our trusty micrometer, and they both measured out to be 19.8 x 19.8.  Slightly smaller than the desired 20 x 20, but not enough to worry about.

We may try some GT2 belts & pulleys and replace the MXL's with those.  That way we don't have to worry about rounding errors, but I don't think the error is that significant anyway.

Update:  After writing this, I went back and checked the values using 2.034 for the pitch (this is what various websites give as the MXL metric pitch).  The value I used inside Marlin was changed to 78.74015748031496.  I ran a couple of test cube prints, and there was no apparent difference in the Y dimensions of the prints, so obviously a pretty small adjustment.  I'd imagine on a larger print it might be more of an issue, but I still couldn't see it being a deal breaker.

Sanguinololu troubles...

We're driving the new printer build with a Sanguinololu board we got in another 3D printer kit (a MM1.5+).  It's not the zippiest board, but it's pretty simple to use and we had it spare.

While doing some test prints, the PLA that was feeding into the extruder decided to grab a bunch of wires and twist them up into itself (my own fault for leaving the PLA coil on the desk).  Of course, I didn't notice this happening until the wires for the X-Stop got pulled off the micro-switch and the printer stopped.

Not only did this ruin the test print, but it seems to have fried the ATMega 644p too.  No matter what I did with the firmware, the endstops for X & Y would not trigger (or un-trigger).

 

You can see from the photo of the un-populated board, the outer pins are Ground and Sig.  In normal operation, you should see about 5V between these pins, as the Signal line is being pulled up by an internal resistor.  On ours, I was seeing about 2V.  Not right.

Also, with the power off, I measured the resistance between ground and the signal line -- it read 20ohms.  It should be off the scale, i.e. not connected.  Also not good.  So the pulled wire had fried the input pins of both the X and Y end stops.  The Z end stop, which was not connected, behaves as it's supposed to.  It read 5V when being pulled high, and had an open circuit to ground when the board was powered off.  Hooking up a microswitch to that gave the expected results.

We've ordered a new ATMega to replace the existing one - hopefully it comes with the right bootloader and I can just plug it in and flash it with the correct firmware -- fingers crossed!

Pillow block bearing...

We swapped out the LM8's that were on our x-carriage for some pretty cool pillow block bearings we got from Igus.  They're significantly lighter than the metal bearings we'd been using and don't require any lubrication.

They also run quieter and seem to be smoother, both of which can't be bad.


I'm printing a hollow Spocktopus (despite seeing the awful new ST:ID movie I still like that model) to see how it works on a larger complex print.  My previous test boxes all worked out pretty well.









I'll update this with a full pic of the finished print later.

New Printer!

We've been working on a new printer layout for the past few weeks, and now that we have our direct drive extruder working, along with a z-axis that we're happy with we tried printing something more complex than a simple box.

It's a small Spoctopus, printed @ 0.2mm layer height with 25% infill.  We think it looks pretty good!

1st real print out of our new printer!

More PID tweaking

So after my episodes with PID auto-tune yesterday, someone sent me a link to a presentation on PIDs and what those Kp, Ki, & Kd values actually do.  You can read the presentation yourself here: http://wwwdsa.uqac.ca/~rbeguena/Systemes_Asservis/PID.pdf.  It will give you a decent grasp of what impact the numbers have on the temperature graph.

TLDR; version:  From the summary:

• Increase Kp to decrease the rise time.
• Increase Kd to reduce the overshoot and settling time.
• Increase Ki to eliminate the steady-state error

As our setup was still having serious overshoot, a look at the auto-tune results told me by Kd was far too low.  I had used the following values:

Kp = 10.75, Ki = 0.56, and Kd = 51.60

 I went in and took Kd back to the default of 114.  This is the resultant heating curve from that:

Kd = 114, target temp 180

As you can see, the overshoot was much better than before and it settled really well.  I then tried again with Kd set to 200.

Kd = 200, target temp 180

The results were actually not as good as before - so now I decided to tweak the Kp setting, by reducing it I should increase the time the heater takes to get to target temp, which I hoped would reduce the overshoot.  It had been set to 10.75, I decided to start by halving it to 5.5.

Kd = 200, Ki = 5.5, temp = 180

It was pretty disappointing to see no real change to the curve.  Time for drastic changes!  I tried various settings of Kd (even as high as 600) and dropped Ki down to 2.0, but nothing really made the curve better than I had.  So I started exploring the code in Temperature.cpp some more.  Turns out the firmware setting called "PID_FUNCTIONAL_RANGE" was pretty important.  Until the actual temperature and the target temperature get within this range, the PID is disabled.  This meant the heater was on full until the temp got with 10c of the target temp and tried to take control, but it was too late,  I'd already seen everything!

I set the PID_FUNCTIONAL_RANGE to 30 (default was 10) and got the following result:

PID_FUNCTIONAL_RANGE = 30

Much better! Now hopefully with some more minor adjustments I can reduce the settle errors, but that will have to wait until another time.  Let's see if this new setup can actually print something remotely resembling the 3D shape I send to it...

 



 

New Heater for summer!

The MM2.0 uses a nifty heater cartridge instead of the old standard resistor to provide heat to the hot end.  We really liked the ease of connection of the cartridge, not to mention that it's been designed to heat things up, while a resistor is really designed to provide resistance and heat generation is a byproduct of it's primary function.

We did some hunting around and found a supplier of heater cartridges that work with a 12V supply.  The cartridge is about 3.5 ohms, which means it eats 41W... this is more than the old resistor heater (6 ohms) and so it heats up much faster.

The heater element is connected the part with the red wires attached...

With the previous firmware settings we were having a problem with the heater overshooting the target temperature by quite a lot (>40c) which could be a real problem if we want to use it to print Nylon or ABS.  We could easily exceed the maximum hotend temperature.

We tried to use the auto-tune settings built into Marlin by sending a M303 S200.  This tells the printer to measure the PID performance as it get to 200c.  However, because of the overshooting temperature the auto-tune would fail as the temperature got too high compared to the target.

A little digging in the temperature.cpp file found the following lines:

  

There is a line that used to say if (input>(temp+20))... so in our case, once we went above 220, the auto-tune would fail.  I ended up modifying this to +40 and then set the target temperature to 150, with: M303 S150.

This worked, and auto-tune was able to complete and I then used the outputed numbers in the firmware.  I then re-ran the auto-tune, this time with the target temperature set for 180.  Took the new PID values and plugged those into the firmware.

 We're still not happy with the results, but it's better than it was, but still overshoots the target temperature when the hotend starts up, just not as much as before.

Startup Temp graph for the Hotend after auto-tune

Temp graph after the hot-end has been running for a bit

The Fleet is in!

A friend of ours asked if we could print some battle ships his daughter needed for a diorama she was making as part of a school project - I said sure!  Then went hunting for models.  There are some great models in the Sketchup warehouse, but they are all crazy detailed and not printable.

Searching around Thingiverse turned up this model:

http://www.thingiverse.com/thing:26635

It looked like it would work and a few folks had printed it already, so that was selected.  In my opinion the hull is much too tall for the ship (maybe it was done this way so it would float).  I loaded the model in Blender and reduced the height.

Loaded it up in Kisslicer and produced the G code file that let me print these:

The left image was printed on the MM1.5+ and the right hand one was 3 ships at once on the MM2.0.


Below is a video showing some of the ships being printed -- this is from the MM2.0 with faster acceleration than we'd previously used.

Printing with ABS

After getting comfortable printing PLA, we decided to buy some ABS and nylon.  I opened up the ABS roll today and after printing a few test cubes, I loaded up a Spocktapus. Why Spocktapus again? First, I've printed it enough times to know what it's supposed to look like and what it's not supposed to look like. Second, it will annoy Colin (they're like Tribbles around here).

This was printed at 0.25mm layer height at 230C. It curls a lot more than PLA, which already curls too much and the smell is a lot stronger than PLA. Here's a video and final shot.

Not the best print ever, but I just wanted to crank this out quickly.

More worm work

My curiosity with worm gears continues...

The gears I printed yesterday were too small to make workable, and I've since modified the OpenSCAD file to give me better sized parts.

I need to make a mount that will hold the NEMA17 and the 8mm rod and a couple of bearings along with the gears.  This is what I have right now:

Like I said yesterday, OpenSCAD is a wonderful program (with limitations) and I'll use it to design and build the mount.  Hopefully it'll be done soon and I can see the worm drive in action!

Worms, gears and OpenSCAD - Oh My!

I've been wanting to play around with worm gears and stepper motors for awhile, and today I had some time to experiment.  I downloaded this http://www.thingiverse.com/thing:8821 from Thingiverse today and after a bit of work, got it rendering correctly with OpenSCAD (http://en.wikibooks.org/wiki/OpenSCAD_User_Manual).

Initially I printed the gears the same size they were in the original file and was quite surprised by how well they turned out:

The fitted pretty well together and even turned as you'd expect.  The actual worm gear had some underhanging PLA under it's flanges, but it was better than I thought I'd get.

I then decided to reduce the size of them and try it again, this time with something I'd actually use on a stepper motor:

They came out beautifully - and don't they look cool!

When I've got them in a jig and hooked up to a stepper I'll post updated pics & video.

Giant Lego Vader

A friend of mine had asked me to print him a Giant Lego Darth Vader he'd seen on Thingiverse -- http://www.thingiverse.com/thing:50300 and I said I'd be happy to.

After buying some cheap black PLA from an EBay supplier and failing to get the thing to stick to the bed or even itself, we ended up ordering a lot of Ultimachine Black PLA (which we use for a lot of things now) and it prints really well.

I finally got around to finishing the print and figured I'd share just before I dropped it in the mail.




These are all the parts laid out on the desk - they're all printed in black, except for the light saber blade which is done in a translucent red.










This is a close up of the body - you can see the layer height is pretty uniform and the body detail looks great, even close up.















His legs were also printed at a 0.25 layer height - I'm pretty happy with the results.
















Finally the light-saber handle - this is printed vertically with a built-in support.  Kisslicer seems to generate some broken paths when slicing this file (around the base) so I printed it with a grid to get it to stick better to the bed.  When the print is finished the grid and the extra support are cut away leaving a hole for the blade to be inserted.  I think this was printed at 0.2mm layer height.

Winterfell on the MendelMax 2

The MM2 has been up and running for a few weeks now so I printed another Winterfell model to test the print quality. The print took about 3 hours at 0.1mm layer height, 1 loop, no infill at around 35mm/s.

Fun with Git

I've started collaborating on a software project with a friend and we're using a remote Git repository to share the code -- anyway, after banjaxxing some of his changes he suggested I read this:

It's a pretty good book and free -- well worth the read if you intend to use Git (especially with more than one person, and even more especially if that other person is even grumpier than me).

Setting up a Sanguinololu on a Mac

The printer kit we'd bought previously came with a Sanguinololu board as the controller.  This is basically a RAMPS device that has been squashed into one board with all the functions for controlling a printer built in.   You can read more about it here: http://reprap.org/wiki/Sanguinololu.

It's a pretty nice bit of kit and is certainly easier to wire up than your standard RAMPS, but is limited to one extruder, no support for fans and we're using it with a relay to turn the heated bed off and on.  From what I've read I think this is just the original kit designer being cautious.

It's also missing the extra LEDs present on some RAMPS which let you know when the heaters are on, and the expansion header is different so it won't work with the standard LCD screens or SD readers.

Anyway, it's what we have and I got it nicely wired up to drive our new printer.  When we setup the first one, we did so with Windows and there are plenty of instructions on how to do that.  This time I wanted to use my Mac to do the initial flash and setup.  Figured I'd share my experiences.

Now, I'm not saying everything I did is correct -- but it worked for me and hopefully it might work for you too...

First, I installed the FTDI drivers for the serial USB chip that's on the board.  I downloaded this from http://www.ftdichip.com/Drivers/VCP.htm as directed by the standard Arduino website (http://arduino.cc/en/Guide/MacOSX).

On the FTDI page there are a few options - for me (OSX 10.8.3) I grabbed the 64-bit Intel file and mounted the disk image once it was downloaded.

From the disk image, I then installed the latest version which seemed to work fine for me.

Now I had the driver installed, I next downloaded the Arduino software for Mac OSX from http://arduino.cc/en/Main/Software.  The Mac version is provided as an App and you can just execute the downloaded file directly.  I did copy the App into my Applications folder so I could find it later, and it would show up on LaunchPad.

We're used to using Marlin, so I downloaded the latest version of the Marlin firmware from https://github.com/ErikZalm/Marlin -- just download the latest release, unzip it and put it some where you can find it later.

So, before you can build the firmware and send it to your Sanguinololu you need to modify the Arduino tools so they know about your board.  This is pretty straightforward, but neccessary.

From http://code.google.com/p/sanguino/downloads/list download the latest release and unzip it.  Now go back to the Arduino App you put in your Applications folder and right click it.  Select 'Show Package Contents' and left-click.

This will open a Finder window - double click the Contents folder, Resources folder, Java folder and finally the Hardware folder.

Grab the sanguino folder you downloaded and unzipped earlier (from http://code.google.com/p/sanguino/downloads/list) and drag it into the Hardware folder.  Your hardware folder should now look like:

With that done, you can close the Finder window and run the Arduino App from either LaunchPad or from your Applications folder.  If you installed the Sanguino folder correctly, you should see the Sanguino options at the bottom of the board list:

If the Sanguino options are not there, then you did something wrong -- maybe you already had the Arduino software running when you added the Sanguino extensions - if so quit it completely and re-launch it.

Now you can load the Marlin firmware and configure it for your Sanguinololu.  Navigate to the folder you had downloaded and extracted the firmware you downloaded earlier.  This should be a folder called Marlin-Marlin_v1. Open the folder, then open another folder called Marlin.  There should be a file called Marlin.pde.  That's the project file the Arduino software opens.  You can right click on the Marlin.pde and tell Finder to open it the Arduino App.  Once loaded, save the file and the Arduino App will let you know that the project extension has changed.  Go ahead and let it save a new copy of the project file as Marlin.ino.  In future, you can just double click Marlin.ino to load the project.

There are just a few more steps to get this working on the Mac -- you need to select your board type from the Tools/Board menu - I have a Sanguino ATmega1284p 16Mhz, so that's what I selected - you'll have to pick the entry to match your board.

You need to select the serial port that your board is on - this will only appear if the board is connected to the Mac and is powered up (USB power will do for this).  In my case I use the following setting:

dev/tty.usbserial-A104M4B

Yours might be different, but it should have tty. at the start of it. You can try compiling the firmware and sending it to your board to make sure the connection works, but before you do that, make sure you set the board type to 62 in configuration.h.

That's it - you now should have your Mac talking with your Sanguinololu and you can configure the firmware to suit your printer.

Enjoy!