- currentValue must be initialised when entering the menu
- Consume lcd_encoder value when editing an item
Change in memory:
Flash: +40 bytes
SRAM: 0 bytes
The feedback is produced due to the user clicking the knob
the menu_goto call should therefore not trigger additional feedback when
switching between menus.
No change in memory
Properly increment menu_item when the menu item is clicked so that you don't get multiple menu items clicked if in view (when the menu code is deduplicated to functions)
There is no need to check if every axis bit with each for-loop
iteration. We just need to check if a given axit bit is set.
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
lcd_encoder was int32_t (4 bytes) because of the menu code
when editing through the menus, the menus only accept
int16_t so it doesnt make sense to use int32_t.
Change in memory:
Flash: -892 bytes
SRAM: -2 bytes
This change needs to be approved of course due to it affecting UI
The affect UI is only one menu
lcd_settings_linearity_correction_menu
I doubt many users are using this menu except very advanced users.
I propose we delete the variant of menu_draw_P which was used for
uint8_t but renders them as floats.
Instead treat
uint8_t same as int16_t i.e. just render integers.
Keeping it simple :) Solve our fanSpeed problem.
Change in memory:
Flash: -140 bytes
SRAM: -2 bytes
These variables only range from 0 to 255
For the menus we currently need to convert fanSpeed to int16_t.
Change in memory:
Flash: -160 bytes
SRAM: -2 bytes
This fixes the spurious feedback when rotating the knob
because lcd_update is called much often than the interval
at which the lcd rendering is updated
Change in memory
Flash: -88 bytes
SRAM: -9 bytes
This commit adds the ability for firmware to make sounds when the
knob is clicked or rotated, when LCD updates are disabled.
The improvement here is the sound is being made with one line of code
whether or not LCD updates are enabled or disabled.
Change in memory:
Flash: -24 bytes
SRAM: 0 bytes
Valid values range from -100 to 100. Storing this value as four bytes
(int32_t) is not efficient.
Instead we can store G80 user input temporarily as int32_t and check
if the value is within the allowed range. If it is, then we convert the
int32_t (4 bytes) to int8_t (1 byte).
Change in memory:
Flash: -78 bytes
SRAM: 0 bytes
This way doesn't add any more flash memory.
Calculating the string length or checking for a null byte
will end up increasing flash consumption overall.
This gets rid of float conversion.
We just need to check the 6th character when M862 is detected. This
character gives us the digit after the dot.
Change in memory:
Flash: -20 bytes
SRAM: 0 bytes
For non-time critical code it is more effcient to call a function
rather inlining each division operation.
Change in memory:
Flash: -122 bytes
SRAM: 0 bytes
Rename acceleration_st to acceleration_steps_per_s2 to be same as Marlin 2
Store the accelerator in local variable accel
while we are performing the limit checks.
When limit checks are done we can assign
the block it's acceleration. Especially
block->acceleration_steps_per_s2 is now only written to once, instead of direcly in the limit checks.
Change in memory:
Flash: -118 bytes
SRAM: 0 bytes
Noticed this when exploring another optimisation
By specification exactly which overloaded function to use
we save some memory
Seems to have something to do with doing arithmetic in the function argument
Change in memory:
Flash: -156 bytes
SRAM: 0 bytes
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.
On printers without the MMU no error screen should occur and no attempts of communication with the MMU should be performed -> EEPROM_MMU_ENABLED should default to 0.
PFW-1418
Use "echo:" for thermal model error reporting to avoid octoprint
automatically sending a M112 kill.
Keep using "error:" instead for other thermal errors (MAXTEMP/etc).
This should allow resuming a thermal mode pause with the default
octoprint settings.
This is an 80% solution to PFW-1488 which should be somewhat compatible with the existing languages/translations infrastructure.
I don't see a point in extending the infrastructure a great deal to support some compile-time replacement in order to patch just MSG_DESC_FW_UPDATE_NEEDED.
Related PR: https://github.com/prusa3d/Prusa-Firmware/pull/3993
Main changes:
* setAllTargetHotends() is removed
* setTargetHotendSafe() is removed
* Extruder parameter on setTargetHotend() is dropped
Change in memory:
Flash: -192 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).
The function adds a bit of overhead compared to code_value()
I suspect this function is a relic of the past.
Change in memory:
Flash: -82 bytes
SRAM: 0 bytes
During calibration model warnings are possible/normal. This is
apparently leading some into thinking the hotend might be faulty
and abort the calibration with a hard reset.
Disable warnings/beeps during calibration.
Rely on the error threshold only.
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.
Used lcd_print_pad_P is some obvious places. We can probably use
this function in more places to further save flash memory
Change in memory:
Flash: -268 bytes
SRAM: 0 bytes
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.
During thermal errors all fans are set to full speed.
When the print is resumed or stopped *and* the thermal error is gone,
also restore the autofan state.
Fixes#3893
Running `M310 A` should set the TM calibration bit status if the
autotune procedure was successful.
Partially addresses #3891 and #3890, since running `M310 A F0` should
*still* count as valid calibration data and is not something that can be
replicated by using the LCD (which enforces self-test).
This fixes#3891 without having to set the calibration bit, meaning
that if the model is later re-enabled without a real calibration, a
prompt is shown as expected.
Alert messages are intended to persist above "info" messages, thus
preventing further calibration status updates to be shown (such as
thermal model calibration).
Just set the message as a regular status message.
Fixes#3892
It was only enabled when multiple extruders are enabled
The firmware doesn't support it
and even if the M218 gcode could be used, the code does not compile
Disabling the model during a warn/error condition will also stop
updating the warning/error flag, keeping the printer in an error state.
Clear all flags as well when changing model settings.
Follow Marlin's behavior and simply insert a delay for the requested
duration when using M300 S0.
When S is not specified, use the default tone instead.
Fixes#3856
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
Instead of checking for explicit versions, resume the wizard if some
(new) wizard is missing.
This handles both the old SELFTEST check, the new thermal model
and any future check in the same fashion.
Update the eeprom FW version as soon as migration is complete, to avoid
resetting the CALIBRATION_V2 variable at each reset.
Do not implicitly reset the calibration steps for WizState::Run: do this
only for the menu action.
- Handle the conversion from the V1 calibration status to the V2 bitmap
for all past FW versions.
- Allow to run the wizard in "Restore" mode (for example during upgrade
or service prep) to complete any missing steps.
- Fix service prep to use the above feature by clearing the appropriate
calibration bits.
- Remove exceptions for FW 3.2.0.4 which can now be handled cleanly.
Simplify status tracking:
- S::Restore to continue to the next logical wizard item
- S::Finish for a successful failure
- S::Failed to exit while showing a failure
- Move calibration status/declarations to util.h
- Allows to query the status of each step independently without assuming
any order
- Allows to extend the calibration with new steps transparently
- Generalize force_selftest_if_fw_version() so we can check when upgrading
between arbitrary FW versions.
- Do not call update_current_firmware_version_to_eeprom() prematurely
when forcing self-test (if a reset happens before self-test completes,
the check would be incorrectly skipped on the next run).
3d-gussner
Alex Voinea
Guðni Már Gilbert
D.R.racer
DRracer
Yuri D'Elia
vintagepc
Giles Bathgate
RoboMagus
Yuri D'Elia