-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Ignore Retraction moves for clog detection #428
Comments
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 ( 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 |
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. |
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
I remember adding this last year for the very case you are citing... |
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 |
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
|
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? 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)
Also here is a log from my current print, it seems like my retraction tests before where just a fluke. |
The encoder isn't working correctly. The clog detection headroom should not be above about 20... |
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.
The text was updated successfully, but these errors were encountered: