[BUG] "Heating Failed" after PID takes over

[Thinkersbluff]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

This bug is present in the CR6-SE Community Firmware at Release 6, which incorporates Marlin bugfix2.0. I am running this particular version, compiled for my printer's hardware configuration: CF6.1-Pre2-btt-skr-cr6-with-stock-creality-tft-2021-04-18-22-12.zip

I reported this bug on the Community Firmware GitHub Issue#248, but the CF6 developer has asked me to report it upstream, here.

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 "Heating Failed failed to achieve target temperature within the alloted timeframe" message on the screen and "kills" the job, forcing the user to cycle power to recover.

wtf.txt

Bug Timeline

Issues with PID not performing as well as in the past have been reported by several users since Release 6 of the Community Firmware.

Expected behavior

Nozzle should heat to the target temperature and stabilize. Particularly if the system has just had a PID run (M303 E0 Sxxx U1) at the same target temperature with no problem, yet now can not heat to that xxx temperature to print.

Actual behavior

When this problem occurs, the serial interface shows that the printer recognizes the correct target temperature, yet it stops short of heating to that value, cycling instead around a value about 10 deg C lower than the target.

NOTE: These users on the Creality CR6SE/MAX Official Facebook Group describe this same problem in other scenarios, so it is not specifically or uniquely an issue when heating to 235C or when running an esteps extrusion.

I have also been able to successfully achieve 230C when I could not achieve 235C and I have achieved 235C when the nozzle was already at 230C, so there are other parameters at play, here, that I have not yet isolated. The part cooling fan was off, the whole time.

In the final cycle of the second graph (see my comment below this post), the printer actually bumped-up from 230 to 235 just at the end, there. No idea why, as you can see it was settling at the lower value & I touched nothing.

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.

Version of Marlin Firmware

Latest Bugfix2.0 merged into Community FIrmware Release 6.1 Pre 2 on 18 April 2021

Printer model

Creality CR6-SE

Electronics

BTT SKR CR6 motherboard, stock hotend, stock cooling fans, stock TFT. Users with Creality 4.5.3 boards also report this issue.

Add-ons

None

Your Slicer

Cura

Host Software

OctoPrint

[Thinkersbluff]

I twice edited the above to include this second graph and log, but the template seems to be truncating it out: wtf2.txt

[Talha909]

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. I have SKR 1.4 Turbo with TMC 2130 and in 2nd printer with SKR E3V2 and skr mini

[Sebazzz]

@Thinkersbluff Have we been able to exclude #21374 being the cause?

[portals999]

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.

[scooter2214]

Same problem here... Board 4.5.3 and Stock TFT... I use the CR6Comm-CF6-Final-cr6-se-v4.5.3-mb-2021-03-27-15-53.zip ...

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, too

any solutions ?

[Thinkersbluff]

@Thinkersbluff Have we been able to exclude #21374 being the cause?

Nope. No evidence either way. I do suspect, though, that rounding-off the thermistor readings may be causing PID to get “tricked” into cycling around the target temperature minus PID_FUNCTIONAL_RANGE. That final temperature cycle in wtf2.png above was clearly converging on the lower value then suddenly “flipped” up to the target temp. I did nothing to cause that. Thermal inertia and random rounding errors could explain that.

[Thinkersbluff]

@Thinkersbluff Have we been able to exclude #21374 being the cause? UPDATE - my testing of the Community Firmware Release 6 Prerelease 6 today shows the same behaviour with or without PR #21374 merged into it. This suggests that this problem pre-dates PR #21374.

It appears that the problem is related to using the parameters returned by the current PID routine.

[rhapsodyv]

I just sent this to make temperature internal calculations using high precision again, maybe worth a test: #21678

[Thinkersbluff]

I just sent this to make temperature internal calculations using high precision again, maybe worth a test: #21678

Thank you. I just found this existing issue which sounds very similar to the behaviour I am reporting here - https://github.com/MarlinFirmware/Marlin/issues/20463.

This problem may date back over a year, if related.

[thisiskeithb]

There have been several temperature-related fixes merged within the last couple days. Please download bugfix-2.0.x to test with the latest code and let us know if you're still having this issue.

[Sebazzz]

Sorry, it has become less stable. Not only "heating failed" errors but thermal runaway as well. Need some time to collect additional data.

edit: Reverted before the PR and at least there is no thermal runaway.

[Thinkersbluff]

There have been several temperature-related fixes merged within the last couple days. Please download bugfix-2.0.x to test with the latest code and let us know if you're still having this issue.

Thank you for the outreach. @Sebazzz let me know that the latest bugfix2.0 had been merged with the Community Firmware Nightly build of Release 6.1 tonight, so I did download and test it on my system. (I have a Creality CR6-SE with a BTT SKR CR6 v1.0 motherboard and a stock Creality DWIN display.) My tests did NOT result in any Heating Failed or Heating Runaway alarms today, but the PID tuning performance is still not working well, and the PID Autotune function still seems to make things worse instead of better.

When I was reviewing the closed Issues for possible matches to this problem, I found the description and discussion in issue 20463 was particularly similar and relevant to the situation I think we are having here. For that reason, I have experimented with two configurations in these tests:

1. The predefined Configuration.h values of PID_K1=0.95 and PID_FUNCTIONAL_RANGE=10, and
2. A version incorporating advice from the discussion in that other issue, with PID_K1=0.55 and PID_FUNCTIONAL_RANGE=16

The test procedures that I used and the results that I logged are documented in the .txt file under each plot.

Here is a copy of the configuration files from the second series of tests. They differ from the first series only in the value of those two parameters. Configs.zip

My limited math skills and lack of C++ literacy is slowing-down my efforts to understand why these changes seem to improve both the hotend stabilization and the PID Autotune function, but the plots seem to confirm that they do.

I would particularly like to understand the significance of editing these parameters, so that I don't recommend changes that only break something else. I wish I had some way of independently validating the PID factors being generated by Autotune...

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

[pillopaolo]

I have a similar problem (temperature 5-10 degrees higher than setpoint) with SKR 1.4 (3 of them), while on SKR 1.3 (4 of them) had never had problems. Same printers (Ender3, Sovol SV01). It seems caused by strange noise/peaks in the thermistor reading.

I improved thing a lot by increasing ADC_LOWPASS_K_VALUE from deafult 2 to 6 or 8.

Reading around and looking at the schematics, I see that SKR 1.4 (and maybe other boards) has different configuration than SKR 1.3, including a ESD Suppressor (CG0603MLC-3.3LE). Might this lead to issues with temperature reading, which need special attention?

[Thinkersbluff]

In my work life, we found that one of the easiest ways to explore complex technical issues is to exchange highly simplified pictorial models. If this model is obviously over-simplified in the mind of one or more participant, that suggests an important factor of which other participants may not be aware. By marking up this model to "correct" it, we facilitate a focused conversion of implicit to explicit knowledge. Through that exchange, we all better understand what matters.
Currently, I am thinking that PID Autotune is not working on at least some machines, but it seems - because the number of folks reacting to this issue seems low - most Marlin users are not noticing this issue on their own systems. That implies to me that those of us with problems are operating systems that are configured differently somehow from those other users, in a TBD critical way. Figuring out which differences we can ignore and which seem to be relevant is the hard part.

Open question to those who are interested in solving this problem: Does this model show all of the essential elements that need to be considered + all of the controls available to us to adjust our machine(s) back into a stable operating region? PID Model.pptx

[Sebazzz]

Possibly related #18642 by @bohbotjames

[pillopaolo]

Adding to my comment above.

