# Flashforge Creator Pro (2016) Slic3r settings

Hi,

I have been using my FFCP for about a 30 days now and have been struggling to get Slic3r to work 100%.

Everything seems pretty good except my left extruder is off by the offset of the two extruders. I followed this video and used all his settings.

I think there is differences between the older model he is using and the 2016 version. I have Sailfish v7.8

Does anyone have the g-code for the start and end left and right they could share for the (2016) version?

I have been printing with this but when the printer starts the head hits the front left side as if it is trying to keep moving until it’s heated up. As long as I make sure the prints are in the center I can get them to print but I can’t use the whole print bed.

Thanks

1 Like

Have you tried Flash Print, made for creator and dreamer, I use it a fair bit, you can tweek settings.

When you install it and first run you select Creator Pro.

That easy,

I have no trouble with it with my Creator, actually, it does a better job on some prints than Simplify3D.

I worked for a while trying to get Slic3r to work but had canned the project. I may get back to it one of these days when I have time.

Simplify 3D works great with these printers.

Have you reset your offset and ran the print to calibrate?

http://www.sailfishfirmware.com/doc/tuning-dual-extruder-calibration.html

You must set the extruder offset. You can find the exact offset number online by Googling about it. Just type in “Flashforge creator pro extruder offset.” and it should come up. This will fix your issues.

I’ve got three of the 2016 FFCP printers, also running Sailfish v7.8. And though I use Cura instead of Slic3r, I’ve found that, at least with it, you don’t need to enter an extra offset. When you send the G-Code command to select the other tool, the printer automatically shifts by the offset amount preprogrammed in the firmware.

I originally tried to follow various tutorials online, as you did, where it said to enter the offsets, but that only caused it to be shifted because both the slicer and the printer was adding the offset. In fact, you can take a .gcode file that was setup for the right-extruder, edit it manually to change the tool from T0 to T1 and make sure it sends a “M108 T1” command (select tool T1). When the printer receives that command, it automatically shifts the position to the T1 tool offset. Then run it through GPX to the printer and then it will print with the other extruder, which proves no additional offset is needed since the X/Y coordinates in the rest of the gcode still had the original displacement.

My guess is that somewhere along the way they switched from requiring the slicer to add the offset to having the printer/firmware itself do it, since it seems to be different from the vast majority of tutorials out there online.

You can fine-tune the offsets by doing the calibration print and entering offsets in the setup screens via the LCD/Keypad. But beware, some versions of Sailfish (can’t remember if it was v7.8 or one of the others I’ve used) has a floating point to integer conversion issue. If you go through the process of entering which line is the best on the calibration print where it calculates the correction based on the line index, it will calculate an incorrect value and suddenly you’ll have an offset of like 32768mm, which works about as well as you’d think. And the only way I found to recover that was to go to the manual screen where you enter the specific correction in mm and hold down the button until it ticked back down to the 0.xxx something range (took forever!).

So the best way to tune it is to figure out which line is best and manually calculate the offsets and set it from that on the manual correct screen rather than use the firmware’s fancy “enter the best line” function. My experience is that there are some pretty serious bugs like that in Sailfish… Though despite that, in general, Sailfish works pretty well for printing.

Oh, and you asked for example start/end gcodes. Here’s what I’m using on Cura:

*** Begin Start GCode ***

M103 (disable RPM)
M73 P0 (enable build progress)
G21 (set units to mm)
G90 (set positioning to absolute)
{IF_BED}M109 S{BED} T0 (set HBP temperature)
{IF_EXT0}M104 S{TEMP0} T0 (set extruder 0 temperature)
{IF_EXT1}M104 S{TEMP1} T1 (set extruder 1 temperature)
(**** begin homing ****)
G162 X Y F2500 (home XY axes maximum)
G161 Z F1100 (home Z axis minimum)
G92 Z-5 (set Z to -5)
G1 Z0.0 (move Z to “0”)
G161 Z F100 (home Z axis minimum)
M132 X Y Z A B (Recall stored home offsets for XYZAB axis)
(**** end homing ****)
G1 X-110.5 Y-74 Z50 F3300.0 (move to waiting position)
G130 X20 Y20 Z20 A20 B20 (Lower stepper Vrefs while heating)
M6 T0 (wait for toolhead 0, and HBP to reach temperature)
{IF_EXT1}M6 T1 (wait for toolhead 1, and HBP to reach temperature)
G130 X127 Y127 Z40 A127 B127 (Set Stepper motor Vref to defaults)
{IF_EXT0}M108 T0 (Select extruder 0)
{IF_EXT1}M108 T1 (Select extruder 1)
G0 X-110.5 Y-74 (Position Nozzle)
G0 Z0 (Position Height)
G1 E4 F50.0 (Create Anchor)
G1 Z15
G92 E0
*** End Start GCode ***

*** Being End GCode ***

M73 P100 ( End build progress )
G0 Z150 ( Send Z axis to bottom of machine )
M18 ( Disable steppers )
M109 S0 T0 ( Cool down the build platform )
M104 S0 T0 ( Cool down the Right Extruder )
M104 S0 T1 ( Cool down the Left Extruder )
G162 X Y F2500 ( Home XY endstops )
M18 ( Disable stepper motors )
M70 P5 ( We <3 Making Things!)
M72 P1 ( Play Ta-Da song )
*** End Stop GCode ***

