Instead of incrementing a variable on every iteration on the filament sensor trigger loop, we now use a real time macro that ensure better repeatability and is easier to customize.
- Add startFileprint(); call to M108 display routine to fix progress and ensure "printing done" gets shown
- Add SD printing check in marlin_main.cpp M600 routine to skip TFTstate if not necessary (e.g. USB printing)
- Move routine to the top again to ensure immediate execution
Move the routine to a better position and set the state regardless of SDPRINT status.
This ensures that M600 makes the display show a continue button every time. Before, it was only behaving correctly for the first instance of M600.
- Check for PausedByFilamentChange flag on pause and resume
- Move stop movements from StateHandler() to StopPrint()
- Retract 1mm on pause (2mm on runout) without feed on resume, preventing ooze
- Fix special menu margin on some buttons
Lowering the safety margin of MAXTEMP to 10°C and raising MAXTEMP to 285/135.
Resulting in a limit of 275°C for the hotend and 125°C for the heatbed.
Referencing #23
Improve USB printing by slowing down on certain situations. This prevents the buffer from running empty and removes the need to wait for new serial commands.
Some hosts like Pronterface use continuous M105 commands to poll temperature, this causes a software halt when the heating via M109 or M190 is finished. Flushing the rx buffer fixes this.
As reported in #15, thanks to @rug156 for the feedback!
As a possible fix for the bug with Cura's end Gcode as described in
issue #7, I changed the leveling state to be disabled after homing since
Cura uses X homing in their end Gcode.
While adding ENDSTOP_NOISE_FILTER, I try to reduce the impact on accuracy as much as possible by reducing the endstop_poll_count to 2.
Possible fix for #8.
Thanks to @notching, @mensikv and @md66pt for the valuable feedback!
Thanks to feedback from @DerDominik I was made aware that Anycubic's default acceleration values in their source code are different from the ones they use in their compiled firmwares. Seems like insufficient torque on the Y-axis caused step loss on TMC2208 for that reason.
Co-Authored-By: DerDominik <derdominik@users.noreply.github.com>
David Ramiro