-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Apparent regression in variable PA #6338
Comments
It looks like this ticket is a request for help (or similar). Many helpful people will not see your message here and you are unlikely to get a useful response. Instead, see the contact directions at: https://www.klipper3d.org/Contact.html We use github to share the results of work done to improve Klipper. We don't use github for requests. (In particular, we don't use github for feature requests, to answer questions, nor to help diagnose problems with a printer.) Please follow the directions at: https://www.klipper3d.org/Contact.html This ticket will be automatically closed. Best regards, PS: I'm just an automated script, not a human being. |
This is not a request for help, silly bot. It's a report citing a particular commit and describing the regression it introduced. |
As you surely noticed, this project has no possibility to open a new issue. To simply outsmart this fact seems rather brazen to me. |
@Sineos But apart from richfelker being a naughty boy, have you maybe considered fixing it? |
You might want to open a topic in Discourse as this is still not considered the right place to discuss it. |
No thanks, I'm happy with Danger Klipper. |
Opened thread in the proper place here: https://klipper.discourse.group/t/regression-in-dynamic-pa/17260 |
Commit 29724a7 moved the PA constant from being a property of the move to a property of the extruder. As far as I can tell, this broke configurations with variable PA, e.g. use of a lower K for bridges where there's no backpressure, by performing the integration with a single K that's whatever happens to have been the most-recent-set at the time of the iterative solver running, rather than using potentially differing-per-move K values in the integration.
My proposal for fixing this would be reverting the changes to chelper and the representation of PA K in trapq, and instead having the Python side copy the PA K from the relevant extruder object to the moves when adding them to the trapq.
The text was updated successfully, but these errors were encountered: