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.

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

[1.1.x] Fix M303 thermal protection #8103 #8126

Merged
merged 6 commits into from Oct 29, 2017
Merged

[1.1.x] Fix M303 thermal protection #8103 #8126

merged 6 commits into from Oct 29, 2017

Conversation

RowanMeara
Copy link
Contributor

@RowanMeara RowanMeara commented Oct 27, 2017

The temperature sanity checking logic was not applied during M303
(pid autotuning) because instead of setting a target temperature, PID_autotune
directly manipulated the pwm values. When PIDTEMP/PIDTEMPBED is
enabled, PWM values rather than the target temperature determine whether
the heater is on. I changed the temperature sanity checking logic to look directly at the PWM values
when pid is enabled.

I tested M303 with the changes and they fix #8103 .

Edit: I also added calls to disable the heaters if PID_autotune errors out.

The temperature sanity checking logic was not being applied during M303
(pid autotuning) because instead of setting a target temperature, it
directly manipulated the pwm values.  When PIDTEMP/PIDTEMPBED is
enabled, PWM values rather than the target temperature determine whether
the heater is on.  I changed this to look directly at the PWM amount
when pid is enabled.
@AnHardt
Copy link
Member

AnHardt commented Oct 28, 2017

A good solution!

Currently, PID autotuning stops if it overshoots the temperature by 20C
or if if the temperature does not change for 20 minutes and it times
out.  I added calls to disable the heaters in these scenarios.
@ghost
Copy link

ghost commented Oct 28, 2017

Very Good job .... 👍
Make the same for 2.0 please 😄

@GMagician
Copy link
Contributor

GMagician commented Oct 28, 2017

Hello, sorry for int(er)mission, I checked the pid code and I think we can save up to 2K changing some things, but not sure if this is correct or not

  1. at the end of function there is
    if (!wait_for_heatup) disable_all_heaters();
    but above there is a while cycle that exits when variable is 'false' then we can just call function with no if.
  2. Everywhere in function, when exit and also "disable heaters' are required, instead of 'return' set 'wait_for_heatup' to false and (p)ut remaining code to else {...}

What do you think?
Compiling original code differences are:
184582 bytes (70.4% Full) vs 182470 bytes (69.6% Full)
with this fix maybe we can save more bytes (heater off is c(a)lled more times)

@Roxy-3D
Copy link
Member

Roxy-3D commented Oct 28, 2017

Hello, sorry for intermission, I checked the pid code and I think we can save up to 2K changing some things, but not sure if this is correct or not

I wonder if there is some 'dead code' that is being eliminated by the compiler when you make those changes? Can you cut and paste your code here for people to discuss? It would be helpful if you can show in the comments what changed so people can discuss things easier.

@GMagician
Copy link
Contributor

Honestly test was made on 2.0.x-bugfix branch with platformio, sadly with arduino there is no such optimization...
only replacing with 'break' gives me some free memory
default configuration gives me
52246 -> 52236 bytes

temperature.zip

@GMagician
Copy link
Contributor

This is really fun..I made same test again, on 2.0 with platformio, just to be sure I'm not crazy

I confirm:
Original code:
Program: 184582 bytes (70.4% Full)
Data: 6486 bytes (79.2% Full)
With variables set to false
Program: 182470 bytes (69.6% Full)
Data: 6486 bytes (79.2% Full)
With break (as 1.1 sent before)
Program: 183734 bytes (70.1% Full)
Data: 6486 bytes (79.2% Full)

o_O

@fiveangle
Copy link
Contributor

fiveangle commented Oct 28, 2017

Aside from trimming potentially dead code, I've noticed Arduino and PlatformIO swapping places a handful of bytes +/- with nearly every change —no rhyme or reason. When I'm struggling to fit into a 128k board, I'll try both and use whichever comes out smaller :)

Added changes suggested by GMagician.
@RowanMeara
Copy link
Contributor Author

I implemented the changes that @GMagician suggested which ended up saving me 62 bytes (116,272->116,210) on my arduino mega.

@thinkyhead thinkyhead merged commit 9850ba0 into MarlinFirmware:bugfix-1.1.x Oct 29, 2017
@RowanMeara RowanMeara deleted the bugfix-1.1.x branch November 2, 2017 01:03
@RowanMeara RowanMeara restored the bugfix-1.1.x branch November 2, 2017 01:06
MoellerDi added a commit to MoellerDi/Marlin that referenced this pull request Nov 27, 2017
… into bugfix-1.1.x-HD-CR10

* 'bugfix-1.1.x' of https://github.com/MarlinFirmware/Marlin: (94 commits)
  [1.1.x] Fix M303 thermal protection MarlinFirmware#8103 (MarlinFirmware#8126)
  Implement support for Dual X and Y endstops
  Add Dual Steppers / Endstops to configs
  Cleanup for DIGIPOTS settings
  (1.1.x) serious bug G33
  Add scripts for .travis.yml to append config options
  Revert default BABYSTEP_MULTIPLICATOR to 1
  Added MKS GEN L board (MarlinFirmware#8088)
  Concise SD_REPRINT_LAST_SELECTED_FILE description
  Clean up trailing whitespace
  (1.1.x) auto tune calibration parameters (MarlinFirmware#8031)
  Tweak neopixel self-test
  Add some Polish translations
  Fix FWRETRACT logic, apply common sense
  give this language an unique name
  Initial conflict resolution of SD_REPRINT_LAST_SELECTED_FILE (MarlinFirmware#8104)
  1.1.x - save 1400 bytes of FLASH by using reduced font for some languages (MarlinFirmware#8095)
  More specific M100 description
  Fix spacing, use single instances of similar pins
  Encourage users to re-examine their configs
  ...

# Conflicts:
#	Marlin/Configuration.h
#	Marlin/Configuration_adv.h
mtm88001 pushed a commit to mtm88001/Marlin that referenced this pull request Dec 9, 2017
…re#8126)

* Fixed M303 thermal protection

The temperature sanity checking logic was not being applied during M303
(pid autotuning) because instead of setting a target temperature, it
directly manipulated the pwm values.  When PIDTEMP/PIDTEMPBED is
enabled, PWM values rather than the target temperature determine whether
the heater is on.  I changed this to look directly at the PWM amount
when pid is enabled.

* Turn off heaters on M303 error

Currently, PID autotuning stops if it overshoots the temperature by 20C
or if if the temperature does not change for 20 minutes and it times
out.  I added calls to disable the heaters in these scenarios.

* Removed unnecessary if statement.

Added changes suggested by GMagician.

* Update temperature.cpp

* Update temperature.cpp

* Update temperature.cpp
damicreabox pushed a commit to damicreabox/Marlin that referenced this pull request Sep 14, 2018
…re#8126)

* Fixed M303 thermal protection

The temperature sanity checking logic was not being applied during M303
(pid autotuning) because instead of setting a target temperature, it
directly manipulated the pwm values.  When PIDTEMP/PIDTEMPBED is
enabled, PWM values rather than the target temperature determine whether
the heater is on.  I changed this to look directly at the PWM amount
when pid is enabled.

* Turn off heaters on M303 error

Currently, PID autotuning stops if it overshoots the temperature by 20C
or if if the temperature does not change for 20 minutes and it times
out.  I added calls to disable the heaters in these scenarios.

* Removed unnecessary if statement.

Added changes suggested by GMagician.

* Update temperature.cpp

* Update temperature.cpp

* Update temperature.cpp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants