-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Klipper velocity pid #6272
Klipper velocity pid #6272
Conversation
Signed-off-by: Daniel Sherman <[email protected]> Signed-off-by: Vinzenz Hassert <[email protected]>
This pr is part of the effort to break PR 5955 into smaller commits. |
Is it intentional that this code:
got reduced to this:
? |
Yea it's intentional, The derivatives don't need to be zeroed, and since they are smoothed it's better thast they aren't. |
One small change I would make is to change it to this:
That way the edge case of having a target temp below 0 is also covered |
I'm not sure if you can actually request a sub 0 temperature. from my quick test in mainsail, I get an error. |
Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html There are some steps that you can take now:
Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available. Best regards, PS: I'm just an automated script, not a human being. |
@KevinOConnor can you assign a reviewer to this? |
Looking forward to finally have a non-broken PID heating in Klipper. Maybe another half a year and then it'll be merged. |
Been testing this, in my (anecdotal) experience, and after recalibrating my PID values with it enabled, my temperatures do seem much more stable. Instead of overshooting at initial heating by ~1C (I have recalibrated multiple times in an enclosure with stock PID implementation, it never went away), it now gracefully reaches target and stays within +/- 0.1C. Variance before was usually +/- 0.5-0.8C during the course of the print. It does take slightly longer to reach the target (e.g., 5-8 seconds longer for a target of 245C at the extruder), but I'll take that over a more oscillatory/variant overall temperature. |
To chime in i can confirm similar results to @scottmudge on my hotend using a 60watt on a volcano block. prior it would take a bit to setting now it just coasts up to target. Albeit the settle time wasn't overly long just not great in comparison to pid_v. enclosed pic is pidtuning then ramping up to target 240 |
Just to remark that: This velocity pid algorithm seems not working very well if you (as in my example) calibrating the hotend with pid_v for 210 °C and then try to set a target temperature of 240 °C. The temperature drifts step by step upper and didn't settle back to 240. I also have a volcano hotend with 64W heater. But it works, if the target temperature is the one calibrated. In contrast, the base pid algorithm has no problem with the same task. So it seems like it has it's pros and cons. |
The common detail i keep seeing between 2 printers. is on 1 my (dc) bed is
/ heavy insulated bult also 30v. i have to fix regular pid by hand. or use
older fixs with smooth time to keep pid off long enough for it to cool it
ticks power on every now and then. this lead to it taking 10-20 mins to
start .Otherwise it usually required fully turning off to cool then reheat
to "target" so things like pla ended up problematic where higher temp
materials the bed could drop temps fast enough. . The other printer i dont'
see a large difference on the bed. regarding the hotends id agree with
highwatt / low thermal mass improving. i have this behavior on a rapido ,
and 70w volcano clone block (abit thinner) these used to take slightly
longer to "settle" vs coast up and start printing. So it seems like it
should be a "extra option" to accommodate varying hardware. but perhaps
suggest if its needed to use pid_v hardware should also be looked at to
ensure it assembled correctly. no loose thermistors / underspec psu etc.
sorry for typos in advance if i typed this to quickly im at work.
…On Mon, Aug 7, 2023 at 11:05 AM freakyDude ***@***.***> wrote:
Just to remark that: This velocity pid algorithm seems not working very
well if you (as in my example) calibrating the hotend with pid_v for 210 °C
and then try to set a target temperature of 240 °C. I also have a volcano
hotend with 64W heater.
But it works, if the target temperature is the one calibrated.
[image: pidv-c210-s240-i243]
<https://user-images.githubusercontent.com/32776748/258888382-ba007b7e-095d-416f-b410-63cc992f18c2.png>
In contrast, the base pid algorithm has no problem with the same task. So
it seems like it has it's pros and cons.
—
Reply to this email directly, view it on GitHub
<#6272 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AR4KIEDALV5SJHFNG62KX33XUEU6VANCNFSM6AAAAAAZU2MWXQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@freakydude. We should have different results since i failed to mention Im using a semi proprietary clone. This also drops temps more rapidly with connected block supports to a large aluminum plate. (v400 design) Not quite ideal much harder to heat properly. As apposed to the intended e3d design or how phaetus goes about it.. To add further clarity. but i suppose alloy would be the other variable since as far as i know e3d has a special blend on their aluminum blocks vs generic clones. |
@freakydude what you are seeing is a side effect of the old pid calibration algorithm. I have not seen this when the new calibration method was used, but that won't come till after the pr is mainlined. |
Could be true, I tested your "big" pull request a (long) while ago. And I can't remember seen this problem. I could retest the same case if wished to double check? |
You can if you want to! |
Thanks. As high-level feedback, the code seems fine to me. I have some questions on the high-level impact of this change. How should a user choose the PID parameters for pid_v? Do they just use the same pid parameters that they were previously using for How should a user determine if they should choose Similarly, just for my own information, what kinds of heaters do you expect would benefit the most from pid_v? For example, heated beds vs extruders, high power extruders, heaters that can change temperatures rapidly, etc. I'm not sure how to evaluate the high-level benefits of making this change to Klipper. On the one side it may help users that are struggling with a heater that is not robust with the current PID code, but on the other hand it may add unnecessary complexity for users. (That is, there is a risk that many users spend time researching and testing pid vs pid_v, but find that they don't observe a real-world quality difference with either choice - thus resulting in lost time for users.) Do you have recommendations on tests that users could perform and the metrics we should look at to evaluate the overall benefit? An example of a metric and goal would be something like: Cheers, |
As indicated by other comments, I see the same pattern on my machines:
They seem to benefit from What I can also confirm: Both implementations currently perform worse when tuning the PID at a low setpoint, e.g. hotend at 210°C and then go to 270°C. But I always tune my PID at the high end anyway, and have not noticed any adverse effects when going lower. What I really miss from the previous implementation is the (a)symmetry value during auto-tuning, which can be interpreted as a heat gain / heat loss ratio. I see this as a real added value, since it allows improving the hardware in a more targeted way, i.e. to give the user an indication if the system would benefit from insulation and/or more power. In my opinion, it gives the user a choice: If in the abundance of different constellations / systems |
@KevinOConnor After further testing or rather different hardware scenarios/printers. It may be wise to add a description regarding wat general thermal characteristics may need 1 or the other. On what i'd call a faulty volcano clone with large thermal loss using pc inserts / steel screws going into a large plate. Pid_v doesn't seem to heat quick enough to deal with slicer fan changes in some scenarios. However if its "proper" (no supports leaking alot of heat) Id be overshooting slightly with regular pid which pid_v solves. The other scenario pid_v solves my heavy insulated dc bed at 30v being unable to settle or drop temps for ages , unless i fix the values by hand. My regular bed without insulation / usual 24v however i see no benefit per say. So it would seems quite hardware dependent either, option should seems to be able to handle a plethora of hardware scenarios. Such as the issues with certain beds needing smooth time fixs / ac beds. otherwise 'most" beds probably work better under pid. As mentioned the variable seems to be insulation / high-power. Otherwise on hotends power to thermal loss. In my situation id be using pid on the clone hotend/proprietary effector if i were a regular user. However, Once i fix the thermal loss i'll be returning to pid_v (replacing the support screws with titanium / or complete removal like the regular e3d volcano design.) |
That's' correct, they use the same parameter's for pid_v as they would pid. The only caveat to that is that' pid_v is less forgiving of a noisy signal, or a bad tune/calibration (and that will be corrected with the modification of pid calibration).
On a hot end
On a bed
Second, I would say they should decide if they are ok with the temperature fluctuations they see when the heater is up to temp. If the heater has a decent tune/calibration pid_v generally shows less deviation from the target temperature. For a hot end that means more consistent extrusion, and for a bed that means less z banding.
Imo, to many variables are at play to be able to make any kind of definitive statement about who will and won't see a benefit.
I'd say to look at the things I mentioned in the response to the "How should a user determine if they should choose |
That's to be expected imo. If you tune low you will get parameters aimed at holding the heater at the lower temperature. Higher temperatures require more aggressive parameters, because you will be loosing heat to the surrounding environment faster. |
@dans98 re "Imo, to many variables are at play to be able to make any kind of definitive statement about who will and won't see a benefit" Yes agree. From the look of varying scenarios. Probably a few hardware situations in docs should provide a degree of examples. So far on a few machines ive seen 1 or the other reported behaviors. Another thing that has come up, |
Okay, thanks. I guess my high-level feedback is that I'm not sure how to judge how useful this change is for users in general. It doesn't seem to be a "must have" in that the current PID generally works for most users (it's certainly not optimal, but PIDs rarely are). Without being able to quantify an improvement it's hard for me take on additional code complexity. (I also don't think users want to spend time and effort choosing between "unoptimal PID algorithm A" vs "unoptimal PID algorithm B".) Also, I guess you are saying that the only way users will know to use pid vs pid_v is to try both and see how long each one takes to stabilize on a particular temperature? -Kevin |
They need to look at the initial overshoot, and how well it does at maintaining steady state. |
A stand alone pr the contentions the minimum amount of changes required to incorporate the velocity pid control algorithm.