Using Slic3r with the FlashForge Creator Family of 3D Printers

January 5, 2014 Jeremy Simon 3D Printing, Calibration, Dual Extrusion, Informational, Slicing 63
Using Slic3r

The FlashForge Creator family of 3D 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 softwares. 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.
Start G-Code:  start_gcode_single.txt
End G-Code:  end_gcode_single.txt
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)
Start G-Code:  start_gcode_left.txt
End G-Code:  end_gcode_left.txt
Custom G-Code (Dual Material Prints)
Under “Custom G-Code” in your dual material printer profile, try using the following:
Start G-Code:  start_gcode_dual.txt
End G-Code:  end_gcode_dual.txt
And for Tool-Change G-Code:  tool_change_gcode_dual.txt
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 discussed 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!

More 3D Universe blog posts:

Check out the 3D printed cellular cocoon vase HERE…

My post on how 3D printed architectural design brings an idea to life can be found HERE…

Related Articles

3D Printing

Introducing the Ultimaker Essentials Software

November 5, 2020 Jen Owen 3D Printing, Education, Informational, Manufacturing, Products, Ultimaker Comments Off on Introducing the Ultimaker Essentials Software

We are excited to officially introduce Ultimaker Essentials to our 3D Universe customers and offer this incredible subscription plan. What is Ultimaker Essentials? Ultimaker Essentials is a software subscription plan, tailor-made for enterprises with more […]

