Flashforge Creator Pro Setup Adventure and Troubleshooting Ideas

General Discussion
1

Basic Information:

Printer Model: Flashforge Creator Pro
MCU / Printerboard: Flashforge Board Rev D (Mightyboard Clone (mighty_one)
Host / SBC: Raspberry Pi 3B+
klippy.log

klippy(6).log (9.0 MB)

Describe your issue:

This is partly a continuation of the conversation that happened about 2 years ago in:

And partly a “draft” of a guide – with searchable keywords – that I want to have somewhere for posterity, in case anyone else dips their toes into this very frustrating hobby with this specific printer in the future.

I received an FFCP with Microswiss extruders and a borosilicate glass plate as a hand-me-down from a friend about a week ago, thinking it could be a fun way to start “making” and do more hardware-side tinkering. I’ve been lost in the 3D printing abyss ever since. Had no idea what I was in for.

Discovered Klipper, installed, spent days configuring it for the FFCP (and might actually have some material to contribute upstream in the example config and screen menus, I think :slight_smile:). Ran through the docs on the Klipper site for post-install, including rotation distance, configuration checks (PID Calibration for both extruders and bed), and Manual Bed Leveling (which, honestly, took some time to wrap my head around).

But I’ve been running into issues as I try and start printing. I was able to print a PLA calibration cube (after a single failed attempt – keep reading), but when I tried to do the same in ABS with OrcaSlicer defaults, the Pi would consistently crash mid-print (2 solid LED lights). I searched here and around online. Folks said it might be failing Pi hardware; ran the tests described here (including the wear-intensive IO tests), and passed them all with flying colors:

I saw folks talk about how it probably had to do with the 5V line between the two boards. Blocking it with tape meant the Pi couldn’t see the Autel board.

So I hoped it was an OS issue. I saw some threads here about overwriting dtoverlay, tried some of that. But it seemed to interfere with other Pi firmware settings in the mainsailOS image. Saw many folks describe weird USB issues when using mainsailOS images, so I opted to install “from scratch” on a clean Raspberry Pi OS Lite image using KIAUH, 32-bit Bookworm as this seemed safest.

It got farther along in the ABS calibration cube than ever. But still crashed. Dialed down max_accel and max_accel_to_decel under [printer] in printer.cfg, as well as some USB power settings in firmware; got further still. And for the first time, I got an actual error from the MCU:

Heater extruder not heating at expected rate
See the 'verify_heater' section in docs/Config_Reference.md
for the parameters that control this check.

Which was encouraging. I suspected it was because I calibrated the extruders at lower temperatures than the ABS cube was sliced for (I ran PID_CALIBRATE to 170, as described in docs), and I know that physics dictates that the speed at which something can heat up changes as one climbs up the scale.

So I tried calibrating to 260, as described in that initial thread. Pi crash.

At this point, it’s worth mentioning that I was feeding docs to LLMs throughout the process, so I could ask clarifying questions if something wasn’t clear to me. I took some of those threads, describing my troubleshooting methods and asking if they had any other ideas. One mentioned using a powered USB hub as a workaround to the 3B’s iffy USB controller.

I happened to have 2 powered USB 3.0 hubs laying around. One looked cheaper, but was capable of outputting more power to the ports. Figured it was a safer bet, but the Pi couldn’t “see” the MCU in /dev/serial/by-id/ when the printer was connected through the port. So I tried the second, and the MCU was consistently available.

And so, we arrive where I am now, where I’d like to get some feedback.

The Current Situation

The prints are still failing, but the Pi seems to stay alive throughout and I’m getting errors in Klippy. The main problem is that, at higher temperatures (>255 or so), I start getting thermocouple errors:

MCU 'mcu' shutdown: Thermocouple reader fault
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

If I don’t hit that error, I get the earlier not heating at expected rate error.

Conceptually my understanding is that:

  • I need to PID_CALIBRATE to higher temps so that Klipper knows what a realistic heat rate is.

  • The thermocouple/heater start reporting hardware faults at higher temps; the AI’s interpretation of the logs goes:

    This is the MAX6675 chip itself detecting an open circuit fault at the hardware level. All thermocouple readings showed fault=0 until the very end when it suddenly faulted at ~260°C.

    Root Cause: Hardware Electrical Noise

    At 260°C, the heater is running at full power (pwm=1.000) for extended periods. This creates electrical noise that interferes with the thermocouple’s µV-level signals. The MAX6675 occasionally misreads this as an “open thermocouple” fault.

My current thinking for workarounds for the mostly-stock config:

  • Add a [verify_heater extruder] block that is more forgiving of slower heat rates; maybe lowering the heating_gain and raising check_gain_time.
  • Under [extruder], increase pwm_cycle_time from the default .1 to something higher, to reduce the chance of interference. It’s probably that the stock Sailfish/Marlin firmware had this set lower when the printer was initially sold.

As for feedback: Is my understanding correct? Are these workarounds likely to help? Does anyone else have any other suggestions?

I’ve included a pretty long and messy klippy.log from the new install – MainsailOS logs are gone, but were also useless as they didn’t even show that the Pi knew it had died. They’re messy because I’ve been floundering through trial-and-error to this point :sweat_smile:. If any of it contradicts the story above, please just assume that my memories have melted together after several full days of cycling through research, LLM Q&As (with much skeptisism and correction), and “let’s see what happens” tinkering :melting_face:.

Thanks a ton, all!

P.S. I am away from the printer for a few days, which is why I am sitting here writing/thinking about it rather than working on it :slight_smile:. But that also means I won’t be able to try anything out for a while. I figured I’d crowdsource wisdom to make sure my understanding isn’t flawed.

1 Like
2

Update:

AI and I have been digging through the mainsail code and confirmed that all pins align to the mighty_one

And also discovered that one of the main strategies used by the mainsail devs to combat EMI in this poorly-insulated situation was using hardware timers to crank the PWM frequencies up to less-interfering levels.

There are 3 relevant timers on the board: Each extruder/fan is hooked up to one (Timer1, Timer4), and then the part-cooling fan and bed share another (Timer5).

Sailfish used the latter (Timer5) as the system timer, and opted for Software PWM on the bed at (much) lower frequencies. Then gave each heater their own timer (Timer1 and Timer4) at 976Hz. Likely because the cables connected to the pins associated with Timers 1 and 4 run parallel to the thermocouple wires in the umbilical, which makes them the most likely to interfere with readings, while 5 is routed much further away, to the bed (cooling fan, which is low amperage/EMI aside).

This is unusual, because convention (and Klipper) dictates that Timer1 be used for system scheduling.

On top of that, the thermocouple fault threshold used by Sailfish was 15 vs Klipper’s 3. And this is presumably with the Hardware PWM enabled

/// Number of bad sensor readings we need to get in a row before shutting off the heater
const uint8_t SENSOR_MAX_BAD_READINGS = 15;

/// Number of temp readings to be at target value before triggering newTargetReached
/// with bad seating of thermocouples, we sometimes get innacurate reads
const uint16_t TARGET_CHECK_COUNT = 5;

I’m not really interested in maintaining a fork of Klipper… but I think I’ll at least try out some source code mods in an unpstream-friendly manner and see if anyone else is interested in getting them upstream :slight_smile: