Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Heating Fails after PID takes over #248

Open
Thinkersbluff opened this issue Apr 19, 2021 · 52 comments
Open

Heating Fails after PID takes over #248

Thinkersbluff opened this issue Apr 19, 2021 · 52 comments
Labels
t:bug Something isn't working upstream-bug

Comments

@Thinkersbluff
Copy link

Thinkersbluff commented Apr 19, 2021 •
edited
Loading

UPDATE 27 Aug 2021 - Separate PID RANGE values coming soon. Meantime, good advice from thinkyhead on how best to mitigate this issue on the upstream bug [BUG] "Heating Failed" after PID takes over MarlinFirmware#21661.

Description

The nozzle temperature sometimes fails to reach the target value when heating.
When this is happening, the temperature may climb to within a few degrees of target, but then drops again, cycling around a center value approximately 10 degrees below target. Eventually, the system throws a yellow "Heating Failed" message on the screen and "kills" the job, forcing the user to cycle power to recover.

Steps to Reproduce

I was able to reproduce this problem fairly consistently as follows:

  1. Connect Octoprint to the printer & monitor the serial interface and the Temperature plot to observe what happens
  2. Use the CF6 PID function to PID the nozzle at 235C
  3. Wait for the nozzle to cool to 145C (or set the temperature to 145C, to let it stabilize there.)
  4. Use the CF6 esteps function to run a calibration extrusion at 235C.
  5. The printer recognizes and reports on the serial interface that the target temperature is 235
  6. The printer stops short of 235 when heating, instead cooling again around 230C
  7. The printer then cycles around approx 225 +/-5 degrees, never trying to achieve 235, as seen in the attached logs.
  8. If left long enough (sorry, did not time it), the printer throws a Heating Failed alert and kills the process.

Expected behavior:

At step 5 or step 6, the printer should overshoot 235, and gradually settle on to it, after a ring or two.

Actual behavior:

The printer never gets to the target value.

Logging:

wtf
wtf.txt
wtf2
wtf2.txt

Additional Information

Hardware = Stock Creality Hot End, BTT SKR CR6 v1.0 Motherboard, Stock Creality TFT, Octoprint on RPi3B+

Running this CF6 Pre2 as offered in Assets section, with no mods:
CF6.1-Pre2-btt-skr-cr6-with-stock-creality-tft-2021-04-18-22-12.zip
@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 19, 2021

Can you please report this upstream? I try to stay clear of thermal control code.

@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 19, 2021 •
edited
Loading

I am surprised that noone upstream seems to have noticed this issue. It went so well last time, when you were able to show them the error in their code. I had hoped you could see this one, too.

I will give it a go & see what reaction I get.

[UPDATE: Upstream ignored the issue I posted, but I found another closed one that sounded very familiar. The way Marlin calculates PID values may be flawed and the way it uses them may also be flawed. Since temperature.cpp continues to “work” for most users and the code is quite arcane, upstream seems loathe to investigate and validate the code.
The experimentation documented below explores whether editing some configuration.h parameters can help “fix” the bug described here by putting PID Autotune back into a “stable” operating range with this hot end.]

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 19, 2021 via email

@Thinkersbluff Thinkersbluff mentioned this issue Apr 19, 2021
Closed
@Talha909
Copy link

I have the same issue. I am using 12 April bug fix. Yesterday I try to do PID but its fails. And it does reach to desire temp. It always below 10 degree.

@Thinkersbluff
Copy link
Author

I have the same issue. I am using 12 April bug fix. Yesterday I try to do PID but its fails. And it does reach to desire temp. It always below 10 degree.

@Talha909 Are you using the Community Firmware on a CR6 or are you saying you have a problem running 12 April 2021 Marlin bugfix2.0 on something else?

@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 19, 2021 •
edited
Loading

Maybe this has something to do with that temperature is now measured in whole integers instead of floats.

I am suspicious of the 10 degrees part.
Can you tell in the code whether this code in Temperature.cpp is causing PID to turn off the heater when the nozzle gets within 10 degrees of target?

if (temp_hotend[ee].target == 0
|| pid_error < -(PID_FUNCTIONAL_RANGE)
|| TERN0(HEATER_IDLE_HANDLER, heater_idle[ee].timed_out)
) {
pid_output = 0;
pid_reset[ee] = true;

If the integer roundoff error were to "trick" PID into turning off the heater too soon, I could understand it cooling when it should be heating. It is beyond my "skills" with software & logic to decide whether that Functional Range parameter (defined as 10 in Configuration.h) could cause the PID routine to settle 10 degrees short of target if round-offs "went the wrong way" during the heating cycle. I know that last test I ran, the PID suddenly went up and achieved target when it had been looking like it would settle 10 deg lower...

#define PID_FUNCTIONAL_RANGE 10
// If the temperature difference between the target temperature and the actual temperature
// is more than PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max.

I am away from my system today, but am tempted to try redefining that parameter to something like 5 and seeing what happens.

[UPDATE: It turned out that I was on the wrong track with this theory, but looking at one of the right parameters. It needed to go higher, not lower]

@portals999
Copy link

I'm using CR6Comm-CF6-Final-cr6-se-v4.5.3-mb-2021-03-27-15-53 and can confirm I too have this issue, I never saw the problem until I got a new 4.5.3 board and upgraded to CR6.

The temp drops to 10C below what you set it to and hovers around there on the heating and homing screen until the yellow heating error screen appears shortly after.

It is always approx 10C too low and I can consistently reproduce this issue.

Interesting theory re 'Functional Range parameter (defined as 10 in Configuration.h)'.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 19, 2021

Workaround for now appears to be:

  • Reset to factory settings and use default PID values or
  • Increase the temperature in the leveling settings.

@Sebazzz Sebazzz added t:bug Something isn't working upstream-bug labels Apr 20, 2021
@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 22, 2021 •
edited
Loading

@Sebazzz - I ran some tests today with PID_FUNCTIONAL_RANGE set to 5 instead of 10. [UPDATE: I later found advice that this parameter needed to be larger, not smaller. ]

Does it tell you anything important that I was now able to complete a full eSteps calibration, although the temperature never stabilized at 235? (i.e.: Instead of throwing a "Heating Failed" error message, the printer proceeded with the extrusion, then beeped and asked me to measure the remaining filament. )

NOTE: In Test 1, I have just flashed a new build of Rel6.1_Pre2, from the Source.zip files, with the ONLY change being that I have modified the PID_FUNCTIONAL_RANGE parameter from 10 to 5. BUT I forgot to perform a factory reset, so the results may not reflect that change & may be using the previous PID values (I also forgot to query M301 before starting... :( sorry.
I did Test 4 to try to make up for that a little. Looks like the temperature oscillations with a PID_FUNCTIONAL_RANGE of 5 are not enough to trigger the "Heating Failed" detector. For some reason, though, temperature also never tries to converge on a steady state value either. Instead of a damped "ringing" response, it just oscillates happily at a constant wave height.

pfr=5_Tests1-3
PID_FUNCTIONAL_RANGE=5_Tests1-3_LOG.txt

pfr=5_Test4
Test4_LOG.txt

[BTW - esteps calibration ignores the filament runout sensor, because I had no filament in the machine & the runout sensor light was out, but the printer said nothing.]

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021 via email

@Thinkersbluff
Copy link
Author

Here is a second series using PID_FUNCTIONAL_RANGE = 2.
In both tests, the printer threw a Heating Failed warning.

pfr=2_Tests 1-2
PID_FUNCTIONAL_RANGE=2_Test1-_LOG.txt
PID_FUNCTIONAL_RANGE=2_Test2-_LOG.txt

@Thinkersbluff
Copy link
Author

In stark contrast to the above demonstrations, PID works correctly in CF6 Prel 6 (pre Marlin bugfix2.0 commit "Add typedef celsius_t MarlinFirmware#21374"):

PreBug#248
Before Bug#248.txt

What a difference a few significant figures after the decimal place can make...

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021 via email

@Thinkersbluff
Copy link
Author

You might want to add that to the upstream bug. Met vriendelijke groet, Sebastiaan Dammann

Yep. Working on it. Using "Compare" to try to identify all of the bugfix2.0 commits that differentiate Pre6 from 6 Final.
Do you already have that list compiled or available somewhere?

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021

You say the issue isn't there in pre6 right?

Comparison between pre6 and final

Comparison between pre6 and 6.1 pre2

@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 22, 2021 •
edited
Loading

You say the issue isn't there in pre6 right?

It is not there in rel6 pre6
It is there at rel6.1 pre2
Facebook Group Users are reporting issues at rel6 final, but this particular bug is not evident in my test.

PreBug#248-6f
Before Bug#248-rel6f.txt

This does seem to implicate the Marlin PR "Add typedef celsius_t (MarlinFirmware#21374)"
Not wanting to fall prey to confirmation bias, though, I would like to update the upstream bug with an accurate and complete list of all of the differences between CF6 Final and CF6 Pre2.
Is that a github compare report you can make persistent with a link I could paste?

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021

@Thinkersbluff Yes, the Github compare URL just wants two git commit IDs or references to commit ids like branch names, tags etc.

@Thinkersbluff
Copy link
Author

Perfect, thanks. I used my "new skills" to update the upstream bug.
Is it worth it to you to create a test fork of CF6 that only incorporates that one PR#21374 into Rel6Pre6, to try to prove this theory?

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021 •
edited
Loading

On my first Kickstarter CR-6 with "CF7-Nightly" with distribution date "2021-03-27" I have this graph:

image

Unfortunately, I can't check when I compiled the firmware. For now, assume this was a pre-temperature fix build.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021

Is it worth it to you to create a test fork of CF6 that only incorporates that one PR#21374 into Rel6Pre6, to try to prove this theory?

I can do the git magic and push a temporary branch.

@Thinkersbluff
Copy link
Author

Is it worth it to you to create a test fork of CF6 that only incorporates that one PR#21374 into Rel6Pre6, to try to prove this theory?

I can do the git magic and push a temporary branch.

I think that would help us corroborate or disprove this theory. I think it would help to be able to say that was the only difference between bug and no bug.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021

@Thinkersbluff Pushed a temp/celcius_t branch:

image

If you happen to use a command line git client:

git fetch origin
git switch temp/celcius_t

@ztakis
Copy link

ztakis commented Apr 22, 2021

13 confilcted files. Should I do it?

image

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021

You are trying to merge the branch in your local branch. Instead, you need to switch to the branch.

@ztakis
Copy link

ztakis commented Apr 22, 2021

Ahh yes. Thank you

@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 22, 2021 •
edited
Loading

There's this universal "law" that my British parents called, "Sod's Law".
I think I just proved that my most recent test method needs revision. (Or this may suggest that the bug is further upstream than we thought...)

I just got this result from testing Rel 6 Pre 6:
BUG248+Rel6Pre6
bug248-rel6Pre6.txt

Maybe this demonstrates the Facebook Group's situation, in which a user claims if he does a PID with CF6, he sees this bug, but if he resets to factory settings, his problem goes away...

I think the PID function generates p, i & d based on what it had to do to get the nozzle to achieve & stay at target temp.
If the nozzle is already close the the target temp (in my test case it was already at target temp) then the resulting parameters may not be aggressive enough to get PID to work when starting from a much lower temp...

I do not know, yet, whether this is a red-herring generated purely by a bad test procedure or whether this is another useful clue.

Thank you for the custom build.
I hate using command lines... I have Windows GitHub Desktop.
I see the origin/temp/celcius_t branch
I have a BTT SKR CR6 board, so I have copied the folder onto my C drive, to let me edit the configuration files without impacting yours.
Thank you.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 22, 2021

@Thinkersbluff You are using the BTT SKR board right? Make sure the firmware was flashed (firmware.bin renamed to firmware.cur). On a stock Creality board, I would change the version in Version.h and check afterwards.

@Thinkersbluff
Copy link
Author

Thanks, yes. I wish it was only that...
NOTE: The system is doing an excellent job of keeping me straight on all this flashing. (Sooo glad I put that extension cable into the display, way back when..) I get excellent feedback between the flashing led and the messaging, to ensure that I have the right builds installed in every configuration.

@Thinkersbluff
Copy link
Author

Testing is now showing me that the problem I am able to consistently reproduce is present in both Rel 6 Pre 6 and Rel 6 Pre 6 + PR MarlinFirmware#21374.

The perpetual temperature cycling shown in this graph is consistent with the behaviour that some users are describing as, "hovering about 10 degrees below the target temperature".

Custom Build Test 5
custombuildTest5.txt

It appears as though the PID routine in the latest bugfix2.0 of Marlin is not generating "effective" PID parameters.
Although my earlier testing seemed to show that this bug was not present in Pre 6 Rel 6, I must now revise that assessment in light of these results:

Rel6Pre6 Test 5
Rel6Pre6-Test5.txt

@Thinkersbluff
Copy link
Author

This upstream issue seems to be related: MarlinFirmware#20463

@Thinkersbluff
Copy link
Author

@Sebazzz - I notice that the default PID parameters for the Creality and BTT board machines are different in the CF6 configs, although their stock hotends would be the same. Is this intentional?

image

@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 23, 2021 •
edited
Loading

Based on this data, I believe the problem here is that generating the right PID values is not as simple as entering a target temp and pushing the button. I do not yet understand how Marlin decides what parameters to recommend, but I do know that the numbers I am getting with PID E0 S245 C8 U1 are definitely not the right ones.

CustomBuild_PIDDEBUG_245C
CustomBuild_PID DEBUG_245C.txt

If anyone else already understands the Classic PID algorithms and/or has a standalone commercial PID system with which they can generate the "right" values here, that would be great. Otherwise, I am packing for a long long long deep dive down a rabbit hole...

@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 23, 2021 •
edited
Loading

After reviewing this work and recommendations uploaded by descipher on the Marlin bug MarlinFirmware#20463, I ran a couple of tests with two modifications to the Configuration.h settings:

The smoothing factor is highest as the value approaches 0.5 if you prefer to see a high level of smoothing try around 0.55 to 0.45. You can expect a slightly slower ramp up to the setpoint but a high level of stability.
My best results are with
PID_K1 0.52
PID_FUNCTIONAL_RANGE 16
EXTRUDE_MINTEMP 160
30W 12V heater, ATMEGA2560 RAMPS 1.4, 100k Thermistor
Seeing +1.5 -1.5 on the startup ripple, with stable follow on +- 0.20 fluctuations via PID_DEBUG output.

I have made no attempt to optimize these two parameters (PID_K1 & PID_FUNCTIONAL_RANGE), but preliminary testing on my system does suggest that the "bug" we are chasing here may be addressable by tuning the Configuration.h file.
For reference - the Configuration.h file for BTT SKR CR6 with stock display contains:
PID_K1 = 0.95; PID_FUNCTIONAL_RANGE = 10; Kp: 14.3200 Ki:0.8100 Kd:63.1200

CustomBuild_PIDDEBUG_245C
CustomBuild_PIDSmoothing55
CustomBuild_PID SMOOTHING pt55.txt
CustomBuild_PIDSmoothing95_Range16
CustomBuild_PID SMOOTHING pt95Range16.txt
CustomBuild_PIDSmoothing55_Range16
CustomBuild_PID SMOOTHING pt55+RANGE16.txt

@gerd35 gerd35 mentioned this issue Apr 23, 2021
Closed
@Thinkersbluff
Copy link
Author

Thinkersbluff commented Apr 23, 2021 •
edited
Loading

In these tests, I evaluated the ability of my printer to heat and stabilize the nozzle at three different print temperatures (235C, 205C and 180C), using the same set of PID parameters at each temperature.

In the first plot, the PID values are those currently in the CF6 BTT MB configuration files
In the second plot, the PID values are the ones from the previous test series that seemed to perform best.
In the third plot, the PID values are the ones currently in the CF6 Creality MB configuration files.
In all 3 of the plots, the PD_K1 factor was set to 0.55 and the PID_FUNCTIONAL_RANGE factor was set to 16.

CustomBuild_PIDSmoothing55_Range16+BTTpidKs
CustomBuild_PID SMOOTHING pt55+RANGE16+BTTpids.txt
CustomBuild_PIDSmoothing55_Range16+bestpids
CustomBuild_PID SMOOTHING pt55+RANGE16+bestpids.txt
CustomBuild_PIDSmoothing55_Range16+CRpidKs
CustomBuild_PID SMOOTHING pt55+RANGE16+CRpids.txt

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 24, 2021 •
edited
Loading

@Thinkersbluff Thank you for your extensive testing. Can you describe your testing procedure (or I've missed it)?

Upstream PR MarlinFirmware#21678 has flowed down to this codebase, so it might be worth re-testing. Make sure you're on the extui branch (if you're still on the temp branch) and then pull in the latest changes.

@Thinkersbluff
Copy link
Author

@Thinkersbluff Thank you for your extensive testing. Can you describe your testing procedure (or I've missed it)?

Upstream PR MarlinFirmware#21678 has flowed down to this codebase, so it might be worth re-testing. Make sure you're on the extui branch (if you're still on the temp branch) and then pull in the latest changes.

The test procedures and logged data are in the text file below each graph. It took me a bit of trial and error to settle on a consistent approach. The PID tests show that Marlin’s Autotune is not delivering “good” parameters with the current default PID_K1 and PID_FUNCTIONAL_RANGE parameters. Changing them both makes the Autotune converge smoothly to target but leaves minor ringing.

I will try the latest extui later. All of these tests were done with the integer temperature values, which likely smooths that ringing, but I expect we still need to address those two PID parameters.

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 24, 2021

@Thinkersbluff With the latest merges it is even more unstable 😐

@Thinkersbluff
Copy link
Author

I think we have to consider that the results I am posting here may only be valid for machines with my configuration. They may even only be valid for my machine. I did not have any failures while running my specific tests. These tests take a lot of time and effort to execute and document, so I am hoping that other users will be willing and able to run similar tests on their systems and give feedback if they have problems.
Based on these tests, though, recognizing that I can not explain the results I am seeing, only present them, I am encouraged to think that one feasible work-around that would allow us to proceed with Release 6.1 testing would be to make these two changes in Configuration.h:

  1. Change PID_K1 smoothing factor from 0.95 to 0.55
  2. Change PID_FUNCTIONAL_RANGE from 10 to 16

Here are the plots and data that lead me to recommend that. Once again, the test procedure and the logged results are in the .txt file below the related plot:

6 1Nightly24Apr21_PID_K1-95_RANGE-10_DefaultKs
6.1Nightly24Apr21_PID_K1-95_RANGE-10_DefaultKs.txt
6 1Nightly24Apr21_PID_K1-55_RANGE-16_DefaultKs
6.1Nightly24Apr21_PID_K1-55_RANGE-16_DefaultKs.txt

@Thinkersbluff Thinkersbluff mentioned this issue Apr 25, 2021
Open
@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 30, 2021

@Thinkersbluff Please check this - possibly related MarlinFirmware#21743

@renegadecitizen
Copy link

I just got this error
On stock firmware too (I haven’t yet updated to the community firmware)
I fixed it by turning the hotend fan off
Lol
Crazy I know, but it works
Maybe you can explain this?

@Sebazzz
Copy link
Collaborator

Sebazzz commented Apr 30, 2021

@Thinkersbluff Merged to extui and extui-bugfix-2.0.x. It seems to me temperature is more stable now.

@Thinkersbluff
Copy link
Author

Today I made time to test PID and Autotune in Release 6.1, Prerelease 3. I waited too long before capturing the first plot & lost the initial Autotune run with the default PID values, but it did look the same as the curve in the center of the graph. I am not getting Heating Failed warnings any more, but the Autotune is still clearly undershooting twice before achieving the target temperature.
6 1Pre3_PID_K1-95_RANGE-10
6 1Pre3_PID_K1-95_RANGE-10_part2
6.1Pre3_PID_K195+RANGE10.txt

@maximustiberius
Copy link

I'm having the same problem.

Just updated from stock firmware to CR6Comm-Rel_Final... and getting undershooting of nozzle temperature after PID calibrating... Just about worked the second time after turning off fan for PID.
Untitled

@Thinkersbluff
Copy link
Author

Thinkersbluff commented May 6, 2021 •
edited
Loading

I'm having the same problem.

Just updated from stock firmware to CR6Comm-Rel_Final... and getting undershooting of nozzle temperature after PID calibrating... Just about worked the second time after turning off fan for PID.

@maximustiberius - Your curves look similar to those I reported here:
https://user-images.githubusercontent.com/36551518/115781148-00d87e80-a388-11eb-9c95-a50fdc53de80.png

I have also been doing PID with the fan off.

I have a couple of questions for you that might help the Marlin developers troubleshooting this bug.

  • Did you also get a Heater Failed warning/shut down event on that effort where the temperature never achieved target?
  • Which motherboard is now in your printer?
  • Are you still using the stock CR6 hot end originally delivered with the printer, or have you replaced or modified your hot end?
  • Did you try this same test using the stock firmware? (PID could be commanded by sending M303 S240 E0 U1 via the terminal.)
  • What happened if you did test the stock firmware?
  • Which version of the stock firmware did you test? (The Creality firmware is also based on Marlin, but it is a much earlier version than the Community Firmware. It might help to reveal how far back this bug was introduced into Marlin.)
  • If you do a factory reset of the PID values, what does the nozzle temperature curve look like, when you try printing at 240? (There may be two separate issues, here - 1. The PID may not calculate "good" numbers. 2. Marlin PID Autotune may not converge well at target temperatures, even with "known good" values.)

I am curious what K values your PID routine generates. Notice that I report my values on the graphs, in case there is a clue in that information.

@maximustiberius
Copy link

I'm having the same problem.
Just updated from stock firmware to CR6Comm-Rel_Final... and getting undershooting of nozzle temperature after PID calibrating... Just about worked the second time after turning off fan for PID.

@maximustiberius - Your curves look similar to those I reported here:
https://user-images.githubusercontent.com/36551518/115781148-00d87e80-a388-11eb-9c95-a50fdc53de80.png

I have also been doing PID with the fan off.

I have a couple of questions for you that might help the Marlin developers troubleshooting this bug.

  • Did you also get a Heater Failed warning/shut down event on that effort where the temperature never achieved target?

i got the heater failed warning a previous time, but in this graph, I cancelled the print!

  • Which motherboard is now in your printer?
    4.5.2
  • Are you still using the stock CR6 hot end originally delivered with the printer, or have you replaced or modified your hot end?
    Stock
  • Did you try this same test using the stock firmware? (PID could be commanded by sending M303 S240 E0 U1 via the terminal.)
    yes... no problem with PID on Octoprint terminal
  • What happened if you did test the stock firmware?
    worked fine
  • Which version of the stock firmware did you test? (The Creality firmware is also based on Marlin, but it is a much earlier version than the Community Firmware. It might help to reveal how far back this bug was introduced into Marlin.)
    Latest Creality firmware for CR6
  • If you do a factory reset of the PID values, what does the nozzle temperature curve look like, when you try printing at 240? (There may be two separate issues, here - 1. The PID may not calculate "good" numbers. 2. Marlin PID Autotune may not converge well at target temperatures, even with "known good" values.)
    I will try this

I am curious what K values your PID routine generates. Notice that I report my values on the graphs, in case there is a clue in that information.
I don’t know... where do you see those on the screen command? I’ll look.

thanks,

paul

@Thinkersbluff
Copy link
Author

@maximustiberius

  • Thank you for the quick replies. It is useful to know that the 4.5.2 motherboard also has this issue.
  • The K values are not displayed on the CF6 screen. They are reported via the serial interface during and at the end of the PID process itself. Also, if you send an M301 command by itself, Marlin will respond with the current K values.
  • You can manually force a K value change with M301, if you want to experiment with your own values. (https://marlinfw.org/docs/gcode/M301.html)

If you do try testing the Creality stock firmware, it would be interesting to know what their default PID values are.

@Thinkersbluff
Copy link
Author

Not to duplicate information here and on the upstream Marlin version of this report, here is a link to a post I made today documenting the behaviour of my Ender 3 printer PID system, running Marlin 2.0.8 on a BTT SKR E3 Turbo board:
MarlinFirmware#21661 (comment)

Interesting to see that:
In the first run: the Ender cycled +/- 5 deg around the target value instead of centering below target, when using parameters that seem to have been corrupted - perhaps from ADC noise ingested during the PID Autotune process.
In the second run: the Ender PID Autotune parameters were much closer to the defaults and the system behaved much the way my CR6 SE is now performing.
The second PID Autotune was started with the nozzle already 1/2-way to the target value, while the first one was started from room temperature. The first Autotune is also clearly not the smooth cycling process it is supposed to be, so that may also have been corrupted with ADC noise.

@CR6Community CR6Community locked and limited conversation to collaborators May 7, 2021
@Sebazzz
Copy link
Collaborator

Sebazzz commented May 7, 2021

Since the issues are core to Marlin - let's continue the discussion in the upstream issue #21661.

The issue does not seem to be necessarily related to the default configurations of the CR-6 Community Firmware. Rather, it seems to be core to something in Marlin. To aid the developers, let's continue the discussion upstream. I'Il leave this issue open however until it is resolved.

@Sebazzz Sebazzz pinned this issue May 7, 2021
@Thinkersbluff
Copy link
Author

@Sebazzz - I recommend increasing the PID_FUNCTIONAL_RANGE parameter to 50 in Configuration.h
per my latest comment on the upstream Marlin issue Worst case may be a little bit of overshoot on the initial heatup.

@Sebazzz
Copy link
Collaborator

Sebazzz commented May 7, 2021

Alright. Note that will affect bed heating as well.

@Thinkersbluff
Copy link
Author

Thinkersbluff commented May 7, 2021 •
edited
Loading

Alright. Note that will affect bed heating as well.

It will, if we change the bed heater settings from Bang-Bang to PID. Also Chamber PID and Laser Cooler, I believe.
There are different powered heaters and different thermal inertia in each case, but only the PID Kp,Ki, & Kd parameters were meant to change according to the system being controlled. The need for any PID_FUNCTIONAL_RANGE parameter has been challenged in the past, by folks described as "knowing about PID" in their professions, as being totally unnecessary, and yet there it is. Maybe someone expected to save processing cycles?
Values as high as 100 were recommended and the feedback was that it worked... All it does is turn on the PID controls when the temperature is within RANGE of the target. So yes, the BED would be much less likely than the nozzle to be outside of that PID_FUNCTIONAL_RANGE for long...

@Thinkersbluff Thinkersbluff changed the title Nozzle temperature sometimes cannot reach target - hovers instead about 10 degrees lower until "Heating Failed" timeout Heating Fails after PID takes over Aug 27, 2021
@Thinkersbluff
Copy link
Author

Hoping this upstream change is going to make things better. MarlinFirmware#23871

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
t:bug Something isn't working upstream-bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@Sebazzz @renegadecitizen @Talha909 @Thinkersbluff @portals999 @ztakis @maximustiberius