Posted 12 September 2021

I recently sold my MakerGear M3-ID and replaced it with a FlashForge Creator Pro 2 IDEX (FFCP2) model. The M3-ID was a great printer, but I could never get it to reliably print with dissolvable filaments. Since that was the entire reason I got the printer, I was more than a little bummed out. After viewing some very positive YT reviews of the FFCP2, I decided to sell the M3-ID and used the proceeds to buy my new FFCP2.

The new printer allowed me to successfully print water soluble PVA with PLA pretty much right away using the FlashPrint5 slicer that comes with the printer. However, after a few prints I started looking for ways to use the printer with either Simplify3D or with the Prusa Slicer, as the FlashPrint5 software is pretty buggy and suffers from really poor GUI design (for instance, the only way to specify the support extruder is via a right-click option in the plater view). This post is a description of my efforts so far to make this happen.

Some web research revealed that there was a FFCP2 profile for the Simplify3D (S3D) slicer floating around. This sounded like a good start, as I had S3D from well before from my PowerSpec 3D Pro (FlashForge dual extruder knockoff marketed by MicroCenter) days, and later with the M3-ID. In response to my emailed request, S3D sent me their FlashForge Creator Pro 2 17MR21.zip file containing just one file – FlashForge Creator Pro 2 17MR21.fff. After loading this into S3D, I was able to print a storage rack for a metric nut driver set fairly easily using a PVA dissolvable support structure.

So, now I could get away from the stupid FlashPrint5 slicer, but what I really wanted was a workable profile for Prusa Slicer 2.3. I use this slicer with my Prusa MK3S single-extruder printer, and I love it. Also, it is open-source, and quite actively developed by Prusa Research. Unfortunately, nobody seems to have developed a profile for PS2, and the process of doing so is not straightforward, at least to me.

After a LOT of reading through the Prusa FAQs and other support documents, I discovered there is already a profile available for a dual-extruder printer – the BIBO printer, so I thought I would try adapting it to use with the PS2. Here’s the BIBO profile, edited to change ‘BIBO’ to FFCP2 and other minor stuff.

By placing this file (FlashForge.ini) in

I was able to get Prusa Slicer to recognize the new profile and load it. However, when I tried to print a small 20mm cube (one that I had printed successfully using S3D), it appeared that the right extruder and the bed heated up properly and the movement codes were reasonable, but I wasn’t getting any filament extruded onto the bed.

Comparing the gcode from S3D with the gcode for the same model but sliced in PS, I found the following:

• The beginning of the start g-code sections were identical (no surprise, as I had copied the start/end gcode from S3D to PS), but the PS2 file had the following lines added

After that, both files contained LOTS of G1 commands, so I got lost pretty quickly. However, I could see that the PS code definitely contained code that should have pushed filament out of the extruder, as shown below:

But this code doesn’t actually extrude enough filament to make the model, as shown in the following photo:

I posted this problem to the Prusa Slicer section on the Prusa forum, and got a reply that triggered off yet another search through all the various slicer settings to see if there was something that might affect this issue. This time, however, I found a setting in the ‘Advanced’ section of the ‘General’ page on the ‘Printer Settings’ tab, as shown below:

After UNchecking the ‘Use relative E distances’ box, the demo cube started printing correctly – yay!

The Prusa-supplied informational flyover associated with this setting said ‘most firmwares use absolute E distances’ and ‘the default is absolute’ , so now I had to figure out where this unusual setting was coming from – the .INI file?

So, it turns out that the FlashForge.ini file, which I ported from the BIBO.ini file, did indeed have ‘use_relative_e_distances = 1’ in the [printer:*common*] section (and in a couple of other places as well). So, I edited the .INI file to change these settings from ‘1’ to ‘0’ and then closed and re-launched PS2 to confirm that the proper value changes were being picked up from the INI file.

There is still (at least) one mystery remaining, in that the little ‘padlock’ icon at the top of the ‘Printer Settings’ page still shows an ‘unlocked’ condition, even immediately after the initial load from the INI file. Don’t know why this is, but at least I’m one more step toward my goal of having a working FFCP2 profile for the PS2 slicer. Here’s the current .INI file contents:

15 September 2021 Update:

When I tried printing a simple 2-color 20x20x10mm cube using S3D, the actual print came out all in one color, even though I could see what I thought was a tool change gcode command in the gcode file. However, when I did this same thing in FlashPrint (FP5), it came out OK. So, I looked at the gcode commands in the .gx file emitted by FP5 and saw the following (after the binary thumbnail image code)

This shows that the FP5 slicer is using considerably different g-codes than S3D or Prusa Slicer. In particular I was dumbfounded by the first line – M118 X30.00 Y30.00 Z10.10 T0 T1 When I looked up the M118 command, it shows as a ‘serial print’ command, basically like “echo” in BASIC or other script languages. This clearly not right, as the M118 command used here is describing the overall dimensions of the model to be printed, including the skirt. Even after extensive web searches, I was unable to find much that described the syntax for the FlashForge usage of this command, except for one post in the Simplify 3D forum, talking about the FlashForge Adventurer 3, which had the following:

