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.