PID loop improvements

[mikeshub]

Description

This pull request adds a few improvements to the PID loops.

• #define MIN_POWER & #define MIN_BED_POWER

The biggest improvement on this PR is to temp changes when doing double nozzle prints. If the new temp is less than the PID functional range this won't have much impact. However, if the drop is more than the functional range this change helps significantly with the undershoot of the target. The logic behind this new define is that to heat a nozzle it needs power. Therefore the power should never be completely off when the error is within the functional range. Now the nozzle undershoots by only a couple of degrees instead of 10 - 15 in some cases.

This value is pretty easy to obtain. Enable PID debug output. Set the lowest temp a hotend or bed will be used at and wait for the PID loop to stabilize. Make note of the output. Set the define to 10 to 20 lower than the value where the loop stabilized at.

• Bed loop works like hotend loop

There is no reason that the functional range should be ignored by the bed PID loop. This change has led to much faster settling times as the target temp is reached without the I term being saturated. Now that they work the same would it make sense to get rid of the bed loop and have all the PID work done in one place? I can make a strong arguments both for and against on that. I am leaning towards don't combine them.

• PID debug output cleaned up

There is no reason to debug two hotend PID loops at once. Only outputting the info for the active hotend makes reading or capturing to a text or CSV for graphing far easier. I can't come up with a scenario where one would need the output of both loops simultaneously. If there is one, what is the benefit of making the vast majority of use cases worse to accommodate a random edge case that will most likely never even happen?

• Fix the autotune output - for real this time!

I have no idea why this one got rejected on one of my previous PRs. You can try yourself if you are a "seeing is believing" type, but take my word for it the "no overshoot" tunings are the only useable ones for the PID autotune on the bed. The other two result in unstable loops. The oscillations do not become unbounded, but they do not stop with the classic tunings. The classic is still the best for the hotend tunings. This change will allow the end user to use M303 and the U flag to have good tunings for their bed. Why would we not want this?

Benefits

See description.

Related Issues

Most likely none. I doubt word has gotten out that the bed PID loops are now usable as I've been making these PRs for my personal use with no fanfare.

It looks like the temp files got some love while I've been sorting out my upgrade to SKR1.3 on my Creator Pro. I'm in way too deep right now to resolve this, but can in a day or two once I have what I'm working on put to rest. If someone felt like resolving this for me I would greatly appreciate it.

[thinkyhead]

would it make sense to get rid of the bed loop and have all the PID work done in one place?

For now if it won't save significant CPU or SRAM then it's fine to leave it as it is. In the future it will be nice to have all the PID heater-plus-temp-sensor units on the same footing. Another PR discusses making a class to embody PID. I'm thinking a small set of mix-in classes could work.

[mikeshub]

Cool thanks!