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!

12 August 2024 Update:

I recently acquired a new Windows 11 laptop and discovered that I no longer had the ability to use Prusa Slicer to do prints on my Flashforge Creator2 Pro IDEX printer- yikes! My choices seemed to be a) dive down the ‘rabbit hole’ to solve the problem, b) return my brand-new Dell XPS15 9530 laptop for a refund and forget the whole thing, c) commit suicide, or d) all of the above :). Because I’m a old broken down engineer with too much time on my hands I chose “a) dive down the ‘rabbit hole’ to solve the problem” (‘b’ was out because my 30-day grace period had elapsed, but I kept ‘c’ in mind too!)

Thank goodness the three-year younger version of me had the forethought to document this, as it was immensely helpful in ‘loading up the buffers’ with previous knowledge’. In particular, I had forgotten about Jaco’s Github repo, so getting that hint saved a lot of time.

Looking around on Jaco’s site, I found this ‘issue’ post – “worked in super slicer but not in prusa 2.6.1 #11′. In the comments, I found this:

I was running into a similar problem with Prusa Slicer 2.8.0.
I would put the FlashForge.ini and .idx files in …/Roaming/PrusaSlicer/cache/ and …/Roaming/PrusaSlicer/cache/vendor, but as soon as I started Prusa Slicer the files would be deleted.

Below is a workaround that finally ended up working for me:
-Close PrusaSlicer
-Remove all FlashForge files from

any folders in …/Roaming/PrusaSlicer
-Install PrusaSlicer 2.6.1
-Follow above steps detailed by @Kingston-C:

From Kingston-C:

I believe that Prusa changed the way it reads vendors in 2.6+.

