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.
My setup:
- 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.
I recommend first installing the latest Sailfish firmware and following the Sailfish installation, setup, and tuning guides.
Setting Up Slic3r for a Flashforge Creator, Creator X, or Creator Pro
Download and install the latest stable version of
Slic3r. Make sure you’re in “Expert mode” (File, Preferences).
Use the Configuration Wizard, or manually configure the printer settings. You’re going to want at least two printer profiles – one for single material prints and another for dual material prints. This is because we’ll use different Start and End G-Code to handle the appropriate number of extruders.
Choose “Sailfish (Makerbot)” for “G-Code flavor” and set the print bed dimensions (X=228, Y=150).
Set the number of extruders to 2.
Custom G-Code (Single Material Prints – Right Extruder)
Under “Custom G-Code” in your single material printer profile, try using the following. I like my G-Code to be well-documented for later reference, hence all the comments at the beginning. Feel free to remove any line starting with a semi-colon.
This Start/End g-code incorporates fixes for a number of issues I was having that seem to be related to the particularities of a Makerbot type printer.
In summary:
- 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.)
Custom G-Code (Single Material Prints – Left Extruder)
Custom G-Code (Dual Material Prints)
Under “Custom G-Code” in your dual material printer profile, try using the following:
In summary:
- 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
You can download the GPX utility from
here. Place it in a directory of your choice.
I found that if you just place the GPX executable into the “Post-processing scripts” field in Slic3r, it doesn’t work the way I want it too because Slic3r doesn’t let you pass command-line arguments to the script (for security reasons). To get around this, I created my own little Perl script to call GPX with the options I want.
If you don’t have a Perl interpreter installed, you can get one
here.
In Slic3r’s “Print Settings” under “Output options”, I use the following for “Post-processing scripts” (modify according to where you have Slic3r installed):
D:\Slic3r\run-gpx.pl
run-gpx.pl is as follows:
#!/usr/bin/perl -i
use strict;
use warnings;
use File::Basename;
use Win32;
my $fname = $ARGV[0];
my ($name, $path, $suffix1) = fileparse($fname, qr’\.[^\.]*’);
my $shortname = “$name$suffix1”;
my $shortpath = Win32::GetShortPathName($path);
exec “D:/gpx-win32-1.3/gpx.exe -g -p -m r1d $shortpath$shortname D:/Dropbox/3DPRIN~2/$name.x3g”
You’ll need to modify the last line according to where you have gpx.exe and where you want the .x3g files placed.
This will call GPX, tell it that we’re using a Replicator 1 Dual (which is basically what the Flashforge Creator is), and tell it where to place the .x3g file. I like having all of the resulting .x3g files go into the same directory so they can then be easily copied to the SD card for printing.
Closing Comments
During testing, I discovered a couple of minor software bugs. I reported them to the developer, and he had them fixed within a few days!
Slic3r is excellent software, and has been released to the community free of charge. If you find the software useful, I encourage you to make a
donation to support the hard work Alessandro is doing.
Have a Flashforge Creator or Creator X and know a better way of doing anything covered here? Post it in comments.
Good luck!
