Slic3r and Makerbot Gcode

I have a makerbot hardware machine and am trying to use slic3r. I have noticed that when I set a bed temperature that the wrong M code is produced in the Gcode. Below is the beginning of my code. The second last line states M190 S70. But it should be M109. Can anyone else confirm this?

; generated by Slic3r 0.7.1 on 2012-03-27 at 19:39:15

; layer_height = .254
; perimeters = 2
; solid_layers = 2
; fill_density = .25
; nozzle_diameter = .254
; filament_diameter = 1.7526
; extrusion_multiplier = 1
; perimeter_speed = 30
; infill_speed = 35
; travel_speed = 45
; extrusion_width_ratio = 0
; scale = 1
; single wall width = 0.27mm

M190 S70 ; set bed temperature
M104 S225 ; set temperature

Looks like a simple typo. Open an issue at [github.com] or submit a fix yourself if you've got a Slic3r repo of your own.

This was fixed recently.

That's great. Being a total noob, how do I get the fix, or is there a file I can change myself?

The next thing is: I cannot build the gui as it fails building GLCanvas.
The build log is attached.
build.log
Thanks.

Edited 1 time(s). Last edit at 05/26/2015 12:23PM by Alistair.

If you put Slic3rs bed temperature variable into the start G-code (i.e. "first_layer_bed_temperature"), then Slic3r will not add its own command.

e.g. put into your start G-code the line

M109 S[first_layer_bed_temperature]

and Slic3r will omit the offending line in its own generated code. (Make sure you include the square brackets and underline characters).

The same applies to the hotend temperature. You can also use the variables in a line that has no effect to stop Slic3r setting any temperature (but not a comment line). That is useful to produce a g-code print file that can be printed in PLA or ABS etc - just set the temperatures manually before starting the print.

Dave

Thanks Dave.
The syntax for Linux seems to be a bit different as it adds the correct M number, but doesn't remove the old one, and does not put in the default value, but it's a start.
Just the other problem to figure out now...

Quote
Alistair
Thanks Dave.
The syntax for Linux seems to be a bit different as it adds the correct M number, but doesn't remove the old one, and does not put in the default value, but it's a start.
Just the other problem to figure out now...

If Slic3r has not substituted the correct figure for the variable in square brackets you put in the start G-code, check that the variable has the correct spelling and case, no spaces etc. OTOH another poster has suggested that this bug has been fixed, so maybe download the latest stable release of Slic3r and try with that.

Dave

Why are you guys concerned of an error present in an early version 3 years ago? (error generated by Slic3r 0.7.1 on 2012-03-27 at 19:39:15)

Why not just get the latest released version 1.2.7 here: Sli3r.org

Edited 3 time(s). Last edit at 05/27/2015 10:20AM by justcurious.

Quote
justcurious
Why are you guys concerned of an error present in an early version 3 years ago? (error generated by Slic3r 0.7.1 on 2012-03-27 at 19:39:15)

Why not just get the latest released version 1.2.7 here: Sli3r.org

One good reason for using older versions is that IME every version of Slic3r has behaved slightly differently and comes with a batch of new bugs to discover. Sometimes it is better to deal with the devil you know than the devil you don't ...

Before I got S3D, I used 2 different versions of Slic3r and also Cura so that I could choose the one that made the best code for the particular design I was slicing. One would sometimes fail to infill walls correctly, one would bridge better than others, one would print the perimeters in an inefficient order that increased print time considerably, one was best for designs that required lots of support structures etc.

Dave

I don't have a choice. I use replicator g400 and don't get a choice to update slic.
I can't use slic3r as a command line app, so the new version won't work for me as item 2 on my first post is not yet resolved, therefore I have no GUI.

Edited 1 time(s). Last edit at 05/28/2015 11:46AM by Alistair.

How about trying with the latest Perl?

Perl is already the latest version apparently (Perl 5 version 18)

Well, technically Perl is at 5.20 already.
Being stuck at 5.18 might explain why you're not getting the latest versions of dependencies which in turn won't compile properly.

Edited 1 time(s). Last edit at 06/01/2015 01:33PM by Mikk36.