A workaround I found is to place “FlashForge.ini” inside of the PrusaSlicer’s AppData folder (typically on Windows at “C:/Users//AppData/Roaming/PrusaSlicer/cache/vendor/”). Then, in this same location, make a copy of any .idx file and rename this file to “FlashForge.idx”

I hope this helps!

-Start Prusa Slicer and add the printer
-Make sure slicing and exporting work
-Upgrade Prusa to newest version

Whatever Prusa 2.8.0 didn’t like about the .ini files seems to be fixed during the upgrade process.

The comment about PS2.8.0 not liking the older .INI file/folder arrangement rang true to me, as my old laptop was still able to process STL files for my CreatorPro2 IDEX with PS2.8.0 installed (hence my complete disbelief that the same setup didn’t work on my new laptop!).

The very first thing I did was verify (again!) that my old laptop did indeed play well with my CP2 by printing out a small calibration model – check!

The next thing was to UNinstall PS2.8.0 from my new laptop and install PS2.6.1 per the above notes. As an aside, the Prusa repo has installers for their latest (PS2.8.0), but not for earlier versions – they just offer a ZIP file. So, I didn’t so much ‘install’ PS2.6.1 as expand the ZIP file to a folder and then just run PS2.6.1 by double-clicking ‘prusa-slicer.exe’.

In my previous (unsuccessful) efforts I had installed Python 3.12.5 using the default install options (plus the ‘admin’ and PATH options), and this put python.exe way down in ‘c:\users\Frank\AppData\Local\Programs\Python\Python312\’, which made for a real long line in the post_process line in Flashforge.ini (to be fair, that’s what happened on my old laptop and the long path didn’t cause any problems, but….). In any case, per the above notes I chose the ‘custom install’ option this time and (with the ‘admin’ and ‘PATH’ options still checked), installed Python at ‘C:\Python312’ leading to a much more readable ‘post_process’ line in Flashforge.ini.

Next I had to install Python’s Pillow library. The ‘Readme’ does say ‘Using Command Prompt’ run the following two commands:

but I missed the ‘Command Prompt’ part and tried to run these commands from inside python – didn’t work :(. Once I figured that out and used Windows command prompt, it still didn’t work. Some more research revealed that the ‘python’ in these commands should be replaced by ‘py’, making the commands

The ‘upgrade pip’ command was a bit redundant in my case, as I had just installed the latest version of python, but the ‘upgrade Pillow’ command was absolutely necessary.

After this, I downloaded and unpacked the latest ZIP file from Jaco’s github repo. Then I placed ‘ff-creator-post-processor.py’ in ‘C:\Users\Frank\AppData\Roaming\PrusaSlicer\post-processor’, and ‘Flashforge.ini/.idx’ in ‘C:\Users\Frank\AppData\Roaming\PrusaSlicer\vendor’.

Then I edited the post_process line in FlashForge.ini to read:

Then I fired up PS2.6.2 again, and now the ‘FlashForge FFF’ option is available in the config wizard, as shown in the screenshot below:

And the CreatorPro2 options show up in Prusa – yay

And, even more fantastic, I was able to successfully process an .STL file for printing on my CP2, and even more amazing, the print came out perfectly (I would have accepted even a lousy print, so the print quality was a bonus!).

So, the last step in this drama is to upgrade PS from 2.6.1 to 2.8.0 and find out whether or not all my work will stay in place – fingers crossed!

Fail! PS2.8.0 popped the following error:

And now the config wizard doesn’t show the FlashForge FFF item, and when I clicked on the still-visible ‘CreatorPro2 Left Extruder Only’, PS2.8.0 crashed :(.

Interestingly though, although the ‘FlashForge FFF’ entry no longer shows up in the config wizard display in PS 2.6.0, I can still see (and select!) all the CP2 configuration choices, and I can still process gcode files properly – yay!

So, screwing around a bit, I saved a copy of ‘BIBO.idx’ as ‘FlashForge.idx’ in the ‘C:\Users\Frank\AppData\Roaming\PrusaSlicer\cache\vendor’ folder, and then re-launched PS2.6.1. This time the config wizard showed the ‘FlashForge FFF’ printer, and I can still see (and use) the CP2 options. Not quite sure why, but even though there is a ‘BIBO FFF’ printer item shown in config wizard, the various configurations don’t show up in the ‘printer’ drop-down box.

Well, I can live with PS 2.6.1, but I’d really like to get back to the newer features with 2.8.0, so I’m going to try again to run 2.8.0. Fingers crossed (again)!

Well, good news and bad news; 2.8.0 came up OK, and I could see the CP2 configuration choices, and I could process a file for the CP2. However, when I saved the processed file to disk, I got another Prusa Slicer error as shown

When I dismissed the error message, PS2.8.0 didn’t crash immediately, and I could still see (and select) the CP2 entries in the ‘printer’ drop-down box. However, when I tried to run the config wizard, PS2.8.0 hung up for a long time, and then produced the same error as above. After dismissing the error window the config wizard came up, but without the ‘FlashForge FFF’ entry. Cancelling the wizard still let me use the CP2 config entries, so that’s a plus. I ran the config wizard again, with the same long hangup and the same error message, thinking this time I would click on ‘Finish’ rather than ‘Cancel’. However, I couldn’t even get that far, as the config wizard (and Prusa Slicer) were hung, and I had to kill the whole thing. Brought 2.8.0 back up, and didn’t run the Config wizard, but still got the same ‘preset bundle version not found’ error after 10-30 seconds. Dismissing the error window allowed me to see and use the various CP2 options. I think for the moment I’m going to leave everything where it is. I don’t really need the config wizard, and dismissing one error message is a small price to pay for having the advantages of 2.8.0.

Summary:

I now have PS 2.8.0 working on my new PC, albeit with a one-time error message popping up each time I launch the program, and no ability to use the config wizard. For the moment at least, that’s good enough.

16 July 2024 Update:

Well, that didn’t last long; shortly after I typed the above summary, PS2.6.1 started crashing it was game over for the current iteration. And, it was about this same time that I noticed that I have actually been running PS2.8.0 on my older laptop – with the Creator Pro II (alias “FlashForge”) profile and without any problems – wtf?

So, I decided to start over (again). This time I uninstalled or deleted all PS installs just to be sure (PS2.6.1 wasn’t ‘installed’ – I was running it from the expanded release folder from Github). Then I uninstalled Python312 (it didn’t like some deprecated syntax in Jacothery’s Python profile) and downloaded/installed Python310. Then I copied over my Flashforge profile from my old box to my new one, downloaded PS2.61 (again) and fired it up. Right away I was able to see the CreatorPro2 selections (yay!), but when I sliced a test file and tried to save it, PS popped an error as shown below:

Yuk, down the rabbit hole again! However, by this time I had figured out how to run the post_processing script in Visual Studio in debug mode – not perfectly, but enough to get a clue, and the clue led me to understand that I had pulled a major boner and not installed Pillow, the Python Imaging Library – oops (and this clue hit me on the forehead right after I posted an issue at the Prusa Slicer Settings repo, so I had to follow up the post with a mea culpa). Anyway, I installed Pillow, and suddenly all was well – at least in PS2.6.1. I was able to load an STL model into PS, slice it, save it in proper .GX format to an SD card, and then print the model on my CP2 – yay yay yay!

Then I crossed my fingers and allowed the upgrade from PS2.6.1 to PS2.8.0, and – amazingly – it worked! So now I have both my old and new laptops running PS2.8.0 and both are fully capable of supporting my CP2 printer – whew!

Stay tuned,

Frank

Frank