So, it appears that if this line is placed in the startup g-code section of S3D, then it will be placed in the start section of the gcode file, with the {} parameters replaced by the maximum X, Y, & Z values. I’m not sure that is actually what I want, as the FP5 output seems to be the entire size of the model, not just the half-dimensions.

16/17 September 2021

In my continuing quest to get my FFCP2 functioning with Prusa Slicer, I have been going back and forth between FlashPrint5 (FP5) – FlashForge’s proprietary slicer, Simplify3D which purports to have a FFCP2 profile, and Prusa Slicer, which purports to have a way of adding ‘vendor bundles’ to its configuration. Yesterday I managed somehow to screw up the S3D configuration so that it no longer prints with the right extruder at all, and in fact appears to be extruding from the left extruder while moving the right one – weird!

So, this morning I went back to basics and reprinted the 20x20x10 two-color cube .gx file from FP5, and verified that it worked properly – yay!

Next I reloaded the original unmodified S3D profile (FlashForge Creator Pro 2 17MR21) back onto S3D and printed the cube again using only the left extruder. This also appeared to work fine.

Next I tried the same cube using the original unmodified S3D profile and just the right extruder. This also worked fine.

Next I tried a two-color print in S3D using two processes – ‘LeftTop’ and ‘RightBottom’. I set ‘RightBottom’ to ‘Right Extruder Only’ and ‘stop printing at 3mm’. I set ‘LeftTop’ to ‘Left Extruder Only’ and ‘start printing at 3mm’. Then I selected ‘Prepare to Print’ and ‘Select All’ for process selection, but this time I said ‘Yes’ to ‘The selected process is not configured for the number of extruders you have chosen to use’, instead of the ‘No’ response I had selected before this test. When I did this, the print preview looked proper, with the right extruder shown for the bottom 3mm, and the left extruder shown for the top portion. However, the actual print failed – the bottom 3mm printed normally, but the right extruder continued ‘air printing’ after 3mm, and the left extruder first clashed with the right one, and then ‘air printed’ off to the left, like it was doing a duplicate print

I sent an email off to S3D support regarding this issue, and got a reply back saying that the problem was related to me changing the gcode flavor from ‘FlashForge Dreamer Firmware’ to ‘Makerbot’. So, I changed it back by reloading the original Flashforge profile, and tried this trick again. Got exactly the same result – the two heads crashed on the tool change.

Then I had an inspiration and tried using S3D’s ‘dual extrusion wizard’. First I created a 20x20x3mm solid in TinkerCad, loaded the model into S3D, and then duplicated it to get two separate cubes. Then I used the ‘dual extrusion wizard’ to stack the two pieces and assign them to different extruders. This worked great – yay!

So next I tried looking at the difference between the print file that worked (210917_20x3mm_S3D_DualExtWizV1.g) and the one that didn’t (20mm_2col_S3DorigFFProfile.g) and it basically boiled down to the startup gcode, and the tool changeover code. Here’s the startup code section:

The 4 commented-out lines are from the non-working print file, and the uncommented lines are from the file that worked. As can be seen, the working file set both extruders to operating temperature at the start, even though the left (T1) extruder isn’t used until the changeover point. Here’s the changeover code:

The commented-out M-commands were my attempt to get the left extruder up to temp but for some unknown reason I couldn’t get that to work. The line

was added to manually park the right extruder, as this was not done automatically by S3D (in fact, AFAICT the 2-process setup doesn’t even consider that each process could use a different extruder). The ‘M108T1’ command is the same as the one found in the ‘Dual Extruder Wizard’ print file. With the above changes, I was able to successfully print the 20x20x20mm cube with the first 3mm printed by the right extruder and the remainder printed by the left extruder, as shown in the following photo:

So, to summarize progress to date, I believe I have figured out that the ‘dual extruder wizard’ in S3D does a good job of handling the extruder switch, but the ‘manual multiple process’ method does not. I also figured out that – contrary to a number of web postings about the FFCP2, at least the S3D profile with it’s ‘FlashForge Dreamer Firmware’ setting for gcode flavor is correct.

22 March 2022 Update:

Early this month ‘jacotheron’ posted a comment to this article, asking if I would share my Prusa Slicer work so far. I said ‘sure’ and sent him off the FlashForge.ini file I had created by copying the BIBO printer configuration and editing it. This exchange started a long conversation between me and Jaco Theron of South Africa. Jaco was also interested in using the Prusa Slicer software to run a FlashForge Creator Pro 2 IDEX machine, and being a heck of lot smarter than me, he was actually making significant progress! In just a few days he had a working version of a Python script to convert PS gcode output to the required *.gx format required by FFCP2. Of course I volunteered to test it, and once again embarked on a new voyage of discovery.

Jaco had already put together a very complete GitHub repo for this purpose, and the Readme documented the required support software installation (Python and a couple of extensions). First and foremost, I didn’t know Python and didn’t have it on my Windows 10 system. After some inet research I felt like I knew enough to take a stab at doing the installation. Of course, even with Jaco’s very detailed instructions, I managed to run into several potholes on my way to Python nirvana.

