Try:
M2001 ; Zeepro’s “End Print” (drops platform, centers head, retracts filament slightly, and turns off heat)
G28 X Y ; home x and y axis (to zero head instead of centering from above command)
OctoPi Tutorial for Zim
BTW I created profiles that don’t attempt to heat up both extruders and they still both heat up. I’m also completely stumped at what exactly picks the T0 or T1 tool for the print. When I slice I figured that the cura profile would embed the right GCODE command for T0 or T1 based on the profile I use… but it doesn’t seem to do it. Anyone figure this out?
EDIT: Just added all 3 profiles I’m using in the post above.
EDIT2: Hmm, it seems to use a different start script in the GCO file than the one in the profile I selected… here’s the profile:
start.gcode = ;Set hotends and bed to their temperatures and continue
M140 S{print_bed_temperature} ;set bed temperature, no wait
;M104 T0 S{print_temperature} ;set EX0 temperature, no wait
M104 T1 S{print_temperature2} ;set EX1 temperature, no wait
;set temps again and wait
M190 S{print_bed_temperature} ;set bed temp and wait
;M109 T0 S{print_temperature} ;set EX0 temp and wait
M109 T1 S{print_temperature2} ;set EX1 temp and wait
G17 ;set plane to XY (not really necessary...)
G21 ;set units to mm (or G20 for inches)
G90 ;set to absolute positioning (or G91 for incremental/relative)
M82 ;set extruder to absolute mode (or M83 for relative)
M107 ;fan off
M203 X10000 Y10000 Z600 E250 ;set max feedrates
G28 ;home all Axes
G1 Z15.0 F(travel_speed)
T1 ;Switch to the 2nd extruder
G92 E0 ;zero the extruded length
G1 F200 E10 ;extrude 10mm of feed stock
G92 E0 ;zero the extruded length again
G1 F200 E-{retraction_dual_amount}
T0 ;Switch to the first extruder
G92 E0 ;zero the extruded length
G1 F200 E10 ;extrude 10mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
And here’s the GCO file:
;Generated from cd-dvd-bearing-hub2.stl 79c3b89c6a3aac442a0bd4f02a865265f03cef73
;Generated with Cura_SteamEngine 15.04
M104 T1 S200.0
M109 T0 S200.0
M109 T1 S200.0
T0
;Sliced at: Sun 13-09-2015 06:12:32
;Basic settings: Layer height: 0.15 Walls: 0.3 Fill: 20
;M190 S70 ;Uncomment to add your own bed temperature line
;M104 S200 ;Uncomment to add your own temperature line
;M109 T1 S?print_temperature2? ;Uncomment to add your own temperature line
;M109 T0 S200 ;Uncomment to add your own temperature line
G21 ;metric values
G90 ;absolute positioning
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F7200 ;move the platform down 15mm
T1 ;Switch to the 2nd extruder
G92 E0 ;zero the extruded length
G1 F200 E10 ;extrude 10mm of feed stock
G92 E0 ;zero the extruded length again
G1 F200 E-16
T0 ;Switch to the first extruder
G92 E0 ;zero the extruded length
G1 F200 E10 ;extrude 10mm of feed stock
G92 E0 ;zero the extruded length again
G1 F7200
;Put printing message on LCD screen
M117 Printing...
I’m not familiar with Cura, but simplify3d just lets you pick the tool(s) to use for the profile. I had to setup 3 profiles: one for left (T1), one for right (T0), and one for both.
Simplify3D looks nice, but it’s another $140 I’d like to keep for the moment 
Got it to use T1 with this script.
I just tried using Cura to generate the GCODE and then doing a little manual editing it started out showing both temps rising perfectly at the same time and then after they both heated up the T0 temps dropped back to 55C. It appears as though Octoprint was fooled into thinking T0 was rising, at least with this print (not sure about previous ones). Here’s the start profile:
;M140 S70 ;set bed temperature, no wait
M104 T0 S0 ;set EX0 temperature, no wait
M104 T1 S200 ;set EX1 temperature, no wait
;set temps again and wait
;M190 S70 ;set bed temp and wait
;M109 T0 S0 ;set EX0 temp and wait
M109 T1 S200 ;set EX1 temp and wait
G17 ;set plane to XY (not really necessary...)
G21 ;set units to mm (or G20 for inches)
G90 ;set to absolute positioning (or G91 for incremental/relative)
M82 ;set extruder to absolute mode (or M83 for relative)
M107 ;fan off
M203 X10000 Y10000 Z600 E250 ;set max feedrates
G28 ;home all Axes
G1 Z15.0 F(travel_speed)
T1 ;Switch to the 2nd extruder
G92 E0 ;zero the extruded length
G1 F200 E10 ;extrude 10mm of feed stock
G92 E0 ;zero the extruded length again
;G1 F200 E-16
;T0 ;Switch to the first extruder
;G92 E0 ;zero the extruded length
;G1 F200 E10 ;extrude 10mm of feed stock
;G92 E0 ;zero the extruded length again
G1 F7200
@BDub: I think the fact that cura always heats up both extruders was my fault:
I Posted the lines from my 2-extruders-profile:
M104 T0 S… and M104 T1 S…
Of course if you want to print with one extruder only, this makes no sense. You can delete the T1 Line if you only use the right extruder or the line with T0 if you want to use the left one.
Unfortunately, it seems that you have to make one profile for every single configuration in cura if you want to easily print your g-code.
You need a profile for a fast print, for a medium print and for a detailed print, as well as a super-high quality print, and all of them for PLA and ABS. Also you might need three profiles for dual-extruder prints in several qualities, and in different materials…
You see that it would be a bad idea to slice everything with the onboard slicer.
Although the new RasPi2 B ist really fast, slicing on PC/MAC is faster and way more comfortable.
So I decided for myself to have three standard-profiles in Octo for a quick and dirty print (and to show my friends that I can print from my phone 
), and everything else… well, I slice on my computer with slic3r or Cura.
BTW: In the original ZIM software, you had the same problems. The only advantage was that you could modify your settings in the UI. (BUT: There were only the easy settings, no options for experts)
@all: You can delete the G17 line… Octoprint sais that the command is unknown… (G17= set plane to XY)
@J_Schmidt right I did catch that in the script, but even after I modified it to only heat one extruder, it reports that the other one is heating as well (which it’s not). Here’s what the temp tab looks like as it’s heating:
And then in the console, you can see it’s receiving 30.5 for T0, not 155.4.
Recv: T:153.8 E:1 W:? T0:30.5 /0.0 T1:153.8 /200.0 B:0.0 /0.0
Recv: T:154.6 E:1 W:? T0:30.5 /0.0 T1:154.6 /200.0 B:0.0 /0.0
Recv: T:155.4 E:1 W:? T0:30.5 /0.0 T1:155.4 /200.0 B:0.0 /0.0
Recv: T:156.3 E:1 W:? T0:30.5 /0.0 T1:156.3 /200.0 B:0.0 /0.0
So maybe this is an Octoprint bug?
To me the on-board slicing seems really fast, and I’d prefer to use one less software package step before I go to the printer if possible. But the profiles don’t even seem to be loading properly on the printer anyway. Currently I’m creating in sketchup, exporting as STL ascii, opening in netfabb basic to check for errors and automatically fix them if so export form there if necessary, then I would have to now open in Cura to slice. I do like the view in Cura though… so maybe once I get on to some larger prints with weird support structures it will be more advantageous to preview the whole print in Cura.
Also unrelated I printed 4x of my CD hubs and the print got paused after about an hour and I’m not sure why (might have been when I tried checking on it from my back yard while I was mowing the lawn 
but I didn’t realize it was just paused and I ripped the half baked hubs off of the platform to check my filament. Doah! 
Wish I would have got to save the day with the resume button… rats.
@BDub, I believe this is a bug in my new Marlin responses not matching what OctoPrint expects. It’s better than it was, but still not right, because I’ve seen the same thing where temp 1 tracks temp 0 even though the terminal show temps correctly. I need to find out how to properly format the response for OctoPrint and fix Marlin to do that. The whole dual extruder active tool thing is sortof a hack on my opinion, made to fit CNC where there is one active tool. On a printer, you can really have 2 active tools, but Marlin gcode doesn’t account for this.
1 Like
Are you sure? I think it´s more like
T0 active … print curve, T1 active … print curve, T0 active… and so on.
I don´t think that the G-Code nor the printer ist capable to print with two printheads at the same time. Due the fact that the offset between the heads is fixed, this would also make no sense.
Sure, the use case is limited, but some people use both extruders simultaneously to produce multiple copies of the same part. This is possible on any printer based on the Makerbot Replicator or Sailfish firmware I believe, like the Flash Forge and other copies. It’s Called Dualstrusion
I guess what I really don’t like is reporting T for active temperature for the “active” extruder when there is actually T1 and T0 temperature data to graph and track (e.g.they are both active, at least as far as temperature is concerned, so what is '‘T’ really doing for us there). Having to pick one as active does things like make OctoPrint track the wrong one as BDub reported, until we figure out the correct format to send. This is why the original Zeepro Marlin didn’t work so well with OctoPrint. Mine doesn’t either in some cases. I looked up my mods from the stock Marlin distribution and overlayed them on the Zeepro firmware, but perhaps I missed something (or OctoPrint doesn’t work with Marlin and dual extrusion). I’ll circle back on it and make it work when time allows (maybe tonight 
).
1 Like
@jpod Here’s some help:
http://docs.octoprint.org/en/master/configuration/config_yaml.html
# If enabled, reports the set target temperatures as separate messages from the firmware
#
# True: > M109 S220.0
# < TargetExtr0:220.0
# < ok
# > M105
# < ok T0:34.3 T1:23.5 B:43.2
# False: > M109 S220.0
# < ok
# > M105
# < ok T0:34.3/220.0 T1:23.5/0.0 B:43.2/0.0
repetierStyleTargetTemperature: false
# If enabled, reports the first extruder in M105 responses as T instead of T0
#
# True: > M105
# < ok T:34.3/0.0 T1:23.5/0.0 B:43.2/0.0
# False: > M105
# < ok T0:34.3/0.0 T1:23.5/0.0 B:43.2/0.0
smoothieTemperatureReporting: false
##Reprap format
http://reprap.org/wiki/G-code#M105:_Get_Extruder_Temperature
##Code that parses the response in OctoPrint:
##Talk about if OctoPrint is supporting a dual extruder, how to handle the T vs T0 vs T1:
Maybe as a guess, I would say the first active extruder temp represented as just T, needs to also be followed with a target temp /200.0
Recv: T:155.4 E:1 W:? T0:30.5 /0.0 T1:155.4 /200.0 B:0.0 /0.0
vs.
Recv: T:155.4 /200.0 E:1 W:? T0:30.5 /0.0 T1:155.4 /200.0 B:0.0 /0.0
Excellent! Thanks for the info, I’ll give it a try tonight.
1 Like
Interesting to note as well, before a print is started the response is slightly different:
Send: M105
Recv: ok T:25.7 /0.0 B:0.0 /0.0 T0:25.7 /0.0 T1:25.9 /0.0 @:0 B@:0
and after (this is not the M105 but the M109 set and wait command):
Send: N4 M109 T1 S200*43
Recv: T:153.8 E:1 W:? T0:30.5 /0.0 T1:153.8 /200.0 B:0.0 /0.0
Once it reaches temp it’s not waiting any more and starts sending M105’s again (last 4 lines here)… which it apparently knows how to process just fine:
Recv: T:199.6 E:1 W:8 T0:36.2 /0.0 T1:199.6 /200.0 B:0.0 /0.0
Recv: T:200.1 E:1 W:7 T0:36.2 /0.0 T1:200.1 /200.0 B:0.0 /0.0
Recv: T:200.5 E:1 W:6 T0:36.2 /0.0 T1:200.5 /200.0 B:0.0 /0.0
Recv: T:201.0 E:1 W:5 T0:36.3 /0.0 T1:201.0 /200.0 B:0.0 /0.0
Recv: T:201.5 E:1 W:4 T0:36.3 /0.0 T1:201.5 /200.0 B:0.0 /0.0
Recv: T:202.0 E:1 W:3 T0:36.4 /0.0 T1:202.0 /200.0 B:0.0 /0.0
Recv: T:202.5 E:1 W:2 T0:36.6 /0.0 T1:202.5 /200.0 B:0.0 /0.0
Recv: T:203.0 E:1 W:1 T0:36.7 /0.0 T1:203.0 /200.0 B:0.0 /0.0
Recv: T:203.2 E:1 W:0 T0:36.6 /0.0 T1:203.2 /200.0 B:0.0 /0.0
Recv:
Recv: ok
Send: N5 G17*26
Recv: Unknown command: "N5 G17*26"
Recv:
Recv: ok
Send: N6 G21*28
Recv:
Recv: ok
Send: N7 G90*23
Recv:
Recv: ok
Send: N8 M82*17
Recv:
Recv: ok
Send: N9 M107*44
Recv:
Recv: ok
Send: N10 M203 X10000 Y10000 Z600 E250*12
Recv:
Recv: ok
Send: N11 G28*35
Recv:
Recv: ok
Send: N12 G1 Z15.0 F(travel_speed)*60
Recv: ok
Send: N13 T1*9
Recv: echo:Active Extruder: 1
Recv:
Recv: ok
Send: N14 G92 E0*114
Recv:
Recv: ok
Send: N15 G1 F200 E10*44
Recv: ok
Send: N16 G92 E0*112
Recv:
Recv: ok
Send: N17 G1 F200 E-16*5
Recv: ok
Send: N18 G1 F7200*114
Recv: ok
Send: N19 M107*29
Recv:
Recv: ok
Send: N20 G0 F7200 X49.671 Y49.658 Z0.250*33
Recv: ok
Send: N21 G0 X49.347 Y50.075*17
Recv: ok
Send: N22 G1 F1800 X49.671 Y49.658 E0.01647*50
Recv: ok
Send: N23 G1 X52.620 Y47.393 E0.13241*95
Recv: ok
Send: N24 G1 X56.065 Y45.966 E0.24868*92
Recv: ok
Send: N25 G1 X59.759 Y45.480 E0.36486*80
Recv: ok
Send: N26 G1 X63.455 Y45.966 E0.48110*83
Recv: ok
Send: N27 G1 X66.901 Y47.392 E0.59739*85
Recv: ok
Send: N28 G1 X69.857 Y49.662 E0.71360*81
Recv: ok
Send: N29 G1 X72.128 Y52.620 E0.82988*87
Recv: ok
Send: N30 G1 X73.555 Y56.065 E0.94615*95
Recv: ok
Send: N31 G1 X74.041 Y59.761 E1.06239*85
Recv: ok
Send: N32 G1 X73.622 Y62.948 E1.16262*80
Recv: ok
Send: N33 G1 X73.547 Y63.470 E1.17907*95
Recv: ok
Send: N34 G1 X72.328 Y66.417 E1.27851*83
Recv: ok
Send: N35 M105*17
Recv: ok T:200.0 /200.0 B:0.0 /0.0 T0:37.9 /0.0 T1:200.0 /200.0 @:0 B@:0
Send: N36 M105*18
Recv: ok T:200.0 /200.0 B:0.0 /0.0 T0:37.9 /0.0 T1:200.0 /200.0 @:0 B@:0
I tried installing the YamlPatcher plugin and applying this option with no change:
Temperature for M109 is fixed in 1.1.0.19. I tried adding the target temperature to the “active” extruder as suggested, but this still didn’t fly with OctoPrint. I ended up removing active temperature for M109 altogether, and that solved it due to parsing for T0 and T1 only. This is what I didn’t like about the reporting anyway, since T0 and T1 are already there for both extruders… It appears the OctoPrint guys agreed in our absence , though it is not what the original Marlin does (e.g. appears OctoPrint isn’t compatible with Marlin and dual extruders without some modifications).
Btw, this version also shortened the button hold required to turn off the printer. It never felt very responsive to me with a 2 second hold required. I changed it to 500ms. I understand the whole accidental push an all, but that button is pretty hard to accidentally push. You can change it back on Configuration_adv.h -> MAX_TIME_PUSHING_MS if you are so inclined (changed the value to milliseconds, so 2000 for the original timing).
So in all, heres the changes in 1.1.0.19 JPod
- Added T0 and T1 temperature readings for M105 and M109 commands for
OctoPrint. - BLOCK_BUFFER_SIZE changed from 4 to 16 to reduce short move pauses.
- Increased serial receive buffer from 4 to 8 to reduce short move pauses.
- Added OCR1 workaround for newer compiler described here to correct for short move overrun.
- Removed references to RFID and PVA code.
- Added filament used output to terminal when print completes.
- Removed “active” extruder temperature to correct OctoPrint temperature tracking of T1 for M109 commands.
- Shortened button hold required to turn off machine to 500 ms (from 2 seconds).
4 Likes
I just found this really good page for configuring OctoPi if Joe’s tutes don’t get you all the way there. I was having trouble enabling wi-fi, and that got me sorted:
Note that he says to edit /etc/network/interfaces but it’s looking at boot/octopi-network.txt so continue using that as directed.
There is this really nice 
in Simplify3D.
It saves me from prints not starting after everything is heated up and my personal “killed Zim”-Problem in mid-print.
Does anybody know how to make this instant kill and connection reset with reconnect and what else, in Octoprint?
Creating a macro with M112? This might be stupid but is the code that appear on S3D for emergency stop…
I made a G-Code Handbook some days ago (original source of information: Reprap Wiki).
If anyone likes to take a look, here´s the Link:
https://onedrive.live.com/redir?resid=B2A53EE4BB8C1B66!2098&authkey=!AI-FOv8hsb0DrOA&ithint=file%2Cpdf
1 Like
This is a really valuable resource. Thanks for sharing it with us.
Hm, I get that same command after I press the button.
But what I really get is this:
RECEIVED: Unknown command: “M112”
Afterwards the reset, disconnect and reconnect happens. But there are no visible commands in the console.
So something else is going on.
No ideas?
Hey, I found this github repo where a 3d printer owner of a craftbot printer created a python script for Octopi to prevent the extruders from turning off while heating up if it took too long to heat them up to your targeted temp. I haven’t tried/tested it but something to look into.
I know a few of us are frustrated that it shuts down on us when heating up the print head.
From what i quickly gathered is that it simply queries for temp. and sets it again. I do that manually now.
github repo: https://github.com/krisp/staywarm