Don't start moving the E-motor immediately
Instead of starting the E-motor move when the load to extruder starts,
we can start when we are loading to the fsensor. At that stage
the MMU has changed from a fast load to a slow load.
Because it looks like the communication drop outs are caused by some electrical issues and we can loose even a byte from the version response, which is deadly for future operation.
When a Progress report is started, we set the CustomMsg to MMUProgress.
But there was an issue where, once the reported "Progress" action was done.
We did not reset the CustomMsg to Status. So if we are printing from the
SD card, the file name is not displayed on the LCD.
Communication timeout and Protocol Errors are now distinguished.
In case of a Protocol Error, the printer waits for heartBeatTimeout to allow filling up the input UART buffer (we expect the MMU still produces some bytes).
Once the timeout elapsed, the input UART buffer is cleared and a new Start Sequence is initiated.
Fix the unload procedure when the user has paused a print
then stopped the print after the temperature has reached below 175°C
Now the E-motor will move as expected
This is a draft PR showing the potential 3x retry implementation on the printer's side.
It is much less code and looks more reliable than the same functionality in the MMU FW.
Still, more work needs to be done:
- [ ] Button is sent to the MMU even before returning from the parking position
- [ ] Then the button is sent again
- [ ] Then the printer runs out of retryAttempts
We need to find a better spot to check for "automatic" retry and issuing of the buttons
* Fix MK3S buttons being processed too slowly
After a button is selected on the MK3S MMU error screen, we need to process it before asking for another MMU Query.
Because the MMU Query will make the Error screen return and overwrite the status screen
* Add back CheckUserInput for ButtonPushed event
When a FSENSOR error happens, the first step for the MK3S should be to stop any loading by stopping the E-motor.
From this point, the buttons should determine what the MK3S does next.
* FSENSOR_DIDNT_TRIGGER
* FSENSOR_DIDNT_GO_OFF
The Done button does not Move the E-motor because it
expects the user to have manually resolved the problem
Also if the filament is in the gears, we cannot pull the filament out.
In this case the Retry button is more suited as it will unload the filament.
lcd_encoder_diff would be set to 0 if lcd_update_enable(true)
is called outside ReportErrorHookMonitor
This would put enc_dif out of sync with lcd_encoder_diff and could cause false rotation triggering
It turned out the runout is caused by the ramming sequence in the G-code, which is interpreted before the actual MMU command gets into processing.
The frequency of these errors/runouts differed one machine from another and was really hard to track down.
Therefore - once the MMU is enabled (active and running) we'll disable filament runout handling caused by the printer's filament sensor.
There are still printers which suffer from spurious runouts for no reason.
For testing purposes, runout will be disabled until the real cause is found.
The following situation is now fixed, steps:
1. Load filament through LCD
2. Load to nozzle through LCD
3. Before filament reaches Fsensor => turn off the printer
4. Wait a few seconds and then turn the printer on again
5. Start a print through the SD card
6. Printer will unload and then re-load the filament
Previously in step 6, the printer would start a print without any
filament loaded.
- Dependent on current MMU error being processed
- Includes rename of LEFT_BUTTON_CHOICE -> LCD_LEFT_BUTTON_CHOICE (and right, middle as well) to avoid confusion with MMU buttons' ordering
Guðni Már Gilbert
D.R.racer
Alex Voinea
VintagePC