[2.0.x] Fix Bed Temp Period

[Wackerbarth]

Reference PR #8236
In copying the #if ENABLED(... spaghetti to add Thermal Protection to PID Autotune (M303), the wrong formula was used for the THERMAL_PROTECTION_BED_PERIOD. This causes the attempted calibration to immediately halt with a RUNAWAY indication.

[GMagician]

Excuse me but why is time related with temperature?

[Wackerbarth]

On Nov 25, 2017, at 9:59 AM, GMagician ***@***.***> wrote: Excuse me but is why time related with temperature?

A part of the temperature protection logic checks that the temperature reading is increasing while the heater is “on”. Because of time delays, noise, and slow response rates, it is necessary to allow enough” time for there to be a noticeable change.

[GMagician]

Yes but you subtract to temperature a time.
Your code:
watch_temp_period = hotend < 0 ? temp - THERMAL_PROTECTION_BED_PERIOD : THERMAL_PROTECTION_PERIOD

[Wackerbarth]

On Nov 25, 2017, at 10:04 AM, GMagician ***@***.***> wrote: Yes but you subtract to temperature a time

No, you cannot do that. 1) They are different units. 2) Creating a negative interval makes no sense. 3) The logic which looks for E-1 must give the same result as when the hotend option is disabled.

[GMagician]

lol sorry....you removed that

[Roxy-3D]

This seems to be only an error in the bugfix-v2.0.0 branch. In bugfix-v1.1.x it looks more reasonable.

I don't know why Travis is having problems. But let's just close this and I'll zap it in the repository.

[thinkyhead]

This could've simply been merged. The travis error is unrelated to this. See #8562.

[Roxy-3D]

Yeah... In hindsight that is true. But I was thinking if something doesn't pass Travis it should not be merged.

[thinkyhead]

A page search of "error:" (with the colon) is a fast way to find the errors in the Travis log, and sometimes the issue is simple enough to fix in-place.