ACE 2 overfeeds into U1 toolhead and crushes filament, repeated on multiple heads (v0.99.8b)

[1841979-beep]

Setup

• Snapmaker U1 firmware: 1.5.2.13
• multiACE: 0.99.8b based custom build; loading and feed-assist code matches public v0.99.8b
• One ACE 2 Pro, protocol V2
• ACE firmware reports V1.1.3O. This is an ACE2-Open build derived from stock V1.1.31. Its documented changes are RFID-only, but I list it as a separate variable until the flashed binary is hash-checked.
• PLA, ACE dryer approximately 50 C, chamber approximately 42 C
• feed_speed 80, retract_speed 80, load_length 1400
• seat_overshoot_length 20, load_retry 3, extrusion_retry 7
• wiggle_scheme EAEAEAE

Problem

This is the third similar incident within approximately one week. It has occurred on T0 and T3 and repeated after installing a new replacement head.

The filament becomes flattened or buckled inside the PTFE/toolhead path and is chewed by the toolhead gears. In one incident it was forced sideways out of the normal path. The audible clicking starts after the filament has already jammed.

During one print, the T3 entry sensor became false while the ACE still reported filament present. The nozzle was stable at 221/220 C and no MCU, CAN or thermal fault was recorded. The print paused, and four automatic reload attempts failed to reach the head sensor.

After cleaning and reassembling the head, a controlled load reproduced the failure. The head sensor became true, but no plastic exited the nozzle and the extruder clicked.

Timing observed during the controlled load

• ACE transport started at approximately 16:31:06.465 with a 1400 mm command at 80 mm/s.
• The e3 sensor became true at 16:31:07.398.
• The v0.99.8b load path has an unconditional approximately 4 second wait before it begins polling the head sensor.
• The earliest possible stop was approximately 16:31:10.67.
• This leaves approximately 3.27 seconds, nominally up to 262 mm, of commanded feed after e3 had already detected filament. Actual physical movement is unknown because the ACE buffer and resistance are not measured.
• The head was still below 100 C when the filament reached e3.

After heating, the recovery sequence continued with the seat move, 16 extrusion probes of 20 mm, and seven E/A wiggle cycles. Every wheel check remained 1 -> 1, and coil delta was only 279 to 969 against a 5000 threshold. No extrusion was detected, but the retry sequence continued.

The final error was: "filament reached but no plastic comes from nozzle."

Suspected mechanism

ACE pressure or feed assist pushes filament into a blocked or not-yet-ready toolhead path. The filament buckles or flattens near the drive gears. The subsequent extrusion retries and wiggles grind the already damaged strand and produce the clicking sound.

This appears closely related to #109 and may also share part of the ACE2-specific behavior reported in #57.

Questions

1. Can the fixed 4 second wait be replaced with immediate sensor polling and a verified stop command?
2. Should the recovery terminate after the first confirmed no-wheel-movement result instead of continuing all extrusion retries?
3. Should resistance_pause be enabled by default for ACE2?
4. Is disabling print-time feed assist for ACE2 currently the recommended safe workaround?
5. Which sanitized log sections would be most useful for diagnosing this?

I can provide exact timestamped excerpts from multiACE state logs and klippy.log. No private network addresses need to be included.

[JReacher2]

Mmm.. I had an issue similar to this a couple of times on the ace 1. Only this happened while the tool head was extruding fine. I had to extract the filament after an air print error and noticed it was all crushed and curled . The filament was extracted manually without much effort and upon reloading the tool head worked fine. I attributed the issue to the filament since it only happened to one specific roll

[decay71]

Hi,

Two things you can do right now, both effective immediately:

Lower feed_speed. The overrun is a fixed span of about 3.3 seconds, so it scales with speed: at 40 mm/s it is roughly 130 mm instead of 260, at 20 mm/s about 65. Loads take longer, 35 seconds instead of 17 for 1400 mm at 40 mm/s, which is a fair trade until the fix ships. load_length does not help here, the feed is stopped by the sensor, not by the length.

After a failed load, unload fully before trying again. The problem only bites when the filament is already close to the head, which is exactly the state after a failure. ACE_UNLOAD_HEAD first puts the whole bowden between the ACE and the sensor again, and the fixed wait is harmless over that distance.

On my side: the fix is to poll the head sensor from the first iteration and keep the wait only for the readiness check. Small change, but it touches the load path of every setup, so it goes through hardware testing here first. The early abort of the retry ladder on a flat zero flow reading is a second, separate item I will also look at.

The wait dates back to the very first multiACE version. SnapACE, which multiACE grew out of, fed in 100 mm steps at 20 mm/s and polled the sensor immediately. multiACE replaced that with a single long feed at 80 mm/s, and that exposed a second exit in the loop: right after the feed command the ACE has not started moving yet and still reports "ready", so the loop would end at once and treat the load as done. The 4 second wait was the guard against that, with the comment "wait for ACE to start motors". It was never revisited for the case where the filament arrives before the wait is over, which only happens on a reload with filament already near the head, exactly your recovery case.

[decay71]

multiace0.99.8bfeedfix.zip

Please test this patch.

What was fixed: The load loop slept a fixed 4 seconds after the feed command before it started polling the toolhead sensor. If the filament reached the sensor inside that window, the ACE kept pushing until the sleep ended, against a stationary, cold extruder, up to 262 mm. That crushed the tip at the extruder inlet and the drive gears chewed it afterwards. Only the "filament already close to the head" case was affected: every retry inside the load loop and a reload after a fault. A normal load was never affected.

What changed: The sensor is polled from the first round, the ACE is stopped within 0.1 s of the sensor edge. The 4 seconds remain only as a guard against a premature "ACE ready" report and no longer delay the stop. Hardware-verified: sensor reached at 3.0 s and 3.4 s of feed time, stop sent after 99 ms and 83 ms.

Install: copy both files to /home/lava/klipper/klippy/extras/, then FIRMWARE_RESTART. Without /oem/.debug the copy does not survive a reboot.