Currently we are queuing many small 2 mm E-moves until the filament
sensor triggers. We do this because we never abort any queued moves,
so making small 2 mm moves ensures we do not move the E-motor more than
2 mm past the filament sensor.
Unfortunately, when E-cool mode is enabled, the E-motor will create
audible clicking sounds (similar one hears during jam or a loose grub
screw). A workaround for this is to queue one or more very long moves.
Where very long is something of the order of hundreds of millimeters. I
have it set to 350 mm but it's just a random constant really. Keep in
mind the firmware will block too large E-moves, if I recall correctly
it was anything above > 450 mm (see PREVENT_LENGTHY_EXTRUDE)
In order to use very long moves, we must somehow stop the E-motor from
moving once the filament sensor triggers. In other words, throw away
what's left of the current E-motor move. For this simple purpose we can
use planner_abort_hard() but we must set planner_aborted to false
afterwards because the code architecture does not allow the main loop()
to run until the Toolchange command is done processing.
Change in memory:
Flash: +18 bytes
SRAM: 0 bytes
There is no need to repeat:
lcd_update_enable(true);
lcd_update(2);
Also lcd_clear() is redundant because lcd_update(2) will clear the LCD
Change in memory:
Flash: -16 bytes
SRAM: 0 bytes
Previously when the firmware called M701/M702 manually
there was no Z lift. But after we added support for the Z
parameter we set the default to 50mm.
Change strings "M701" to "M701 Z0" and "M702" to "M702 Z0"
to restore the previous behavior from before 3.13.
Also pulled the gcodes into PROGMEM in message.cpp
along with M83 and M84 to save memory.
Change in memory:
Flash: -34 bytes
SRAM: 0 bytes
When the extruder lifts up after completing the Purge line,
the baby stepping is not allowed for a short time. This dismisses
the menu. We don't want this behavior, so only apply the Z-axis requirement
when printing.
Change in memory:
Flash: +8 bytes
SRAM: 0 bytes
Add lcd_commands_type == LcdCommands::Layer1Cal
just in case blocks_queued() is 0 for one instant between
lcd_command steps
Change in memory:
Flash: +8 bytes
SRAM: 0 bytes
Fixes an issue with running first layer calibration twice in a row.
Improvements:
Now the Z baby step menu closes automatically when first layer calibration is done.
No need to wait for a timeout or close the menu manually by setting a variable
If the baby stepping menu is open, and suddenly
the printer enters a state where baby stepping
is not allowed.
The printer will save the last value before closing the menu.
When LcdCommands != Idle, don't dismiss
the Z baby step menu. This saves 20B
Change in memory:
Flash: -130 bytes
SRAM: 0 bytes
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
* M600 used 1°C threshold, which may increase the waiting time a bit
* Wizard used 3°C
Sync both to use TEMP_HYSTERESIS for consistancy
No change in memory footprint
Use 5°C threshold to be consistant with other parts
of the firmware.
Relying on 95% of the target temperature creates
a dependency on the temperature:
PLA: Target = 215°C, threshold = 10.75°C
PETG: Target = 230°C, threshold = 11.5°C
ABS: Target = 255°C, threshold = 12.75°C
ASA: Target =260°C, threshold = 13.0°C
PC: Target = 275°C, threshold = 13.75°C
My proposal is we instead use a constant
TEMP_HYSTERESIS = 5, which is consistent with
M109, and behavior when restoring print from RAM
and some of the MMU code (like unload function)
Change in memory:
Flash: +2 bytes
SRAM: 0 bytes
This commit adds the ability for the firmware to dim and wake the
backlight when LCD updates are disabled. Such as in the MMU error screen
or when rendering full screen messages which typically
disable the LCD updates to prevent the status screen from rendering.
Fixes#2777
Change in memory:
Flash: -26 bytes
SRAM: +1 byte
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
Model UV as power-invariant, so that scaling P doesn't change the
intercept location (that is, the zero point remains at the same
temperature even for more powerful heaters).
NOTE: It's not clear to me whether this is generally true (couldn't
find a datasheet from the same heater in diffent power variants
showing the efficiency loss)
- Expose TEMP_MODEL_fS and TEMP_MODEL_LAG as D and L respectively,
initializing the default values based on the previous hard-coded
values.
- Always round L to the effective sample lag to future-proof model
upgrades or changes (the stored value _is_ the effective value).
- Introduce UV as a new linear term for PTC heaters, defaulting
to an identity for model backward-compatibility.
Guðni Már Gilbert
Alex Voinea
3d-gussner
D.R.racer
DRracer
Yuri D'Elia