Fix Duplicated Temp Report

[InsanityAutomation]

Resolves issue #26805 which saw temp reports duplicated when in the waiting state. As autotemp reporting is now isolated the idle state wait heaters for M109 etc, use the global wait for heatup flag to suppress the report.

I cant see a logical reason why this bool was initialized to true. Each use case sets it as expected before entering its wait loop.

[ellensp]

I think you have missed the issue here (Or I have)

It is my understanding that:
M109 and M190 shouldn't report any temperatures unless M155 as been set

M109/M190 should just sit there (with optional Busy processing lines) and eventually once temperature is reached return OK without reporting any temperatures.

Currently with this PR they still report temperatures while waiting.

If you enable M155 then use M109/M190 you still get two lines of temperature reports

M104/M140 currently seem to correctly just returns, no temperature reporting
but M155 then M104/M140 also doesn't report any temperatures either, and it should.

[InsanityAutomation]

From the sim output here - no duplicated reports when M155S2 is set and M109 is sent, M155 resumes correctly following

I believe temps while waiting is a legacy behavior, the duplicated output was the issue. It should not report both. I have a few machines laying around on really old builds, I can check one to be sure, but I do expect a report while waiting.

[InsanityAutomation]

but M155 then M104/M140 also doesn't report any temperatures either, and it should.

I just ran this in the sim and M155 continues reporting while M104 and M140 is heating -

[ellensp]

Operator error. M155 without a parameter did not default to a time or off, its just quietly ignored. invalidating most of my testing.

I still think M109/M190 should be quiet unless told to report.

[InsanityAutomation]

Confirmed behavior - M109 has called for reports while waiting independent of M155 settings for a very long time, and is intended behavior.

16:15:12.000 > echo: Last Updated: 2021-07-31 | Author: Tinymachines3D
16:15:12.018 > echo:Compiled: Jul 31 2021
16:15:12.018 > echo: Free Memory: 608  PlannerBufferBytes: 1552       
16:15:15.008 > //action:notification T-REX 2+ Ready.
16:15:15.039 > echo:V83 stored settings retrieved (716 bytes; crc 8934)
16:15:15.040 > Unified Bed Leveling System v1.01 inactive
16:15:15.087 > 
16:15:15.087 > UBL reset
16:15:16.494 > //action:prompt_end
M109S180
16:15:19.922 > echo:No SD card
16:15:19.923 > //action:notification SD Init Fail
16:15:19.923 >  T0:17.27 /180.00 T0:17.27 /180.00 T1:17.07 /0.00 @:0 @0:0 @1:0 W:?
16:15:20.914 >  T0:17.23 /180.00 T0:17.23 /180.00 T1:17.03 /0.00 @:127 @0:127 @1:0 W:?
16:15:21.927 > echo:busy: processing
16:15:21.927 >  T0:17.27 /180.00 T0:17.27 /180.00 T1:17.11 /0.00 @:127 @0:127 @1:0 W:?
16:15:22.930 >  T0:17.46 /180.00 T0:17.46 /180.00 T1:17.07 /0.00 @:127 @0:127 @1:0 W:?

[thisiskeithb]

Since @petaflot closed #26805 as "Not Planned", is this PR still needed?

[petaflot]

yes. but it's very simple and does not clean up the code (lot of redundancy, dozens of lines can be removed)

[InsanityAutomation]

I don't disagree but I don't like to mix clean up with bug fix... You tend to end up with new bugs for every bug you fix that way.

[sjasonsmith]

I agree. It is hard to identify what changed when mixed with cleanup.

I never reviewed this one to get it in because I was having trouble understanding the problem well enough to know if the change seemed correct, given the multiple comments seeming to be confused about proper and actual behavior.

[petaflot]

I don't disagree but I don't like to mix clean up with bug fix... You tend to end up with new bugs for every bug you fix that way.

following that last comment I closed #26805 as completed ; please merge