Slic3r G-code snippets for FlashForge Creator Pro

by DrLex, published

Slic3r G-code snippets for FlashForge Creator Pro by DrLex Jun 5, 2017
0 Share
Download All Files

Thing Apps Enabled

Order This Printed View All Apps


Liked By

View All

Give a Shout Out

If you print this Thing and display it in public proudly give attribution by printing and displaying this tag.

Print Thing Tag

Thing Statistics

1347Views 769Downloads Found in 3D Printer Accessories


These are the G-code snippets that belong with my Slic3r profiles for the FlashForge Creator Pro. Although I think the G-code is quite mature now, it is possible I will update it separately from the rest of the profile. Therefore use the ‘Watch’ button to stay notified of updates.
If you see that only this G-code was updated, you can in most cases copy-paste the updated snippets into the printer settings section of Slic3r, as explained in my article. However, check the ‘Updates’ section below to see if you don't need to do anything else, like enable certain options in the printer profiles.

This code has the following features:

  • Z homing with the same speed as plate levelling procedure
  • Reliable tool change when printing with left extruder
  • Only heat nozzles to 140°C while waiting for the bed to heat, and then continue heating, to avoid baking filament inside the extruders when the bed needs a long time to heat
  • Before printing the priming line, chop off ooze on front edge
  • Extrude a line across the front of the bed to prime the nozzle
  • Do an extra wipe on the extruded line
  • No dubious fiddling with stepper VRefs
  • Work around typical extruder lag when the actual print starts

It is probably easy to adapt this code for other slicers like Cura or Simplify3D, if you know how to substitute the parameter names. However, for Cura you would need to remove the relative E commands because it only supports absolute extrusion coordinates.

(Again, I attached an STL file just because Thingiverse only allows Things with some kind of 3D model.)

Print Settings

Printer Brand:





Tweaked start G-code: wait slightly farther away from the front edge to reduce risk of ooze not being properly chopped; improve sideways chop and add another final move for another small wipe across the extruded line; set all speeds to sensible values (although some are simply overridden by firmware limits anyway).


No longer disable Z stepper in start G-code, because this could cause the platform to drop if the Z axis is very well lubricated (it could also introduce a small error due to microstepping being interrupted). Also slightly reorder options summary to better group items that I care the most about.


Update priming routine in start G-code to reduce the risk of sticky filaments remaining stuck to the nozzle; tweak tool change during start code; remove obsolete macros and avoid the risk of non-ASCII characters ending up in the code (both these confuse the latest Prusa3D release).


Big change: converted profiles and G-code to relative E coordinates. Do not copy-paste these snippets into your existing printer profiles, unless you enable ‘Use relative E distances’ in every profile. Also updated start G-code to produce a better preview in Repetier Host (both these changes were recommended by freiser77).
Note that one small disadvantage of the relative E, is that the hack to counteract extruder lag when the print starts, no longer works. This can now only be done in a post-processing script that adds about 0.6mm to the first unretract. Maybe some day I'll release such a script…

2017/12/31: made a change to the Start-dual-extruders-postproc code because some versions of Sailfish do not honor the M109 command. Make sure to download the latest version of this file if you need it.

More from 3D Printer Accessories

view more

All Apps

Auto-magically prepare your 3D models for 3D printing. A cloud based 3D models Preparing and Healing solution for 3D Printing, MakePrintable provides features for model repairing, wall thickness...

App Info Launch App

Kiri:Moto is an integrated cloud-based slicer and tool-path generator for 3D Printing, CAM / CNC and Laser cutting. *** 3D printing mode provides model slicing and GCode output using built-in...

App Info Launch App
KiriMoto Thing App

With 3D Slash, you can edit 3d models like a stonecutter. A unique interface: as fun as a building game! The perfect tool for non-designers and children to create in 3D.

App Info Launch App

Print through a distributed network of 3D printing enthusiasts from across the US, at a fraction of the cost of the competitors. We want to change the world for the better through technology, an...

App Info Launch App

Treatstock is an online platform that offers decentralized manufacturing services such as 3D printing and CNC machining for clients all over the world. We offer free and instant access to comparati...

App Info Launch App

3D print your favourite design with NinjaPrototype, a professional 3D manufacture with consistent quality and speed.

App Info Launch App

Hi DrLex,

thanks for updating the geode-snippets.
However there seems to be an error.

I sliced some part with your dualstrusion start-gcode and the dualstrusion-script. The printer heats both nozzles up to 140 degrees and the bed to 100 degrees as requested in the first part. But then it starts printing and effectively ignores the "M109 S230 T0" requesting it to heat up to 230 degrees and wait until reached. I append my original gcode-file.

Well, it ‘works on my machine’ which probably means you are running a different firmware version that handles the M109 command in a different way. (I am running “v7.8 r0e8a9”.) If I search around, it seems indeed that older versions of Sailfish treat M109 the same way as M140 or M104, what a mess. I wish there was better standardisation between firmwares.
I'll upload new code soon, in the meantime you can fix this in your configs by replacing the single line with “M109” with two lines:

M104 S[first_layer_temperature_0] T0
M6 T0

Works on My Machine certification badge
by DrLex

I use the exactly the same firmware. I've checked it over Utilities -> Version information on my printer.

Then it must be due to GPX. What version are you using and how do you invoke it? I have 2.5.2 and it is invoked as gpx -m fcp.

I have GPX 2.5.2, too. It is invoked by your make_fcp_x3g-script with the following command

"${GPX}" $arg_p -m fcp -l "$1"
. You see, I've only inserted the
option to enable the logging.

OK, this makes no sense. Even though I obviously will never use the M109 command again, I still want to know why it does work as expected in my setup, but not in yours.

Try the attached test file. The extruders won't do anything so you don't need to unload the filament. It will heat the bed to 40°C and the extruders to 140°C, then when the bed has reached its temperature, it should wait for the right extruder to reach 180°C. Then it will do some useless moves and play some beeps. If it doesn't wait and starts moving at 140°C, then there must be something different about your printer's firmware. If it does wait, then there must be a difference between your GPX and mine.

I've tested your x3g-file. It behaves as expected. Maybe because I did a firmware update, after Flashprint showed me the message, that there is some new firmware available. But both have the version string v7.9 r0e8a9. Seems that the version string is not reliable.

Here you go: I updated everything to relative E distances. This especially makes the dualstrusion post-processing script easier to improve, and less prone to extrusion bugs. If you use that script, you must also upgrade it to version 0.6.
You should probably load the updated profiles from the configs Thing to ensure everything is correct. Alternatively, you can also manually enable ‘Use relative E distances’ in all of your printer profiles that use these G-code snippets.

If you want to preview files in the online GCode Viewer, a small workaround is required to ensure correct visualisation. This workaround is included in the latest version of the make_fcp_x3g script. It consists of putting an extra M83 command after the G90 command that Slic3r inserts at the start of the print.

Slic3r configuration for FlashForge Creator Pro
by DrLex

Hi DrLex,

could it be, that the temperature-variation of the "Multiple extruders -> ooze prevention" settings is not considered on tool change?



It is not, and I would expect Slic3r to handle this by itself. The last time I tried the ooze prevention feature however, it didn't work correctly and heated up the wrong extruders at the wrong temperatures. Plus, this feature is insufficient to get decent dual extrusions anyway. I only do dualstrusions with my post-processing script, which inserts its own temperature commands.
I have been testing the relative E settings and converted the profiles and the dualstrusion script, I will release the new versions shortly.

Hi DrLex,

why don't you use relative E distances? Then debugging extrusion issues would be more comfortable. It would also be better to start heating the nozzle to the final temperature, before you wait for the print bed to heat up. Saves lot of time and the hardware is capable of handling the load.

Thanks for your good work.


The postponed full heating of the extruders is not due to power concerns, it is because it takes way longer for the bed to heat up than for the extruders. If you're going to preheat them immediately to the target temperature, you're going to be baking the stationary filament for a long while, especially when the bed has to go from 15°C to 110°C. I usually preheat the bed anyway, which causes the intermediate 140°C heating to be skipped, at least when using the latest version of the G-code. Even when not preheating, going from 140°C to the final temperature is only a matter of a minute or so.

The reason why I don't use relative E is pretty simple: I didn't know it existed until now. I thought there was only a choice between making all coordinates relative or absolute, but it seems the firmware should respond to an M83 command indeed. I'll do some experiments with it and consider using it, but I would need to adapt my post-processing scripts as well, so it better be worth it :)

Thanks for your great work. What would be nice, btw, would be a G92 with the right boundary coordinates:

G92 X112.5 Y72.5 Z0 E0 B0; set (rough) reference point (also set E and B to make GPX happy)

This would place it in repetierhost on the right spot on the build-plate when viewing the gcode.

Important update: the previous code will break on the latest Prusa3D Slic3r release (and maybe also the regular Slic3r dev builds) due to this. Update to the latest snippets to fix this. You'll also get an improved pre-print wipe procedure.

P.S.: a question to the people who have clicked the ‘Watch’ button on this Thing: did you see anything in your dashboard when I updated the Thing description and files, or do you only see this comment (or doesn't this even show up)?

Comments deleted.

Hi DrLex,

Have you use MatterControl with your FFCP? I use 3 different slicers, all have their pros & cons.
FFCP's built in second extruder offset does not seem work with MatterControl or maybe it is getting overridden, it looks good on the GUI but not in printout, I fix printout by adding X offset -34.003, but now the generated GUI view is off.

No, I haven't used it. Your slicer should not be aware of the offset between the nozzles, it should be set to 0 because the firmware handles the offset. If you perform a T1 command, the printer will shift the carriage, but only if there is enough room (this is why my start code first makes a move of at least 34mm to the left).