The first step is to download and install Python (3.10.3 is the latest version) from https://www.python.org/downloads/. However, since I almost always accept all the default selections when installing a new program, I didn’t check the ‘Add Python to your PATH statement’ checkbox and boy did that leave a mark! Because I hadn’t checked this box, The ‘post-processor’ command in the FlashForge.ini file couldn’t find Python, and I couldn’t even run it from a normal command-line console. I tried modifying the PATH statement myself (you’d think that would be easy – what could possibly go wrong?) and again failed – Rats! Somewhere along the line I picked up on the fact that Python was also available from the Microsoft store – so I though “Aha – that’s the ticket! So, I uninstalled Python, and re-installed it from the store. That installed fine, and I wasn’t asked about the PATH statement, so I think Microsoft did that by default. Nope – it didn’t, and now I could not only not run Python from the command line, but apparently the Microsoft version was well out-of-date – bummer! Alright, so next I uninstalled Python (anyone keeping score?) and re-installed again from Python.org, being VERY CAREFUL to check the ‘add Python to PATH’ option, and this time it all seemed to work – yay!

One good thing did result from all my thrashing around – I learned about using the Python ‘pip’ command to install and update other packages like Pillow (also required for the Python script). Here’s a screenshot showing this process:

The next part of the process involved placing the FlashForge.ini and the Python post processor script ‘ff-creator-post-processor.py’ in their respective locations, and then modifying the the FlashForge.ini file’s ‘post-processor’ line to point to the Python script. I used the ReadMe recommendations from Jaco’s Github repo directly for the location of these two files, as shown below:

And the modification to the ‘post-process’ line (line 80) in FlashForge.ini:

If you use the folder locations as I have above, you should be able to use this post-process line, changing only ‘Frank’ above to your user name, (and possibly ‘Python310’ to ‘Python311’ or ‘Python32’ or whatever is current at that time).

After getting all this to work, there was one more hurdle (or maybe two if you count the Prusa Slicer ideosyncracy described below); The FlashForge Creator Pro 2 firmware does not like long filenames, and Prusa Slicer loves them. Once Jaco figured out what was happening, he modified the post-processing script to shorten them to something the printer could handle. What this means to the typical PS user is – Don’t freak out when the filename you thought you were getting is not what is on the SD card! There was one last hiccup in this regard when I used the default filename for a 3D Benchy print, which came out as

after the post-processing step. This produced the dreaded “file opened failed” error when I tried to print it. When I shortened the filename to ‘_3DBenchyDualPrint.gx’ it printed fine. I passed this along to Jaco, and he has undoubtedly fixed this problem by now.

So, after all this, I was able to print my first ‘Benchy’ in dual-color splendor. Actually it was a pretty crappy print, but it certainly showed me why Jaco recommends enabling the ‘draft shield’ option as shown below:

For the life of me I couldn’t figure out why this option was called ‘draft shield’ when its purpose seemed to be a lot more like an ‘ooze shield’. I finally twigged to the idea that the ‘draft’ in ‘draft shield’ related to wind drafts causing the print to cool off too quickly. However, this puts an image in my head of someone trying to do 3D prints on their front porch in a high wind, but what do I know 😛

One last thing. Prusa Slicer has a couple of idiosyncrasies that you normally don’t see until you start working with multiple extruders. The first (and most frustrating) one is that Prusa Slicer refuses to allow objects on the build plate to be moved in the Z-direction, which means you can’t stack parts to do a simple 2-color cube, for instance. There is a trick, however. First you add the first part to the print bed, then right-click on that part and select ‘Add Part’ from the context menu. Then add the second part from the resulting dialog. The part added this way can be moved in the Z-direction. It’s a kludge, but it works.

The second idiosyncrasy is even crazier. When multiple extruders are defined, a ‘phantom’ part appears on the print bed, as shown below:

As you can see, this part isn’t on the object list on the right, and it cannot be deleted! As it turns out, however, this catastrophe is caused by Prusa Slicer having ‘Wipe Tower’ enabled by default for multiple extruder prints, and not also placing it in the object list to give us poor users a chance to figure out where it came from. To rid yourself of this plague, disable ‘Wipe Tower’ as shown:

So, thanks to Jaco Theron’s hard work, those of us with FlashForge Creator Pro 2 IDEX printers now have a pretty reasonable (and getting better by the minute) free alternative to the truly dreadful FlashPrint5 that comes with this printer. Thanks Jaco!

Just as an aside, I’m an old broke-down retired engineer from the 70’s, so much of my professional life was spent without benefit of the internet.  Every so often now I realize how much more productive the inet makes us. How cool is it that an old fart from Ohio and a young engineer from South Africa can so easily collaborate to improve a software package written by a company in Czechoslovakia to support a completely different 3D printer.  An improvement that will be immediately available to everyone in the world!

Stay tuned,

Frank