My only “bug” with these on Cura is that if you are using the Fan, Cura will output the fan commands with T0 for the tool which causes it to inadvertently switch back to the other extruder. My present “workaround” for this is to simply edit the gcode file and change the fan commands to T1 when using the other extruder, which works, but is a pain in the @. Eventually I’ll get unlazy and create a better solution.

Anything else you have to do to get Cura set up?

Thanks so much I will give the additional G-code a try. I had tried the offset in Slic3r and it had no affect on the position.

Thanks,

I have played with flash print as well, I find it doesn’t do a very good job of printing g and have played with many settings to try and improve. The biggest issue I have with it is with when it move to start the next layer it doesn’t extrude for the first 2-5mm and just has a bit of filament come out. Then when it fi idles the exterior and moves to the infill it leaves extra filament which results in a very bad seam. Of all I have tried replicator g has worked the best. Slic3r is very good as well for the most part. Would love to buy Simplify 3d but it’s over 200 cad. I’m new to this so I keep watch in video to learn more.

I have not rest the offset in the firmware. I assume it’s is correct as it works fine in all other slicers I’ve tried except Slic3r. I have down loaded Cura and might give it a try. The more I play the more I learn

The firmware on the link is for v7. 2 the printer came with 7.8. I believe the manual said not to try and upgrade as it might cause issues. I have tried flash print but haven’t gotten the best results yet. I am also using octoprint with Slic3r and love it. No more moving the SD card back and forth and I can watch e what is happening on my phone

Are you on the latest version of Flashprint? It has worked decent for me.

You can try upgrading and/or modifying the firmware, but one thing you’ll definitely want to do first is make an exact backup of both the flash and eeprom data for your existing setup. That way, if the upgrade goes bad (which it easily could), then you can always flash the original firmware and eeprom back in and be right back to where you started. So many people don’t do that and then no longer have the original flash copy to return to and end up with either a non-functioning or poorly functioning printer as a result.

Just use ‘avrdude’ to copy it (Google it if you aren’t familiar with ‘avrdude’ – it comes with the Arduino IDE and/or on Linux you can install it via ‘sudo apt-get install avrdude’). I used the following two lines to read mine. The first one reads and saves the flash and the second the eeprom:

avrdude -p m2560 -P /dev/ttyACM1 -c stk500v2 -b 57600 -U flash:r:FlashForge_flash_orig.hex:i

avrdude -p m2560 -P /dev/ttyACM1 -c stk500v2 -b 57600 -U eeprom:r:FlashForge_eeprom_orig.hex:i

The arguments are case-sensitive. You can probably get by without the baud rate specifier (the “-b 57600”) or the protocol specifier (the “-c stk500v2”) since ‘avrdude’ should get those from the avrdude.conf file from the “m2560” processor specifier, but it never hurts to explicitly list those.

And also, this is on Linux. On Windows and/or Mac, you’ll need to change the /dev/ttyACM1 to the correct USB device name for your printer’s connection. Windows it’s probably a COM port number specifier. On Mac it will probably be something like /dev/cu.usbmodem1A21 or /dev/tty.usbserial-A6004byf, etc… And even on Linux it could be something different, like /dev/ttyACM0 or /dev/ttyUSB0, etc. It should be the same USB port path you use to communicate with the printer via USB.

This will give you two files, FlashForge_flash_orig.hex and FlashForge_eeprom_orig.hex with your original flash and eeprom images, respectively. Then if your firmware upgrade goes wrong and kills your printer, you can repeat the above commands but change the ‘r’ on the -U option to ‘w’ for write and reflash the files back into the printer, which will work as long as you don’t somehow destroy the bootloader in your printer’s M2560 processor in the process of updating your firmware. The bootloader should be locked to make it difficult to accidentally delete (assuming FlashForge properly set the lock bits when they initially programmed things).

Worst case if you do stomp on the bootloader is you’ll have to get an ISP (in-system-programming) cable and connect directly to the ISP port of the processor (the 6-pin header connector near the center of the MightyBoard between where the two crystals (metal cans) can be seen. There’s two ISP connectors, one for the M2560 and one for the 8u2/16u2 processor – be sure to attach to the correct one). And then you can manually reflash the processor without a bootloader. But chances are low that you would accidentally stomp on the bootloader.

But yeah, if you don’t save a copy of the flash and eeprom, then yes, I agree with your quote from the manual – “don’t try and upgrade as it might cause issues” (of which you can’t recover without the original firmware copy – and it’s hard to find an original firmware image if you didn’t save it off yourself).

And you mention OctoPrint. I’m using OctoPrint too and on a Raspberry Pi (OctoPi). In fact, I ran the above ‘avrdude’ commands above on the Raspberry Pi itself to save off the printer’s firmware. You can do the firmware saving with any “computer” – whether it’s your desktop/laptop or a Raspberry Pi or something.

Sailfish 7.8 is the latest and there is no real reason to mess with it. If you are going to, make sure to get the Sailfish manual.

I down loaded it a few weeks ago so it should be the latest

I have not tried Flashprint lately but I could probably on Friday - maybe sooner. If you want to find a STL to try I can get it also and see how it goes. I know my FFCP’s run great with S3D so they should be in good shape to run Flashprint. We can compare results with similar setting etc.