The FlashForge Creator family of printers are great printers for the price, but over the past several months, I have had to solve a number of problems and research a lot of answers in order to get everything working as I wanted. Some of these answers were easy to find, but others don’t seem to be addressed anywhere. I intend to summarize here the results of my testing and calibration, which will be most useful for those using a FlashForge Creator, Creator X, or Creator Pro.
- Flashforge Creator and Creator X (dual extruder models)
- Sailfish firmware v7.6
- Windows 8.1
- Slic3r v1.1.7
Note: While this post shows how to set this up on Windows, I’ve posted a video tutorial that shows how to install on Mac OS X.
As outlined in a previous post, I spent a good deal of time testing out various slicing software. I was having a few issues with Slic3r (all of which were eventually solved and will be addressed here), so I went on to try Makerbot Makerware. The latest version does seem to handle the latest Sailfish firmware okay. Overall, the results were good, and I started to shift to using Makerware as my default software for slicing and generating the x3g files needed for printing. But after lots of further testing and careful comparisons, I became convinced that Slic3r has a more elegant slicing engine and produces higher quality results at better speeds, giving you more control along the way. It also produces more effective support material than Makerware. So, determined to use Slic3r, I went back to solve the problems I had run into previously. Hopefully, the following will save others with a FlashForge Creator or Creator X from having to invest as much time in this process as I did.
Setting Up Slic3r for a Flashforge Creator, Creator X, or Creator Pro
Custom G-Code (Single Material Prints – Right Extruder)
- Slic3r’s default g-code wasn’t setting temperatures properly for my machine. This g-code uses the proper M-commands for the FlashForge and utilizes the Slic3r variables to fill in the temperatures you have set for the first layer.
- Note the use of the “[first_layer_temperature_0]” variable. I couldn’t find this documented or addressed anywhere, but I tried something and got lucky. The variable seen in all the documentation and the Slic3r .ini files is “[first_layer_temperature]”, but on my dual extruder printer, that was returning two numbers separated by a comma. So the resulting g-code would be M104 S225, 225 T0 (which doesn’t compute). On a whim, I decided to try “[first_layer_temperature_0]” and found that yes, this will return just the value for the first extruder (and “[first_layer_temperature_1]” is for the second extruder).
- The default Start g-code used a simple purge routine to extrude some plastic in a corner of the build plate before starting the job. I found that sometimes, especially if there was some oozing plastic already hanging on the extruder nozzle, the blob of plastic created by this initial purge routine would get caught on the nozzle and would then get dragged along, interfering with the first layer of the print. I greatly prefered Makerware’s approach, which extrudes a thin line of plastic along the front edge of the build plate before starting a job. It has a tendency to wipe off any oozing plastic that was already on the nozzle so you get a nice clean start to each print. I analyzed some g-code from Makerware and incorporated the appropriate bits here, with some modifications (i.e. it uses Slic3r’s “[first_layer_height]” variable.)
- Same use of temperature variables as discussed previously. Note the use of both “[first_layer_temperature_0]” and “[first_layer_temperature_1]” for the first and second extruders, respectively. These temperatures are determined by the material you’re using, as defined in the Filament profiles within Slic3r.
- The same improved purge routine dicussed above, but modified so that it is repeated for each extruder. The second extruder uses a Y value that’s +1, so it lays the filament down right next to the filament from the first extruder.
- Tool changes for dual extrusion prints weren’t working for me. When I looked at Slic3r’s g-code, I found that it was using “M108 T0” or “M108 T1” to change extruders. Looking at g-code from ReplicatorG/Skeinforge, I saw that the Makerbot type printers seem to be looking for a simple “T0” or “T1” and don’t seem to recognize the M108 commands. Using the above “Tool-Change G-Code” takes care of this issue by inserting the appropriate commands before each tool change. The M108 commands are still in the g-code, but they just get ignored by the printer.
Converting from G-Code to .X3G Using GPX as a Slic3r Post-Processor
my $shortname = “$name$suffix1”;
my $shortpath = Win32::GetShortPathName($path);