This fixes an issue where sometimes
not all 20 pixels are rendered.
It is better to render 1 too many pixels (sometimes), rather than rendering too few.
Change in memory:
Flash: +18 bytes
SRAM: 0 bytes
In case we are running a retry, the firmware
should clear the old rendering before
starting on a new one
Change in memory:
Flash: +6 bytes
SRAM: 0 bytes
It may be useful to view the Sensors menu
while the toolchange loading test is taking
place. For example to see if the reading is flickering
The firmware needs to call lcd_update(0) to update the screen rendering.
Change in memory:
Flash: -2 bytes
SRAM: 0 bytes
The general idea is to keep platform specific implementation away from the MMU state machines as much as we can.
That would enable unit testing the top level MMU state machine and integration into other project as well (if needed).
It may seem counterintuitive to disable the E-motor, but it gets enabled in the planner whenever the E-motor is to move.
The idea behind disbling the E-motor when it won't be needed for some time is to save power and lower the heat of the motor.
Therefore it is especially important to disable the motor before the printer pauses a print due to some MMU error screen.
Because this error is not an MMU error but a printer one, the existing infrastructure has been bent to support such a scenario.
During testing it turned out, that some machines fail to draw the error screen due to previous internal states.
This PR resets the internal states so that the conditions for drawing the error screen are met.
This PR tries to address the 3 different startup scenarios for 1st layer calibration with the MMU:
- 1st lay cal started with correct filament already loaded in the nozzle - we should continue, but skip the first 58mm (first 2 g-codes in the hard coded sequence) of purge line extrusion
- 1st lay cal started with other filament already loaded in the nozzle - we should unload and then issue a toolchange with no extra unload
- 1st lay cal started without loaded filament - we should just do a toolchange with no extra unload
PFW-1457
This is a prototype implementation of having the ability to show an MMU error screen even for printer's errors (during an MMU operation).
Also, the retry count of unloads after failed load the extruder tube is now limited to ~3 attempts.
Technically, since this very error is not an MMU's one (MMU is just fine at this stage) but a printer's one I tried to hack the existing error-reporting infrastructure to handle such a case.
The original idea of this approach was suggested by @vintagePC
The Extra Loading Distance is configurable by the user.
We need to compensate the hardcoded sequence
such that it does not extrude too much or
too little. Currently the firmware
extrudes too little.
Fixes issue where First Layer Cal. triggers an unload before any
filament is loaded
The purpose of this if() statement is to handle the case where
a user or developer is sending T-codes to the printer directly
via Serial. Such as when one first sends T0 and then T4.
And unload must be triggered in-between, we can do this automatically
if FINDA detect filament.
Change in memory:
Flash: -10 bytes
SRAM: 0 bytes
This piece just changes the default extra load length on the MK3 side.
The same needs to be done on the MMU side but:
- the MMU exposes its register for this (so we can change the extra load distance by writing into the register via G-code)
- the printer shall probably set this value on its own after line up of MMU communication
I had a crash when producing an error screen and printer was unhomed.
Extruder was located at the far right side, and immediately crashed when attempting to park.
Since mmu_loop() is called in the main loop() function
when the MMU is disabled, we need to utilise the
MMU protocol layer to prevent FINDA runout from happening
if MMU is disabled.
We also need to keep in mind we probably can't trigger
a FINDA runout in the middle of a Q0 query.
So my solution now is to wait for the "Finished" state
and check if the FINDA is off during printing.
When "Finished" state appears, the FINDA value should be up
to date.
This fixes an issue where the assumed slot to use is unknown and
the printer will hang on loading filament 100.
Another good thing is this is an old user feature request which
we have in our 3.12 milestone.
Change in memory:
Flash: +14 bytes
SRAM: -1 bytes