[Request] Ignore Retraction moves for clog detection

[Blendan1]

I'm having the issue that I keep getting false clog errors and I have narrowed it down to an issue with retractions. Every time it retracts a small amount of slack get introduced and with many retractions it builds up, and the encoder thinks there's a clog.

If there were an option of the encoder to not count retraction moves I'm certain the issue would go away.

[moggieuk]

The runout/clog detection only works in the extrude direction so retractions shouldn't make a difference. Extruding without retractions is easier for the encoder to see but doesn't chance the logic in the way this works. I wonder if you have a long bowden and the clog detection length is too short (perhaps tuned itself too short). You can adjust self-tuning parameters (desired_headroom) to give more tolerance or you can turn the autotuning off and set a longer static length.

I spent weeks experimenting and optimizing the detection a year or so ago and I'm sure it is as good as in can be right now. Happy to be proved wrong but I'd like to see some concrete debugging numbers from mmu_encoder.py -- the module that implement this functionality.

[Blendan1]

It only detecting in one direction might explain my issue even better:

If my retraction is 1.5mm and it retracts, the length of the tube to the mmu is long enough that the slack of the filament is enough that no movement happens at the encoder, so when it then continues to extrude, it won't detect any movement until the filament is tensioned again.

That would result in it measuring a bit less than was actually extruded.

I already tried using a headroom of 70 but that only delayed the issue.

I also confirmed that the issue does not appear if retractions are disabled.

If I'm mistaken and maybe there's something that I overlooked please tell me, I generally really like the clog detected but the false positives are quite annoying and make it hard to use.

[moggieuk]

You are correct that a retraction would "compress" the filament in the bowden, but the marked extruder runout position is not updated if it is smaller than that prior. This effectively means that retraction is not a factor. Please review the logic in mmu_encoder.py ( def _extruder_pos_update_event(self, eventtime): method). This is called every 0.25s to determine if any encoder movement is seen and will reset the "runout marker", but ONLY in a positive direction.

self.filament_runout_pos = max(extruder_pos + self.detection_length, self.filament_runout_pos)

I remember adding this last year for the very case you are citing...

[Blendan1]

What could my issue then be?

I already rebuild the encoder, used a different blinky, checked the cables, shielded the cables, checked the controller board and everything. I'm a bit at a loss as i was sure it was this issue, but if this is not possible then what could the issue be?

I also checked the extrusions and its not under extruding or something like that.

if you have an idea what it could be that would be great, otherwise i will just not use the clog detection.

thanks in advanced

[moggieuk]

Well, a headroom of 70mm is HUGE. That can only mean that the encoder is not functioning reliably...

EVERY time the encoder sends a single (can be in either direction) the runout/clog logic adds the "clog detection length" to the current extruder position. It only needs one pulse before reaching that point to prevent triggering...

What does MMU_ENCODER say is your current setting? This is mine:

> MMU_ENCODER
Encoder position: 0.0
Runout detection: Disabled
Clog/Runout mode: Automatic (Detection length: 10.4)
Trigger headroom: 15.4 (Minimum observed: 10.4)
Flowrate: 0 %

[Blendan1]

I'm currently printing and it already jumped up to this, could the issue be with the "Easy BRD" im using as i already changed the encoder and rebuild the encoder head? I'm also using the ERCF_Filament_Cutter. But the issue started to show a while after installing that one, But i'm unsure when exactly as i firs thought something else war wrong (clogged nozzle or something like that).

The gate statistics are a bit bad because i tried out something for better unloading and loading (that worked) but i haven't reset them since and the first gate is brocken, I need tho rebuild that one (but i don't have time for that now, and i rarely need more that 3 gates)

> MMU_ENCODER
Encoder position: 33.2
Runout detection: Enabled
Clog/Runout mode: Off (Detection length: 179.8)
Trigger headroom: 179.3 (Minimum observed: 177.9)
Flowrate: 0 %

Also here is a log from my current print, it seems like my retraction tests before where just a fluke. This happend on the first layer and with barely any retractions. It seems to always happen a certain while into the print then the headroom gets raised a lot and then it happens later on again and repeats.

mmu (2).log