PID tuning both extruder / bed tuning"hangs" after reaching targeted bed temperature #26
Comments
|
Hi, why is the bed tuning "hanging" ? Does it seems to never end on the plugin interface, or on your printer screen ? |
|
Indeed, the progress bar is staying at 100% when the PID process is finished, and should go back to 0 instead. The only time when it goes at 0 is when a new PID autotune is started. |
|
@ruedli
is indeed not called. So this sentence from you:
makes me doubt now... Do you have the "PID cal. finished" message writter on your screen after the process by the way ? |
|
@iFrostizz I can test again tomorrow, but the fact that it sits in the lcd module makes me wonder. Either bad programming, or they are indeed just talking about targets set to display on the lcd. I mean: if you need to program temperature stuff, why rely on a call in the module that does lcd stuff? ultralcd did not come from marlin I believe, so there is potential for error here. ;-) After testing I can tell you more... |
|
And.... this leaves me to another observation, maybe storing the obtained PID values fails? I mean I get from the log 3 sets of PID, and instructions to store the last triple in the configuration file. When I do an M503, the reported PID values do not match the PID tuning.
Is there an easy explanation for this? Are you perhaps omitting the U1 option to use the result? Should another "issue" be opened for this observation? I did a M301 P21.42 I2.15 D53.38 followed by an M500 and after that M503 shows the obtained PID values. Is this a bug in the plugin? I was under the impression that your pluging stores the obtained PID values, but it seems to skip the M301 (and perhaps the M304 for the bed as well). Note that not all firmware supports U1, so relying on that might not be a good idea. The result of the newly stored parameters is this, I guess these PID's are better then what I started with?
|
|
Hi @ruedli,
from https://github.com/prusa3d/Prusa-Firmware#prusa-firmware-mk3 As far as I can see, I haven't found the part containing the |
Yes, this is not displayed from my firmware. Yes, the fork for Prusa from Marlin is quite dated. Over that period, the two branches quite diverted, so what works in one branch is not necessarily working in the other. I just did a PID by issuing an M303, using U1. It definitely does not store.. And you see: after the tuning your "target" temperature reported to octoprint is 0. Mine stays at the PID tuning temperature... I am still seeing 2 degrees of overshoot. Will reduce P a bit and see if that's better. Maybe the Prusa algorithm is flawed somehow. I can see in your graph that after each cycle the result is slightly better. For me that seems not the case. |
|
@ruedli |
|
@ruedli |
|
Thank François, I installed the 1.02 from the devel branch, but the temperature is NOT reset, nor are the PID values stored.
I ensured the mark was set for storing the PID parameters, however, I do not think they are actually stored. I did an M503 afterwards. I think the PIDs are not stored? Af far as I can see you reset the fan speed, but not the temperature, as I do not see an M104 S0. As soon as I manually provide that gcode, temperature goes down. Was that not supposed to be done in your devel branch? As far as I can see, you are not setting the U1 parameter when you issue the PID autotune M303.
This are the parameters I think:
Here is the full log. Recv: T:44.2 /0.0 B:36.0 /0.0 T0:44.2 /0.0 @:0 B@:0 P:25.8 A:38.5 Send: M503 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! vvvvvvvvv !!!!!!!!!!!!!!!!!!!!!! Recv: echo:PID settings:
|
|
@ruedli |
|
@iFrostizz
Yes, I did. I think the checkbox resulted in a M500 code sent, but not the
flag with the M303
|
|
@ruedli Okay, I know why. in separated lines. I will find a workaround |
|
I hope that it is fixed now. If it worked, you cannot miss it... A message should appear |
|
Hi François Almost, but not there yet ;-) Temperature goes down, there is an attempt to store the Pid values, but the values were undefined and consequently failed. This is the log now, as well as the M503 output to verify what was stored: all zeroes. Recv: T:88.8 /0.0 B:21.5 /0.0 T0:88.8 /0.0 @:0 B@:0 P:23.6 A:32.4 Recv: T:212.4 /0.0 B:21.5 /0.0 T0:212.4 /0.0 @:0 B@:0 P:24.1 A:33.7 Output from the M503: Recv: echo:PID settings: Conclusion: Almost, but not there yet ;-) |
|
The message after calibration pops up, then disappears after a few seconds. As far as I could see, it did not have correct PID values though. Is that my settings, or do you intend it to popup and disappear that way? |
|
Very probably an error in the code that is picking up the values from the received gcode commands. It is meant to fade out, but maybe that it makes more sense to let it "pinned" ? |
|
@ruedli I hope that it's fine now.. edit: Looks like the M301 has been sent twice, tough the |
|
I'll try again.. Going through some SW problems myself, trying to make my
OctoPlugout mqtt aware...
|
|
OK, think you nailed it now. And.. pinned dialog is better ;-) Verified the settings, they were stored... Nasty one, but glad we could work it out! Cheers Ruud Recv: bias: 67 d: 67 min: 212.55 max: 217.34 |
|
Ooopsss... After the extruder tuning I did a (bed only) tuning. It ruined the PID settings for the extruder... This seems OK: ecv: B:60.36 @:0 But when I check my settings with M503 I get: ecv: echo:PID settings: Not sure how the extruder ones got changed... Did not do anything manually. Can you reproduce this?
|
|
The OTHER window in which I had octoprint open (not on the calibration tab) reported this:
No idea where it picked this up, but this is where the wrong settings came from after bed-only-tuning |
|
Well, it looks like I'm sending |
|
I pushed the update, could you please try ? |
|
I am now issuing both extruder/bed tuning. The be tuning finished. On the window of the calibration I have:
But on the OTHER window I have:
That's a bit strange isn't it? |
|
It is, could I see your logs please ? |
|
ecv: B:60.53 @:0 |
|
This one seems wrong... Send: M301 E0 P73.75 I3.09 D439.98 |
|
I see... The PID applying command should be sent just after that the PID is finished. |
|
I'll wait for another version to try, but this is still a problem I guess. Don't rush, make sure it works at your place first ;-) |
|
Some last info: M503 reports the stored settings (after combined bed/extruder pid calibration)
Alltrhough they seem ok-ish, the "bed" figures appear nowhere... And in between some extruder 0 settings occur that are wiped out by the last extruder PID.
|
|
So I think that I will just let the user do one PID at a time by disabling the other textbox, that will make it more "bug-proof" |
|
Not really, since when I did them one after the other, I STILL got the extruder PID values written to the bed (or vice versa) |
|
Did you tried the version sending an |
|
Did you update the version number so I can check? It is 1.02, but I believe they all are... Not easy to know what is what |
|
Reinstalled and restarted octoprint: new test. |
|
I didn't implemented the greying out input box yet, I will do it tomorrow |
|
Retested, same problems.
Recv: B:60.14 @:0 |
|
Yes, you ran the PID for both bed and hotend at the same time, right? |
|
Well, change it, test it and when it works for you, publish it and I will then test it as well. Note that it could be an issue that is shown only when there are two windows open. I have that and both show different messages, so there is a difference in behavior that should not happen and could result in problems for other users with different configurations and different timing. |
|
I just pushed the new version, with the disabled input to prevent the user from typing in the two boxes at the same time. |
|
OK, I will have a go, doing extruder and the bed PID calibration with this. |
|
As I feared it is not OK, the bed PID settings are saved into the extruder PID as well. I feel it is the multi window octoprint that ruins it, which make me worried that you are doing things in the client that should be done in the server context and you rely on client context for doing executing things. On marlin 2.0.x, is it an option to enable PID bed tuning in your Marlin config and test with that firmware? Unfortunately I cannot run Marlin 2.x as I rely on my MMU2 working flawlessly. These are the screenprints I get:
and in the other window:
Detailed logs: =========================================== Second M503 output Not OK, ruins the extruder: Detailed logs: Recv: T:21.4 /0.0 B:21.2 /0.0 T0:21.4 /0.0 @:0 B@:0 P:22.2 A:24.5 ================================================================================= Recv: T:80.8 /0.0 B:21.4 /0.0 T0:80.8 /0.0 @:0 B@:0 P:23.9 A:29.5 |
|
The key to the solution could be that you ONLY execute pop-ups and M301 / M304 settings for the window where the PID tuning is executed from. Then I feel it should work, as that window picks up the right extruder... The good news is that you can test that functionality as well without capability to run bed PID tuning. Is there a way in your script that does the popup and M301/M304 to be aware of the client context and whether autoleveling is running? |
|
And.... with that client / calibration PID tuning awareness you can execute both in one run again, no need to make them mutually exclusive..... |
|
Hey @ruedli . |
|
@iFrostizz That is good to hear . Now that you can reproduce it, I am sure you can get it fixed. The multiple window was probably something not considered in the original design and was causing errors and confusion. Maybe in more places? Best to close this issue when you release a version with fixes it and document the version in which this is fixed. |
|
Anyone know the status of this issue? |
|
@skl111 I have tested versions from the devel branch and many problems were resolved. It also helped not having multiple octoprint windows open. I left it to @iFrostizz to close this issue when the code was merged to main. |
|
Will give it a go, thanks! |
|
I tried the devel branch and it will let you input the values, but after you do that and hit "Run PID Autotune" it does nothing, nothing gets sent to the printer. |
Tried this 3 times now, on Prusa MK3S / MMU2S latest firmware.
Plugin version 1.01
octoprint 1.7.0rc2
The extruder temperature seems to go though the tuning process, but the BED tuning never ends. I waited more than 25 minutes, no indication this will finish any time soon.
Let me know if further information is needed.
The text was updated successfully, but these errors were encountered: