The fact that the relationship between
machine position and pixel index is not linear
means we cannot simply rely on comparing
the previous position to the next machine position. i.e derivative of E_AXIS
Because around the max amplitude of the triangle wave
the slope will suddenly change sign and will create a deadzone
which has width 2*mm_per_pixel.
For MMU2S this is ~10mm (or two pixels).
Instead we should split the moves.
And only plan the 2nd move once we're
at the top of the triangle wave. That way we don't really care about the position delta.
Now we just calculate the current y(x)
position relative to current position and divide by mm_per_pixel.
If there is a delta measured with unit 'pixel' then that means
its time to render the next pixel.
This solution seems to work well so far on my end.
Change in memory:
Flash: +2 bytes
SRAM: 0 bytes
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