There is a bug where if the printer is recovering a print, it run a
blocking loop to restore the extruder and bed temperatures.
But if a Fan error is triggered in this loop, then the user can't
abort the print via LCD.
If the fan error resolves on its own the 'Resume print' menu will
appear in a few seconds. But if not, then the user can't resume the print
(which is normal). But with the bug above the user can't abort the print either!
The problem is essentially isPrintPaused variable is cleared too early.
We should wait until the print is completely restored first.
Steps to reproduce:
1. Start a print
2. Pause the print
3. Wait for extruder temperature to fall at lest 180°C
4. Click 'Resume' print
5. While heating, stop the hotend fan and wait for a few seconds until an error is raised
6. Observe issue => 'Stop print' menu item is gone!
PFW-1542
There is no problem with opening the menu during first layer
calibration. Removing this condition simplifies the code a little bit.
Change in memory:
Flash: -8 bytes
SRAM: 0 bytes
Drop the ALPHA/BETA/custom version handling. Set the version string and
firmware date based on the current tree description which has all the
required details.
Allow to override the repository information via cmake.
Use a truncated commit hash to set the internal commit number for
compatibility.
Rebase and fix issues
This fixes the undefined _T(label) reference, at the expense of a few
extra bytes.
I would argue this is worth the cost for the ability to check
translation references for the future. The warning happens because
`lang-check` cannot check a reference which is not _directly_ a catalog
entry.
We could introduce a method to suppress this warning (either a new macro
or some ///IGNORE comment), but that would mean that the additional
translation check is completely bypassed, defeating the purpose.
We can't clear eFilamentAction in every case in mFilamentItem()
mFilamentItem() can trigger a call to M701 and M702 e.g. for Autoloading
and eFilamentAction must be cleared by the gcode to prevent
the user from triggering another Autoload (which will crashe the FW)
The same applies to submenus. Now the MMU submenus clear eFilamentAction
only when the action is done.
For MMU Unload Filament item, eFilamentAction is only cleared after
the unload_filament() call is done running. This fixes an issue where
the menu item can be selected again while the first unload is still
running.
The if statement is checked in lcd_sdcard_menu()
so checking it again these functions is
redundant since it's always going to be true.
Tested on MK3S+
Change in memory:
Flash: -22 bytes
SRAM: 0 bytes
An example is when Unloading filament with MMU.
After the unload completes successfully, some menu items disappeared.
Because mFilamentBack() was not called
Change in memory:
Flash: -56 bytes
SRAM: 0 bytes
Kudos to @3d-gussner for finding the issue
Steps to reproduce:
1. reset printer
2. select Load filament
3. go back to main
4. LCD menu is very limited
5. To get all menus back select 6. Preheat
7. back to main
This commit is my proposed fix.
When eFilamentAction is equal to
FilamentAction::Load we must reset it to FilamentAction::None
when the Back button in Load Filament is selected
Change in memory:
Flash: -26 bytes
SRAM: 0 bytes
Proposal to fix some of the issues with the initial implementation
it is safer to use the status line code to print the message so
there aren't any conflicts in the LCD cursor position.
Allow inserting a byte into any position in the LCD status message
Also, add a variable to control from which index in the array
should the message start printing. This is very useful for progress
bars and messages which continually update. I think we can save some
memory by applying this to Mesh Bed Leveling later.
Change in memory:
Flash: +106 bytes
SRAM: +1 byte
Remove loading_flag and check for eFilamentAction instead which already
flags both load/unload (in addition to mmu actions).
Correctly transition from AutoLoad to Load as soon as the operation
cannot be cancelled anymore as opposed to resetting it.
Do not blidnly clear the loading_flag, check for it!
Just disallowing the SD menu while loading is being performed is not
sufficient, since the menu can be entered also by inserting card while
loading is taking place.
This is also nicer in behavior, as we allow to navigate the SD card
while loading.
All custom commands are transitory and eventually switch back to Idle
state by themselves.
It doesn't make any sense to explicitly check for Layer1Cal: any
non-idle state is active by design.
Fix this check in the main menu. This is probably incomplete (Layer1Cal
is incorrectly used in several other places).
This is by far the simplest solution to prevent the user from sending
a Load command to the MMU when the FINDA or Filament sensor
is detecting a filament. This may even happen if the sensors are poorly positioned.
Either way a Load in this scenario will make the MMU seem to hang as the
state machine will reject the command.
We could add a full screen message to let the use know
but it would require some memory resources.
For now, just hide the menu item.
Change in memory:
Flash: +16 bytes
SRAM: 0 bytes
gudnimg
3d-gussner
vintagepc
Yuri D'Elia
sarusani
Alex Voinea
Guðni Már Gilbert