* Sync PEC `FINDA_DIDNT_GO_OFF` to `FINDA_FILAMENT_STUCK`
* Sync PEC `FSENSOR_DIDNT_GO_OFF` to `FSENSOR_FILAMENT_STUCK`
* Sync PEC `PULLEY_STALLED` to `PULLEY_CANNOT_MOVE`
* Sync PEC `SELECTOR_CANNOT_MOVE` update text
* Sync PEC `IDLER_CANNOT_MOVE` update text
* Sync PEC `PULLEY_WARNING_TMC_TOO_HOT` to `WARNING_TMC_PULLEY_TOO_HOT`
* Snyc PEC `RestartMMU` to `ResetMMU`
Also related text
* Sync PEC `SELECTOR_WARNING_TMC_TOO_HOT` to `WARNING_TMC_SELECTOR_TOO_HOT`
* Sync PEC `IDLER_WARNING_TMC_TOO_HOT` to `WARNING_TMC_IDLER_TOO_HOT`
* Sync PEC `PULLEY_TMC_OVERHEAT_ERROR` to `TMC_PULLEY_OVERHEAT_ERROR`
* Sync PEC `SELECTOR_TMC_OVERHEAT_ERROR` to `TMC_SELECTOR_OVERHEAT_ERROR`
* Sync PEC `IDLER_TMC_OVERHEAT_ERROR` to `TMC_IDLER_OVERHEAT_ERROR`
* Sync PEC `PULLEY_TMC_DRIVER_ERROR` to `TMC_PULLEY_DRIVER_ERROR`
Also releated text
* Sync PEC `SELECTOR_TMC_DRIVER_ERROR` to `TMC_SELECTOR_DRIVER_ERROR`
Also related text
* Sync PEC `IDLER_TMC_DRIVER_ERROR` to `TMC_IDLER_DRIVER_ERROR`
Also related text
* Sync PEC `PULLEY_TMC_DRIVER_RESET` to `TMC_PULLEY_DRIVER_RESET`
* Sync PEC `SELECTOR_TMC_DRIVER_RESET` to `TMC_SELECTOR_DRIVER_RESET`
* Sync PEC `IDLER_TMC_DRIVER_RESET` to `TMC_IDLER_DRIVER_RESET`
* Sync PEC `PULLEY_TMC_UNDERVOLTAGE_ERROR` to `TMC_PULLEY_UNDERVOLTAGE_ERROR`
* Sync PEC `SELECTOR_TMC_UNDERVOLTAGE_ERROR` to `TMC_SELECTOR_UNDERVOLTAGE_ERROR`
* Sync PEC `IDLER_TMC_UNDERVOLTAGE_ERROR` to `TMC_IDLER_UNDERVOLTAGE_ERROR`
* Sync PEC `PULLEY_TMC_DRIVER_SHORTED` to `TMC_PULLEY_DRIVER_SHORTED`
Also related text
* Sync PEC `SELECTOR_TMC_DRIVER_SHORTED` to `TMC_SELECTOR_DRIVER_SHORTED`
Also related text
* Sync PEC `IDLER_TMC_DRIVER_SHORTED` to `TMC_IDLER_DRIVER_SHORTED`
Also related text
* Sync PEC `PULLEY_SELFTEST_FAILED` to `MMU_PULLEY_SELFTEST_FAILED`
Also related text
* Sync PEC `SELECTOR_SELFTEST_FAILED` to `MMU_SELECTOR_SELFTEST_FAILED`
Also releated text
* Sync PEC `IDLER_SELFTEST_FAILED` to `MMU_IDLER_SELFTEST_FAILED`
Also related text
* Sync PEC fix MMU_MMU
Update MMU MCU UNDERPOWER
* Sync PEC `FIL_ALREADY_LOADED` to `FILAMENT_ALREADY_LOADED`
Also related text
* Add Prusa Error Codes check script
* Remove `:` at FINDA and FSENSOR as it is in other tiles
* Sync
FSENSOR_DIDNT_TRIGGER
MSG_DESC_SELECTOR_CANNOT_MOVE
MSG_DESC_IDLER_CANNOT_MOVE
MSG_DESC_FW_UPDATE_NEEDED
FILAMENT_ALREADY_LOADED
* Add MMU UNKOWN_ERROR PEC
bFilamentAction variable is never reset, even after
disabling the heaters.
Steps to reproduce:
1. Boot-up printer
2. Select Load to Nozzle.
3. Select PLA (215°C) target
4. Select Filament 1
5. Wait for load to be successful
6. Go to Preheat submenu and select Cooldown (last menu item)
7. Observe target temperature on the status screen is now 0°C
8. Select Load to Nozzle again.
9. Select Filament 2.
* Expected behavior target temperature IS NOT 0°C
* Actual behavior target temperature IS 0°C
Change in memory:
Flash: -26 bytes
SRAM: 0 bytes
Sync with the 32-bit side.
The ReportingRAII does not handle recursion.
Fixes an issue with the multiple calls to
BeginReport() and EndReport()
Change in memory:
Flash: +14 bytes
SRAM: 0 bytes
If the protocol reports and error and give errorCode
a value. When the error is resolved, errorCode is not reset to OK.
If the MMU is not in an error state I would expect errorCode to reflect that.
This fixes MMUCurrentErrorCode()
Change in memory:
Flash: +12 bytes
SRAM: 0 bytes
Restores 3.12 sequence which was working well before.
M600 "L" parameter now works like M702 "U" parameter.
Removed a lot of the unused parameters which were copied
from Marlin 2.
Change in memory:
Flash: +96 bytes
Code size increases a bit but keep in mind the PR
that broke the behavior "saved" 182 bytes:
https://github.com/prusa3d/Prusa-Firmware/pull/4063
So I think this code size increase is OK
Change in memory:
Flash: +84 bytes
SRAM: 0 bytes
The new code did not take into account the minus sign.
The template for menu_draw_P is removed since there is no benefit in
uint8_t version of this function since the value
is converted to two bytes anyway by lcd_printf_P.
Change in memory:
Flash: -92 bytes
SRAM: 0 bytes
If MMU slot is outside of range, then we rather the printer
not do anything. Currently it would accidentally assume
the MMU is disabled. This may have undesireable results.
No change in memory
If the remaining print time is more than 10.9 hours at 100%
then increasing the feedrate multiplier
to 101% or more will yield an unrealistic time due to overflow occuring.
Change in memory:
Flash +2 bytes
SRAM: 0 bytes
Guard the feedmultiply code with
lcd_encoder.
if lcd_encoder = 0, then there is no need to check if
feedmultiply should be updated.
Also set lcd_encoder to zero in one line to consume the rotation event.
Change in memory:
Flash: -40 bytes
SRAM: 0 bytes
Shouldn't make a difference since the array is already defined as 8B long, but I just found it weird and surprising when I noticed only 7 lines were defined
Guard the lcd_display_message_fullscreen_P call by blocks_queued(). If there are no planned moves, there is no need to render this message, it creates a weird LCD draw noticable by the user.
Change in memory:
Flash: +10 bytes
SRAM: 0 bytes
We need to call BeginReport and EndReport
otherwise the SD filename is not shown when printing
This only affects single material MMU gcodes
Change in memory:
Flash: -4 bytes
SRAM: 0 bytes
Drop the sound feedback in lcd_v2_calibration
when switching to lcd_generic_preheat_menu
If a single filament setup (no MMU) has filament loaded, it will jump
immediately to lcd_generic_preheat_menu
this created double feedback.
Let's just drop the feedback since the transition
between menus is very fast.
Change in memory:
Flash: -8 bytes
For MMU users: This happens when the user
selects a filament to load from 1 to 5
For non-MMU: this happens when clicking
the knob within 2 seconds.
Additionally fixed the code indendation
it was a mix of spaces and tabs
Changes in
lcd_implementation_drawmenu_sdfile
and
lcd_implementation_drawmenu_sddirectory
seem to save the most.
Change in memory:
Flash: -72 bytes
SRAM: 0 bytes
Initialise EEPROM_CHECK_MODE always
But if farm mode is detected, update the Check mode to Strict
Initialise EEPROM_NOZZLE_DIAMETER on farm mode.
When opening the menus this value is set automatically to
_Diameter_400 anyway so this should be fine.
No change in memory on Multilang build
There are only 3 possible values. No need to check for two of them
to rule of the last value. Instead simply check for the last value only.
Change in memory:
Flash: -16 bytes
SRAM: 0 bytes
Found these a few months ago when I was trying some other optimization. Don't want to make a PR just for this, so I'll just slide it here in this existing PR.
!variable.running() || variable.expired()
is equal to
variable.expired_cont()
The latter required less flash memory
Change in memory:
Flash: -28 bytes
SRAM: 0 bytes
We should let EndReport set the custom message type state to Status
This will ensure the SD file name is shown correctly AFTER we've shown
the visualisation
Currently the visualisation is cut off in the middle by ReportProgressHook
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
The old implementation would fail if the message was in progmem at address 0xffff or 0x0000 (both unlikely). It would also fail if the eeprom was initialized to some other random value, which could have been dangerous when displayed as a full screen message.
- currentValue must be initialised when entering the menu
- Consume lcd_encoder value when editing an item
Change in memory:
Flash: +40 bytes
SRAM: 0 bytes
The feedback is produced due to the user clicking the knob
the menu_goto call should therefore not trigger additional feedback when
switching between menus.
No change in memory
Properly increment menu_item when the menu item is clicked so that you don't get multiple menu items clicked if in view (when the menu code is deduplicated to functions)
There is no need to check if every axis bit with each for-loop
iteration. We just need to check if a given axit bit is set.
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
lcd_encoder was int32_t (4 bytes) because of the menu code
when editing through the menus, the menus only accept
int16_t so it doesnt make sense to use int32_t.
Change in memory:
Flash: -892 bytes
SRAM: -2 bytes
This change needs to be approved of course due to it affecting UI
The affect UI is only one menu
lcd_settings_linearity_correction_menu
I doubt many users are using this menu except very advanced users.
I propose we delete the variant of menu_draw_P which was used for
uint8_t but renders them as floats.
Instead treat
uint8_t same as int16_t i.e. just render integers.
Keeping it simple :) Solve our fanSpeed problem.
Change in memory:
Flash: -140 bytes
SRAM: -2 bytes
These variables only range from 0 to 255
For the menus we currently need to convert fanSpeed to int16_t.
Change in memory:
Flash: -160 bytes
SRAM: -2 bytes
3d-gussner
Guðni Már Gilbert
Alex Voinea
VintagePC
Scott Mudge
D.R.racer