If I activate PID debug (#define PID_BED_DEBUG, then M303 D), I see crazy PID output values, especially on the derivative action, when temperature values are noisy and jump +- 1 or 2 degrees is a very short time.

And the fact that the temperature hovers exactly 10 degrees above/below Setpoint is not a coincidence. Most of the time PID_FUNCTIONAL_RANGE=10! This means that when above temperature-noise issue is big and PID gives crazy numbers and is not able to control anymore, you end up switching all the time between bang-band and PID modes. The result is a temperature oscillating around [Setpoint - PID_FUNCTIONAL_RANGE] or around [Setpoint - PID_FUNCTIONAL_RANGE].

I did not try, but I bet that if you change PID_FUNCTIONAL_RANGE value, your temperature will hover at a different value.

[Thinkersbluff]

I did not try, but I bet that if you change PID_FUNCTIONAL_RANGE value, your temperature will hover at a different value.

This was also my expectation, so I did explore the impact of changing PID_FUNCTIONAL_RANGE.

The plots posted here show that if I reduce the parameter to 5, the oscillation is more likely to occur consistently.
If I increase the value to 16, it is more likely to achieve the target temperature.

Reducing PID_K1 smoothing factor from 0.95 to 0.55 also improved the system’s performance. Doing both seemed to remove the initial undershoot and ringing almost completely for the conditions tested.

The ADC_LOWPASS_VALUE parameter is unique to the HAL.h for LPC1768, so not an option for CR6 users on STM32F1 motherboards.

I am only looking at nozzle temperature at the moment but I think the bed and chamber and laser cooler all use the same PID function.

[Thinkersbluff]

Possibly related #18642 by @bohbotjames

I agree that looks like the same issue in July 2020. Closed by the author same day without explanation.

[Sebazzz]

@Thinkersbluff Did we determine if the problem happens on stock Creality boards too? We know the BTT SKR CR-6 board has the temperature noise issue - stock has not.

Met vriendelijke groet, Sebastiaan Dammann

---

Van: Thinkersbluff @.> Verzonden: Monday, April 26, 2021 1:28:50 PM Aan: MarlinFirmware/Marlin @.> CC: Sebastiaan Dammann @.>; Mention @.> Onderwerp: Re: [MarlinFirmware/Marlin] Nozzle temperature sometimes cannot reach target - hovers instead about 10 degrees lower until "Heating Failed" timeout (#21661)

I did not try, but I bet that if you change PID_FUNCTIONAL_RANGE value, your temperature will hover at a different value.

This was also my expectation, so I did explore the impact of changing PID_FUNCTIONAL_RANGE.

The plots posted here show that if I reduce the parameter to 5, the oscillation is more likely to occur consistently. If I increase the value to 16, it is more likely to achieve the target temperature.

Reducing PID_K1 smoothing factor from 0.95 to 0.55 also improved the system’s performance. Doing both seemed to remove the initial undershoot and ringing almost completely for the conditions tested.

The ADC_LOWPASS_VALUE parameter is unique to the HAL.h for LPC1768, so not an option for CR6 users on STM32F1 motherboards.

I am only looking at nozzle temperature at the moment but I think the bed and chamber and laser cooler all use the same PID function.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F21661%23issuecomment-826759912&data=04%7C01%7C%7C003dc26da18a4e24e2df08d908a67849%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637550333336697538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PhlaN535fhfjndFF92GiMUejCeKvdrMsXXjwchXBt1I%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAK4FMP7MCR6NRT5SANK7MDTKVE7DANCNFSM43FC3BGA&data=04%7C01%7C%7C003dc26da18a4e24e2df08d908a67849%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637550333336707530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8D4B%2FoTDmDTv3BjkS1eTdgMT0xttmEvFq0KUEM9cRXs%3D&reserved=0.

[pillopaolo]

Dear developers, it seems that SKR 1.4 (my case, see also Talha909 ) and CR-6 (see Sebazzz) boards have temperature noise issues, apparently due to their electronics setup.

Why not adding a user configurable filter for the temperature? Something like OVERSAMPLENR, but a bit more powerful and configurable from configuration_adv.h.

@Thinkersbluff, could you pls reply to above question of Sebazzz? That would be helpful.

Thanks

[Thinkersbluff]

@Thinkersbluff, could you pls reply to above question of Sebazzz? That would be helpful.

Which question have I not answered? These posts seem a little out of sequence but there are at least two stock 4.5.3 MB users above confirming they have this issue.

[Thinkersbluff]

I updated my Ender 3 with Marlin 2.0.8, yesterday (fantastic work by all, thank you!) That printer has a BTT SKR E3 Turbo motherboard (a board that is known to have an ADC noise vulnerability in the version I have installed), a MicroSwiss hot end, and a stock cooling system. I then repeated one of the tests that I had done on my CR6 SE while documenting this PID problem.

In the first graph:

1. I selected Nozzle Temperature of 240C, with the default PID parameters. Notice that there is a short small undershoot and then temperature converges on target and holds +/-1deg.
2. I ran PID by sending M303 S240 E0 C8 U1 via the terminal
3. I repeated step 1, with the new calculated PID parameters. Notice that the system then exhibited stable "ringing" as seen on other systems, but this time it is centered on the target value, instead of being centered below the target.

In this test,the PID process itself generated a bit of a messy curve, not the smooth cycling I am used to seeing. That may somehow correlate to the set of factors that Marlin computed. The +/- 5-6 degree cycling around the target value with the computed PID parameters persisted for the 10 minutes I left it running.

In the second graph:

1. I cycled power off/on to reset the system and then repeated the first test sequence above, EXCEPT that I did not allow the system to cool as much before I proceeded to the next step.
2. I left that 3rd curve from the first test in this second graph, to highlight the contrast between PID performance with the default PID parameters versus PID performance with the calculated parameters.
3. I noted that the PID Autotune cycling looked much more "normal" in this second run.
4. The calculated PID parameters were quite different in this second run of the test and the nozzle heating was able to converge on target temperature, after a bit of undershooting.

[Thinkersbluff]

I am presently struggling valiantly through the PID "documentation" referenced in the Marlin Configuration.h. (https://reprap.org/wiki/PID_Tuning)

That documentation refers to a parameter which appears to have disappeared from Configuration.h since the document was last updated: "The 'sum of errors*time' value is limited to the range +/-PID_INTEGRAL_DRIVE_MAX as set in Configuration.h."

There are 49 Closed issues which include a reference to PID_INTEGRAL_DRIVE_MAX, so I parsed through them to find out what happened and why. Turns out #4881 removed it (see 3rd issue below). The referenced documentation is out of date.

These 3 closed issues sound a lot like this current issue. The second issue was closed without any corrective action :

1. Hotend PID fails to reach target when Auto Bed Level feature is turned on. #4086
   • A PID_FUNCTIONAL_RANGE parameter of 50 or 100 seemed to solve the problem
   • The team concluded that the EEPROM PID data or pointer data was somehow being corrupted - EEPROM Checksum #4167 merged into Marlin 1.1.0
     2. Exruder heater never stabilizes at set temp #3211
   • A PID_FUNCTIONAL_RANGE parameter of 50 seemed to solve the problem - No changes made to Marlin
2. Bug in PID integrator anti-windup #4881
   • A bug was identified in the Integrator portion of PID - Pid unconstrained itemp #4914 merged into Marlin 1.1.0, removing the PID_INTEGRAL_DRIVE_MAX parameter from Configuration.h and removing that time range constraint from the integral term.
   • Numerous other comments suggested other issues remained with PID, but Issue was closed.

[Thinkersbluff]

Following the advice from team members back in 2016, found on the above related issues, here is the same Ender 3 system as tested in the previous comment, running Marlin 2.0.8 with PID_FUNCTIONAL_RANGE set to 50 (Test conditions and serial log captured in the .txt file below the graph:

Ender3_Marlin2_0_8_PID_FUNCTIONAL_RANGE=50.txt

I believe this one parameter change could be optimized with experimentation but annecdotal feedback from numerous issue reports seems to support a suggestion that the current default of 10 may be too low for some systems. This infers to me that Marlin is capable of calculating useable parameters and of performing PID, but it needs a bit more "elbow room" to work, hence the positive impact of increasing the value of that functional range parameter.

[esunayg]

btt skr cr6 + cf6,1p3 I have been using my device with some little fluctiations, just wanted to make some adjustments I have poked with auto tuning. Acoording to my findings, pid loop doesnt calculate D value correctly. Even if you make d and i to 0 it doesnt overshoot. Normally it should get a fixed k value depending on the target and then over time i should get into the calculation and increase the output value. D comes last to not to overshoot. Any pid device works ok without d value if you dont push k and i way over. Even only K value gives a set value stable response. So you and we are trying to cover the D problem by adjusting the k and i. Thats why auto tune fails to respond. It thinks that D value is changed/iterated but not. Just check with your device while only K value. I and D at 0. Temperature "must" be stabilized at any temp. But it doesnt. Digging deep to understand D value calculation. Either variable doesnt change or miscalculated/miscalled in the Pid pwm calculation loop.

// edit: I take it back.

[LouwrensMB]

I just encountered the same problem my bed temperature head up fine but my nozzle does no reach the set temperature was there a solution to this ticket or is it still open "Heating Failed" timeout #21661

[Thinkersbluff]

Modifying the PID_FUNCTIONAL_RANGE and PID_K1 factors as described above is at least a proven work-around.

[fcaiado]

Anyone got a status on a fix for this? Had this issue with an E3v2 and 4.2.2 board and upgraded to the 4.2.7 because I thought it was a board issue then found this thread. This is making printing life horrible and wasting lots of material.

[jimberg98]

I'm having a similar issue with my bed when PID is enabled. I set the temp and it stops heating 10 degrees shy of the target temp and then says it doesn't reach temp and halts the printer. The LCD indicates that the bed is heating with the wavy line icon, but it clearly isn't. Does it try to use PWM? I have a 1000 watt AC heater which can easily surpass the 100 degrees that it never reaches. I set the temp to 110 for ABS, it makes it to 100 and then halts the printer. I set it to 100 and it halts at 90. I wanted to use PID because I'm having the opposite issue with PID disabled. The temp drifts too high and halts the printer. Someone complained about this a while aga and they just closed it because they figured his bed couldn't reach the temp. I think he was probably having the same issue. I know my bed can reach the temps I'm trying to get to.

[jimberg98]

Does anyone know why there isn't a separate PID_FUNCTIONAL_RANGE for beds and nozzles? My problem with the bed heatings is clearly related to this. The heater gets shut off when within PID_FUNCTIONAL_RANGE degrees. I would think that a bed which heats much more slowly should have a PID_FUNCTIONAL_RANGE that is much lower. I added a PIDBED_FUNCTIONAL_RANGE to my code and will experiment with it. My bed is a 1/4 inch cast aluminum tooling plate which has a lot of mass to it. Should have mentioned that in my first message.

[jimberg98]

I got this figured out. PID_FUNCTIONAL_RANGE is the temperature range that PID control takes over. Set your target to 200 and PID control will take over at 190. Up until then, maximum power is supposed to be used... sort-of. The problem occurs because your PID values are set to something that results in a zero power recommendation from a method called get_pid_output_xxx() where xxx is hotend, bed, or chamber. Make sure you have defaults defined and reload your default settings. That will fix the issue with temp never being reached. Or you can just set them with the M codes and save the settings.

Now for the "sort of". For no apparent reason that is documented, the output of get_pid_output_xxx() is divided by 2. Because of this, your heating power will only be running at 50% of max power setting. It would be nice if the code was commented explaining why this is the case. My guess is that since some of the power supplies being put in 3d printers are underrated for the actual power requirements. I can see this being the default behavior for safety, but it should be optional and explained so that people who update their power supplies or stop using them for heating the bed altogether should be able to run at full power. I modified my code so that when it's heating up, it uses full power but then when PID kicks in, I add back the divided by 2 so PID works as designed. My heaters get to temp quickly and the temp control is great. Having a separate PEDBED_FUNCTIONAL_RANGE is also a big help. Using 10 for the hot end and the bed, and probably the chamber, just doesn't make sense. They heat at vastly different rates.

If there is a bug, it's probably that the PID values should be reset to default if using them ever results in a zero power value.

[edumaker-limited]

Having the same issue on Marlin 2.0.9.1, on an Ender-3 v1, with a Creality 4.2.7 32-bit board. As described above, bed (bang-bang) heats perfectly to temperature, but the hot end heats to target minus about 8 degrees, then cuts out, drops to target minus 12-15, then reheats but again cuts out around target minus 8. Tried PID autotune, swapped out heater cartridge and thermistor, tried adding 1000uF capacitor to 5V rail, no joy. Pleased to see this looks like an issue with the PID implementation, it felt like PID was being interrupted. What I found odd was that the 2.0.9.1 firmware I uploaded was a minor edit from a perfectly working copy, same printer frame but built for ATMEGA2560/RAMPS. That worked perfectly. So there is something different about the way it works on the Creality 4.2.7 board.

[Rollux11]

Just advising I have today updated from 2.0.7 to 2.0.9.1 on an Ender 3 Pro with SKR Mini 1.2 and am unable to reach set bed print temp in the print. Can manually set bed temp anywhere up to 100deg without issue, as soon as a print is selected the bed stops heating ~10deg C below target and then timeout with heater failure warning. Set back to Bang bang and works fine. Seems an issue with the PID feature. Changing to previous settings, default and autotune all resulted in no change.

[jimberg98]

Do you have M503 enabled? I'd enter that to see what your PID settings are. They'll show as M301 and M304. You also have to have PID enabled for bed.

My settings show as: echo: M301 P10.8824 I0.5633 D52.5622 echo: M304 P29.7545 I1.9025 D310.2398

Are yours similar? You should also do an autotune PID for your bed and update the settings accordingly. I ran into an issue last night like what you're describing. Doing the autotune and changing the settings fixed it.

[Rollux11]

I did have it enabled - the settings it came back with were as below which I even went back and put it directly into firmware and recompiled (which is where I have copied from as I have switched off PID for know so I can continue printing) NOTE: I am only having the issue for the bed with PID; Hotend PID is on and working fine Kp 68.41 Ki 13.06 Kd 238.98

[jimberg98]

What do you use as your target temp when you autotune and how many iterations did you run?

[Rollux11]

Target 75, 8-10 runs. The issue is not that the bed cannot hit temp under PID. I can manually select a temp and it will hit and maintain that temperature - all the way up until 100deg C. It is only when a print job is selected and it stops ~10deg below target and fails. I even tried preheating the bed to 70deg, starting a print job that required a 60deg bed. The bed temp dropped to 52deg and held there until the failsafe kicked in. The only change to my setup was Marlin update. Changing the bed heating to bangbang allows temp to be maintained and me to print.

[jimberg98]

Is there a difference between setting your temp (M140) and waiting for a temp (M190)?

[jimberg98]

Maybe you should pre-heat your bed and remove the bed temp related lines in your start g-code. There's definitely a lot more code in the wait_for_bed method than you think there would be. Search for "bool Temperature::wait_for_bed(" and you will see what I mean. It's in the temperature.cpp file.

[Rollux11]

Ok, so I seem to have fixed it at this point. Spent the day stuffing around with things (beauty of lockdown sometimes!) I performed the following and now it is working; Updated my RPI4 kernel and EEPROM firmware Updated Octoprint to 1.7 RC2 Deleted all Marlin data, VSCODE and PIO from my computer. Downloaded VSCODE and plugins. Downloaded Marlin 2.0.9.1 Redid all my settings again and compiled new firmware. Added to printer and checked M503: Despite having put the numbers in the Marlin firmware to compile, the bed P,I,D were all 1,1,1. (This I think is the issue!) Entered the pID values via M304 and then M500. Rechecked M503 and the values were there. Started a print - is currently running in 7deg ambient with a 60deg bed and holding well.

So my issue was I think two-fold - the PID numbers I was adding in the Marlin Compiler were not transferring. Secondly, when I was entering the PID data in the machine they were not persisting, despite an M500 command.

[jimberg98]

I'm glad you were able to get it working. I think any defined value that begins with DEFAULT_ is only loaded when you reset your settings. They won't override what's saved on the EEPROM. That's a good thing once you know it works like that.

[thinkyhead]

The general advice I have seen is to increase PID_FUNCTIONAL_RANGE so that PID takes over sooner, and this seems to work for a lot of cases. I'll be adding separate settings for the different heaters soon, but for now it applies to both nozzle and bed heaters.

[thinkyhead]

I would recommend against using bang-bang heating for the bed because it tends to produce visible artifacts in the print.

[thinkyhead]

If the values produced by M303 PID auto-tune are lacking, there are some tutorials online that include instructions for hand-tuning your PID settings to improve power curve and temperature stability. In general, if PID is taking over and failing to heat fast enough, you can try increasing the P term as a first step. This will increase power but may lead to more overshoot and possibly reduced stability, so you will need to follow up by tuning the I and D terms until the temperature is optimally stable.

It may be the case that power to your hotend and/or bed are being leached when both are turned on at the same time. So, when tuning your hotend PID it will help to turn on bed power, and when PID-tuning the bed, it may actually help to turn on the hotend. If you typically run your fan above a certain temperature with auto-fan, you should run the auto-fan during your PID tuning. All of these will ensure that the PID values are set according to the amount of power that is available during printing. If there is any doubt that this will help, give it a try and see if the PID values are very different from doing isolated PID tuning.

[thinkyhead]

when I was entering the PID data in the machine they were not persisting, despite an M500 command.

NOTE: Be sure to include the U parameter in your M303 command to immediately use the PID values. Then they can be saved with M500. Check immediately with M500 that the values are applied. Then, reboot and re-check with M503 that the values are stored. If PID values are failing to store to EEPROM that is a separate issue and will require a new bug report.

[jimberg98]

@thinkyhead Do you know why only half of max power is used? You set it to 255 and you only ever see 127. I fixed it in my code so it doesn't divide the power until it's in PID functional range. My bed has an AC heater so the power supply is barely taxed at 50 watts for the hot end. My bed and temp reach temp at about the same time now. I didn't change the way the hot end heats as far as power goes.

[thinkyhead]

Are you saying this half power behavior is something that recent versions of Marlin PID do, but older versions of the PID code don't do?

[ManuelMcLure]

When I looked at the code some time ago, I determined that @127 is actually full power - I don't know why the PWM power only goes from 0-127 but I expect it's something to do with signed values being needed for the PID algorithm.

[ManuelMcLure]

It looks like https://github.com/MarlinFirmware/Marlin/blob/0c4085da01433c230731828a45ee7a91ae11b794/Marlin/src/module/temperature.cpp#L1324 is where the value is limited to 0-127.

[jimberg98]

@ManuelMcLure, yep. I'm not sure why they do that. I took it out (the >> 1). My bed heats fine and stays at temp reliably.