63 Comments

  1. Hi,

    First thank you for posting this it has been a great help. I have deeply regretted updating to sailfish until this point because nothing has worked. I have been unable to slice how i typically would. however I still cant get the .x3g files to generate. I am in desperate need to print a part so any help you can give me would be appreciated.

    this is the code I am using for the post script section.

    C:\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 “C:/gpx-win32-1.3/gpx.exe -g -p -m r1d $shortpath$shortname C:/sd card files /$name.x3g”

    However it does not generate any file. I have never worked with perl so have no clue what I am doing.

    • Just remove the spaces from your output file folder and it should work. So instead of C:/sd card files, use C:/sd_card_files or something like that.

      Good luck,
      Jeremy Simon
      3D Universe

    • did u manage to fix that? if yes, how? i don’t have any spaces in my script: here it is.

      #!/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 “C:/gpx-win32-1.3/gpx.exe -g -p -m r1d $shortpath$shortname D:/3DPRINT/$name.x3g”

      • I just use a Windows batch file. Works perfectly. Add the contents:
        C:\\gpx.exe -m fcp %1

        Also, Mark Walker has created a fork of GPX that includes improved support for the FlashForge Creator Pro here:
        https://github.com/markwal/GPX

        (That’s the machine configuration listed above, “fcp”) 🙂

        • Oops.. looks like my angle-brackets got filtered out. The double-slash is meant to be the path to GPX. In my case, this is the batch file (gpx.bat):
          C:\Data\Projects\GPX-markwal\master\gpx.exe -m fcp %1

    • I wanted to figure this out too and I finally did. Note that I’m running Windows 10. I’ve summarized what I’ve done as best as I could. There are other languages you could use and other ways to do this, but this is what I did. I know this is 1.5 years after your post, but it might help someone.

      Note: do all of the following at your own risk and read up about the pieces before you do them if you’re unfamiliar with any step. Your mileage may vary. Also, a big thank you to this thread and other internet people for the information I was able to put together to get this to work myself.

      Slicer on Windows

      1. Get Slic3r working: http://manual.slic3r.org/intro/overview.
      a. Install Slic3r to this location “C:\Slic3r”.
      b. Run Slic3r by clicking on “C:\Slic3r\slic3r.exe”.
      c. Set up Slicer per the instructions.
      d. Import a file and generate some gcode to test it out. Open up the generated gcode file and make sure it looks fine.
      e. You’ve used Slic3r to generate some gcode! However, we want an “.x3g” file automatically generated to load up on the Flash Forge Creator Pro. So, moving on…
      2. Get Citrus Perl working:
      http://sourceforge.net/projects/citrusperl/files/latest/download?source=files
      a. Unzip the folder and place the folder inside the unzipped folder (named “perl”) directly to your “C:” drive for ease of access.
      b. Make a file called “perltest.pl” and locate it directly on your C drive for ease of access. Place the following two lines inside it. Note that one issue may have with running these scripts could be due to the differences in the types of quotation marks (the curvy ones versus the straight ones). Try replacing them if you copy/paste things from the internet.
      my $p = “You ran Perl successfully!”;
      print $p;
      c. Open a command window by going to start, run, and type “cmd”
      d. In the command window, type “C:\perl\bin\perl.exe perltest.pl”
      e. If you were successful, it will print out “You ran Perl successfully!”
      f. You’ve successfully installed Perl and it’s working!
      3. Get GPX working:
      a. GPX is needed to convert the gcode to an “.x3g” format. Download GPX from here for Windows: http://www.thingiverse.com/thing:81425/#files
      b. Unzip the folder and place the folder (my version was “gpx-win32-1.3”) directly to your “C:” drive for ease of access.
      c. Open a command window by going to start, run, and type “cmd”
      d. In the command window, type
      C:\gpx-win32-1.3\gpx.exe “C:\gpx-win32-1.3\macro-example.gcode”
      e. Check for errors mentioned by the GPX program. This example gcode should run fine, but your own files might have errors you’ll need to check out manually, such as buffer overruns, which should hopefully only happen on lines with long comments. These long lines are cut short, but it won’t matter because they should just be long comments.
      f. If you were successful, it will create a file in that same folder called “macro-example.x3g”
      g. You have successfully used GPX to convert a “.gcode” file to an “.xg3” file!
      4. Create the Perl script for Slic3r:
      a. Create a simple text document in Notepad or Wordpad.
      b. Name and locate it here: C:\Slic3r\run-gpx.pl
      c. The contents should be the lines below. Change the gpx.exe location if you installed it somewhere else. Update the last line to the location you want the “.x3g” file to go. Without that line, the “.x3g” file will be placed in the same folder as the input “.gcode” file’s folder.
      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 “C:/gpx-win32-1.3/gpx.exe -g -p -m r1d $shortpath$shortname C:/yourpath/$name.x3g”
      d. If not already recognized, you should associate the “.pl” file extension with “C:\perl\bin\perl.exe”
      e. Open a command window by going to start, run, and type “cmd”
      f. In the command window, run the Perl program with the Perl script input and an argument which is the pathname of a “.gcode”file:
      C:\perl\bin\perl.exe C:\Slic3r\run-gpx.pl “C:\gpx-win32-1.3\macro-example.gcode”
      g. If you were successful, the Perl program would have run the Perl file which ran GPX to create a “.x3g” file in the location you specified called “macro-example.x3g”
      h. You have successfully used Perl to run GPX to convert a “.gcode” file to an “.x3g” file!
      5. Fix the registry
      a. It didn’t seem like the Windows OS was allowing the parameter to be passed to the Perl script through Slic3r. After some digging, I realized I needed to do the following before getting this to all work in Slic3r:
      b. Go to start, run, and type “regedit” to edit the registry.
      c. Navigate to HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command
      d. Edit the only entry “(Default)” and change it from
      “C:\Perl\bin\perl.exe” “%1” %*
      TO
      “C:\Perl\bin\perl.exe” “%1”
      6. Now, try it with Slic3r:
      a. Okay, each of the prior sections should hopefully have worked successfully, so this should be easy. In Slic3r, under Print Settings, in the post-processing scripts box, type:
      C:\Slic3r\run-gpx.pl
      b. Now, when you click “export g-code” within Slic3r it will create gcode for your model, put your start.gcode and end.gcode around it, save it to the location you specify, then run that post-processing Perl script with the gcode location as an argument passed to it.
      c. The Perl script will take that gcode file just created and run it through the GPX program which creates an “.x3g” file in the location you specified.

  2. Single prints work great but when I try dual printing when it’s time to change the tool it sends the head to the left of the printer and then keeps trying to go left even after It hits the side.

    • It sounds like your toolhead offsets may not be set correctly (in onboard preferences, from Replicator G). Did you upgrade to Sailfish firmware? If so, did you write down all of your offset values before the upgrade and reset them back to the same values afterwards? What values do you currently show for X and Y home offsets and X and Y toolhead offsets?

      Your X home offset should be close to 152
      Your Y home offset should be close to 75
      Your X toolhead offset and Y toolhead offset should be close to 0, but this will vary based on dual nozzle calibration (for example, mine are set to -0.351 and 0.011)

      • I set the X toolhead offset to 0 and that solved the problem. Now when I try to dual print it will do the lines in the front with both heads. Then start with the first head but when it switches toolheads it goes through the motion except it’s not extruding. I have tried this with GPX and repG and get the same results. I have inspected every part of my Slic3r config and yes I have sailfish 7.6

        • lol I just checked the filament and it broke off so nothing was feeding. Thank you for your time though.

  4. Hi.
    Thanks for posting this article!
    Can you help me to modified your script to using on MacOSX?
    thank you.

  5. Hi, thanks for the great info! I’ve tried using your method to print with my Creator using the left extruder. The first layer works great, but the second layer tries to print from the right extruder. Do you know what may be causing this problem?

  6. Thanks for putting all of this together! I’ve got everything working great except for a couple little snags.

    The first is that I can’t get the perl script to automatically run. I don’t have any spaces in the path, and if I run the script from the cmd prompt on it’s own, doing the substitution of file names and paths, it works. Any ideas?

    From Slic3r:
    C:\Program_Files\Slic3r\run-gpx.pl

    Perl script is a duplicate of yours.

    The second thing is that GPX gives me buffer overflow errors. Whats that referring to?

    • There is a comment line (around line 2970) in my version that is over the 1024 byte limit. GPX will ignore it and all should still work.

    • Karbo is spot-on about the buffer overflow. If you still have any issues, see my reply to Connor above. It could help.

  7. Great job ! Thanks for sharing a valuable information. If you’re okay, I’ll try to translate it in to Korean for Korean users with your credit. Can I ?

  8. Hi there,

    Followed your guide above, but its my first go at slic3r with my printer (FF creator), the line extrudes across the front of the plate perfectly, but then the print starts in the back right quarter of the plate, my bed size and centre seem fine in slic3r, but im not really sure where to start looking to fix this?

    Cheers Steve.

    • You need to set the origin to 1/2 the dimensions… For the FFCP the bed size is X=228, Y=150 so the origin needs to be X=114, Y=75.

      Without that adjustment the prints will be at the back right corner on FFCP with Sailfish 7.7

  9. AHA!

    Print Centre was set incorrectly (should be 0, not half of the bed)

    I also think you could use a M140 to set the bed temp instead of M109, to allow the bed & extruder to preheat at the same time?

    Cheers Steve.

    • Odd, for me it is the exact opposite, had to make the origin 1/2 half the bed size.

      • Yup, same here.i thought it was because i use slicer in combination with replicatorg(to convert the gcode to x3g format). I have set the origin to 228/2 and 150/2 and now it s ok.

        • I would check the home offset settings in the firmware or through machine prefs in RepG. They should not be zero., and instead something like 152 and 75. That might cause this issue.

  10. I just folowed your tutorial, I’m using a flash forge creator pro, I managed to get everything setup just like in your video, the auto x3g works great, coppied the scripts for left and right off this page however when I ran it with the left extruder selected it heated the right extruder to the build plate temp and left the build plate cold, I canceled before anything else happened… any ideas?

    • Double-check your scripts to make sure “T0” is everywhere for the right extruder, and “T1” is for the left extruder.

  11. The right extruder works perfectly, but I’m experiencing an issue when trying to print with the left extruder. The printer starts the print before everything (nozzle and heat bed) heats up. If I manually preheat the bed, then hit build, everything works fine. I try comparing your start/end G-code, but I couldn’t find anything.
    …also is there a way to move the print bed down after the print is complete?
    Thank you for all your tips. PS do you plan on getting any more FF Creator Pros in stock?

    • I use the following GCode to lower the print bed. It’s placed right after zeroing X- and Y-axis:

      G0 Z150; lower Z axis to bottom

    • line #146 in the custom g-code start up should read as follows.

      M6 T1; wait for bed and extruder to heat up

      The T1 was left out. I was having the same problem until I added it.

  12. I am having trouble with my the g code output. For some reason, Slic3r is placing some default g-code lines that are stopping my bed from heating up. Currently, it is putting in the following g-code lines BEFORE my starting g-code.

    M127 ;
    M109 S105;

    Then it continues with the starting g-code you have posted above. Any insight into why its doing this? Thanks again for this resource.

    • I noticed that too. This is a quote from the Slic3r documentation:
      “The codes specified in Start G-code are inserted at the beginning of the output file, directly after the temperature control commands for extruder and bed. Note that if temperature control commands are specified (M104 and M190) then these will replace the temperature G-codes introduced by the Filament settings.”
      M127 I think is a code to turn off an extra (nozzle cooling?) fan.
      M109 is to set the heated build platform temperature.
      Your start gcode can easily overwrite these values, so it is not a problem.

  13. Great article, would you mind if i hacked it and republished for linux users. Makerware is a bitch to get working on modern linux systems. Breaks on both fedora 20+ and Ubuntu 14.04+

  14. Thank you so much for this info (and your youtube videos). I was printing awesome parts with a Creator Pro and Slic3r in under an hour. Your custom g-code has already proven to be invaluable.

  15. Great article, I have been looking for away to free myself of the Makerbot open/closed source slicing software and its limitations.
    I did run into one snag- I copied your starter and ending scripts for my flash forge dual extruder. Then installed Pearl and finally GPX and the post process code you developed. When I selected GPX for post process, Slic3r immediately shuts down. I used Slic3r without the P.P. script and it works, but as soon as I try to run the P.P. lights out.
    I am running the software on Win. 7. Just thought I would mention it.

    • Check the steps I did above in my reply to Connor. I also had Slic3r shut down when trying to generate gcode, but that was before I really had each of the pieces working. It works fine now after making sure all of the substeps were in place.

  16. Hi! So I’ve been printing smooth as butter with the right print head with your starting and ending gcode scripts. Been taking it from Slic3r and opening in RepG to print (I had some trouble where your post processing script crashes Slic3r :/)

    I have a problem when it comes to my left head though. It doesn’t seem to be waiting for it to heat up and just starts going for some reason. I think I figured out that problem though…I was a dummy and didn’t switch everything to “2” in the PrintSettings>Multiple Extruders category.

    After doing that though, I get a bunch of errors from RepG about MCode 135. I’m going to try the “swap tool head in gcode” feature in RepG, but if you know what the problem could be, that’d be awesome. If not I’ll probably go that route (haven’t tested it yet as I’m AFP…away from printer)

    • Just realized I neglected to say thank you. So THANK YOU SO FREAKING MUCH. Using Slic3r standalone is so much better than the old as hell Slic3r code in RepG.

    • Hey matt, when slic3r crashed, were you able to open it back up? I ran into the same issue and have not been able to open slic3r at all since. I’ve tried deleting the slic3r files and redownloading everything and nothing has helped. any suggestions? thanks!

      • Yes, I do recall having this problem. I’m trying to remember what settings that I had to modify, but I’m not at my home computer. Search around for where the profiles are stored on google though. I ended up figuring it out that way. Sorry if that’s not helpful, but I’ll try to look it up when I get home tonight. (If you don’t find it, shoot me a response so it pops up in my email as a reminder)

        -Matt

      • Had the same problem. You have to delete files located in C:\users\”username”\AppData\Roaming\slic3r\…

  17. I just got my FlashForge Creator Pro yesterday and it looks like they’ve updated some things out of the box. One is that it comes with Sailfish 7.7 and it looks like they included some updated device definitions in ReplicatorG.

    I’m not sure if this has changed, but one thing I had to do in Slic3r after running the Configuration Wizard I had to update the “Print center” in Printer Settings to be x:0, y:0. It had them at half the bed size as the default and it wanted to print my first test on the corner of the plate.

    So I’m guessing you prefer the straight line from edge to edge than the circular skirt that Slic3r can do? I was going for minimal start g-code as a starting point so I thought I’d trim it to something similar to what ReplicatorG was putting out and see if the skirt was good enough for me. Something I removed resulted in a very slow head speed. But I haven’t figured out why yet. Perhaps a result of the coordinate system being off?

    • Also, I think having a G0 Z150 in the end g-code is helpful so it’s easier to remove the print, yes?

    • Out of curiosity, what are the coordinates set for in the homing settings of the printer? Maybe they sent some of them out with it set to 0,0. Mine is set for 152 and 75. In Slic3r, I have to set the center to an offset, and not zero. (I purchased my printer in December 2015).

  18. I gave this a try with a test part that is centered on the platter in Slic3r. When printing, the location was off to the right back corner, and some of the filament went off of the build plate.

  19. Anyone know where slic3r 1.2.9 stores the configuration settings? When I used the post-process script it crashes and I can’t open slic3r anymore even after deleting and re-installing. Poking around the internet and I can’t find it.

    I noticed a few having that problem here too and maybe someone can help me out.

    • If you are on mac and can’t open slic3r anymore, go to
      user/library/application support/slic3r/

      (on the finder, click “go to” (or “go” I don’t know in english), and hold alt key, you’ll see your library appear in the list)

      one of your FILAMENT, PRINT or PRINTER file is corrupted.
      Try deleting it all, “slicer.ini” included and restart slic3r.

      Be aware, you will lose all your presets !

      If you don’t want to lose all your presets, just copy your filament, print and printer folders on the desktop and delete slic3r.ini, then re-launch slic3r and but back your presets where they belong one at a time until you find which one went wrong.

      It worked for me.

      Cheers.

  20. Thank you for the description and the youtube tutorials!
    It works perfect with my CTC Creator Dual 😉

  21. Hi.
    My FlashForge Creator Pro did not lower the heatbed after printing, which forced my to lower it myself with the JOG function.
    So I asked on google groupes and someone suggested something that works perfect.

    Here is what he said :
    ”
    Add this line

    G1 Z150 F500 ; send Z axis to bottom of machine

    in between

    M73 P100 ; end build progress
    G162 X Y F2500; home X and Y axe ”

    Cheers

  22. So I just received my FFCP and the right single extrusion works fine. When I try to print with both extruders, nothing comes out of my left extruder. I should mention that I set it up how it was explained with Slic3r and i switched it to the dual extrusion but I keep getting an error that says M135 TO not recognized (I think, I’m not near my printer now) when I take that to ReplicatorG. But I hit continue any ways since I am somewhat new to this and it prints, just with the right extruder. can someone help me?

    • On the printer, use the load left filament option. Make sure filament is coming out of the left extruder. If it is, then it has to be something else, but that’s a good first test!

  23. It’s not a big deal but when I use the Left extruder it prints fine but after the “first layer” the right extruder heats up to the “other layers” temperature and the the Left extruder continues on at the “first Layer” temperature.

    Anyone have any idea why this is happening?

  24. Thanks for this complete description of your experience with Slic3r! It helped me to start using this nice slicer…
    For those that have problems with your Perl launcher script, if they are using Windows, they can try the batch file I’m currently using instead of installing Perl:

    @echo off
    setlocal EnableDelayedExpansion
    rem Strip extension “.gcode” from the argument
    set fname=%~n1%
    echo %fname%
    Rem Be sure to change the path to gpx.exe in the line below !
    C:/Slic3r/gpx-1.3/gpx.exe -g -p -m r1d %1 %fname%.x3g 2> gpx.log

    Copy it in Notepad, save it with “.bat” extension for example in the directory where you want the X3G output files to reside and, as for the Perl, script, put the complete path and batch filename in the “Print Processing/Post-processing scripts” text box.
    For example, my batch is named “run-gpx.bat” and resides in “C:\Slic3r\”. So in the “Post-processing scripts” box, I have “C:\Slic3r\run-gpx.bat”.
    This batch also saves the error output of GPX.EXE in the same directory. It will be called “gpx.log”. You should ALWAYS check it’s contents before using that X3G file, as some errors could have rendered the output file unusable. I had a problem with values defined in percents in Slic3r V1.2.9. They were passed as written, not interpreted, in the gcode file, so gpx.exe could not interpret them…

  25. If someone has still the issue with the post script not running, make sure you have no “copy and paste artefacts” in your script.
    When I checked my script I found out that the quotation marks were the wrong ones…
    If necessary just type the script letter by letter.

  26. First I want to say thank you very much to Jeremy for putting together this article and the videos.

    So I have gotten though some of the issues I have read in these comments, mainly the X & Y Offsets to get the printer to start in the middle. I can print the calibration cube pretty cleanly, but when I go to print the model for the 32mm Spool holder I have all sorts of problems. I have also tried the ball inside the cube print and had different problems.

    So in RepG I set my feedrate speed to 8 and the print speed to 50 and this works very well for the same ball inside the cube print. Trying to print the spool holder and a few other jobs, at the print speed of 50, it seems that it is way faster than with RepG. It prints the first line across the front of the plate and then when it gets to the end, it sits there for a second and a ball of filament forms and then it moves on to the skirt. IT then drags the ball and half that first line, into the print area and then get everything else messed up. That was with the same 50c plate temp. So I upped the plate temp to 75 and the first line stuck pretty good, but then after the first section of the first layer, it seems that it just starts gathering filament and it turns into this thick string.

    So Ive tried reducing all the speeds in Slic3r to around 10 and it seems that this is still happening and it seems like the speed is not really slowing down at all. This is all with PLA and extruder temp in the 200-220 range, Ive tried a bunch of temps.

    I printed the ball in the cube full size using slic3r and similar settings, I think they were bed temp-75, extruder temp-200, and the speeds down between 10 and 30. It was printing perfectly, and then at the 50% mark the print head went all the way to the left side jaring against the stop point and extruding stings of filament all over the place.

    Sorry I know this is a lot for a comment, but the forums seem to be pretty slow and its been days that I have been trying to figure this out. I know there probably wont be an exact answer, but I’m hoping that maybe either something major I missed in the setup, or maybe this is a simple answer.

    Any help is appreciated.

    • Are you trying to print PLA on the Kapton tape surface? That’s really optimized for ABS printing. For PLA, I’d recommend installing a glass build plate and spraying some AquaNet Extra Super Hold hairspray on the glass to help with adhesion. 60C bed temp should be sufficient.

Comments are closed.