Changing (feedrate * feedmultiply) / 6000.f
to (feedrate * feedmultiply) * (1.f / 6000.f)
Replaces the call to __divsf3 with __mulsf3 which is better
No change in memory
- Don't allow re-heating the nozzle or the MMU to unload the filament if the print was aborted by a temperature error
- Allow MMU to unload filament if there is no temperature error, and there is no fan error when Fan check is enabled
- When Fan check is disabled, the MMU may unload if there is no temperature error
Change in memory:
Flash: +14 bytes
SRAM: 0 bytes
PFW-1557
- Show warning if extruder temp is > 40 degrees
- Use fan to speed up cooldown
- Show confirmation msg
- Show nozzle diameter setting after nozzle change
lcd_show_fullscreen_message_yes_no_and_wait_P and lcd_show_multiscreen_message_yes_no_and_wait_P
are the same function. Let's drop one of them so we only have one symbol for the function.
No change in memory
Fix rebase
- No wait for heatup during host print recovery
- No extra Z lift when power panic happens during paused print
- added an extra EEPROM value
- fixed `EEPROM_LAST_ITEM`
- changed EEPROM version to 3.14.0
- Added `reset_uvlo` function
- Hide menus during recovering
- Un-/Load filament with FSensor active only show Load OR Unload depending on FS sate
- Host
- Reprint only shown when M79 timer is active
- Resume only shown when M79 timer active
- Stop print always shown when printing, paused and recovering
When the cs variable is loaded into RAM, cs.axis_ustep_resolution will always have some value and none of the 0xff values.
Change in memory:
Flash: -40 bytes
SRAM: 0 bytes
cancel_heatup is set to false inside wait_for_heater()
there is no need to do it before the function call
Change in memory:
Flash: -4 bytes
SRAM: 0 bytes
When a print is paused, card.sdprinting is set to false. Instead we can check
if the SD card has been mounted and try to close the file.
The closefile() method will check internally whether or not the file is open.
In the case of a Fan Error, the print is paused. If the nozzle is allowed to cool for a while before the print is stopped via the LCD, then the MMU will try to unload with a cold nozzle.
This can happen with ANY recoverable thermal errors.
In this commit I attempt to fix all scenarios. Including PFW-1544 where the nozzle is cooling down when the print has finished normally.
PFW-1544
PFW-1552
Change in memory:
Flash: +74 bytes
SRAM: 0 bytes
If the if statement is not true, then the st_synchronize call is not useful
The raise_z call above the if statement does not need it since it always calls st_synchronize (blocking move)
No change in memory
If the timer is expired, then the timer is stopped. This is OK since
we are starting the timer again anyway
Change in memory:
Flash: -14 bytes
SRAM: 0 bytes
When long moves are planned and executed the USB timer can expire.
In PrusaSlicer 2.7.1 the Toolchange command (T0, T1, etc.) is sent while the USB timer is expired. This will trigger
a manual MMU unload in the firmware. Not only does this trigger a loud beep from the buzzer, but this will also significantly increase print time.
The issue only affects host prints. SD card printing does not have this issue.
Fixes#4551
The fix in this commit is the following:
If there are blocks queued while printing via host AND the USB timer is halfway expired WHILE executing a move. Then simply restart the timer to keep it alive.
Change in memory:
Flash: +62 bytes
SRAM: 0 bytes
This function is not specific to power panic. Some printer models
do not have power panic enabled.
This change fixes a build failure
No change in memory
restore_file_from_sd function now supports any
filename extension. If a print was finished (to allow reprinting) then the
EEPROM filename and extension should always be valid.
Change in memory:
Flash: -312 bytes
SRAM: 0 bytes
If a planned request is activated when the current status is finished
then the firmware must wait for the response when the request
is expecting it
An example is a register read or a register write.
manage_response not return unless the register has been read or
written. And we must see the response to know if an error should be
reported.
Step to reproduce issue:
1. Fail selector homing
2. Select 'Tune' item
3. Observe issue. In this situation you can see the value
for the previous register read is shown. Which is 0. This very timing dependent and does not always happen.
4. Repeat step 2 until the issue appears. It may take a few times.