Restores 3.12 sequence which was working well before.
M600 "L" parameter now works like M702 "U" parameter.
Removed a lot of the unused parameters which were copied
from Marlin 2.
Change in memory:
Flash: +96 bytes
Code size increases a bit but keep in mind the PR
that broke the behavior "saved" 182 bytes:
https://github.com/prusa3d/Prusa-Firmware/pull/4063
So I think this code size increase is OK
Change in memory:
Flash: +84 bytes
SRAM: 0 bytes
The new code did not take into account the minus sign.
The template for menu_draw_P is removed since there is no benefit in
uint8_t version of this function since the value
is converted to two bytes anyway by lcd_printf_P.
Change in memory:
Flash: -92 bytes
SRAM: 0 bytes
If MMU slot is outside of range, then we rather the printer
not do anything. Currently it would accidentally assume
the MMU is disabled. This may have undesireable results.
No change in memory
If the remaining print time is more than 10.9 hours at 100%
then increasing the feedrate multiplier
to 101% or more will yield an unrealistic time due to overflow occuring.
Change in memory:
Flash +2 bytes
SRAM: 0 bytes
Guard the feedmultiply code with
lcd_encoder.
if lcd_encoder = 0, then there is no need to check if
feedmultiply should be updated.
Also set lcd_encoder to zero in one line to consume the rotation event.
Change in memory:
Flash: -40 bytes
SRAM: 0 bytes
Shouldn't make a difference since the array is already defined as 8B long, but I just found it weird and surprising when I noticed only 7 lines were defined
Guard the lcd_display_message_fullscreen_P call by blocks_queued(). If there are no planned moves, there is no need to render this message, it creates a weird LCD draw noticable by the user.
Change in memory:
Flash: +10 bytes
SRAM: 0 bytes
We need to call BeginReport and EndReport
otherwise the SD filename is not shown when printing
This only affects single material MMU gcodes
Change in memory:
Flash: -4 bytes
SRAM: 0 bytes
Drop the sound feedback in lcd_v2_calibration
when switching to lcd_generic_preheat_menu
If a single filament setup (no MMU) has filament loaded, it will jump
immediately to lcd_generic_preheat_menu
this created double feedback.
Let's just drop the feedback since the transition
between menus is very fast.
Change in memory:
Flash: -8 bytes
For MMU users: This happens when the user
selects a filament to load from 1 to 5
For non-MMU: this happens when clicking
the knob within 2 seconds.
Additionally fixed the code indendation
it was a mix of spaces and tabs
Changes in
lcd_implementation_drawmenu_sdfile
and
lcd_implementation_drawmenu_sddirectory
seem to save the most.
Change in memory:
Flash: -72 bytes
SRAM: 0 bytes
Initialise EEPROM_CHECK_MODE always
But if farm mode is detected, update the Check mode to Strict
Initialise EEPROM_NOZZLE_DIAMETER on farm mode.
When opening the menus this value is set automatically to
_Diameter_400 anyway so this should be fine.
No change in memory on Multilang build
There are only 3 possible values. No need to check for two of them
to rule of the last value. Instead simply check for the last value only.
Change in memory:
Flash: -16 bytes
SRAM: 0 bytes
Found these a few months ago when I was trying some other optimization. Don't want to make a PR just for this, so I'll just slide it here in this existing PR.
!variable.running() || variable.expired()
is equal to
variable.expired_cont()
The latter required less flash memory
Change in memory:
Flash: -28 bytes
SRAM: 0 bytes
We should let EndReport set the custom message type state to Status
This will ensure the SD file name is shown correctly AFTER we've shown
the visualisation
Currently the visualisation is cut off in the middle by ReportProgressHook
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
The old implementation would fail if the message was in progmem at address 0xffff or 0x0000 (both unlikely). It would also fail if the eeprom was initialized to some other random value, which could have been dangerous when displayed as a full screen message.
- 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
Guðni Már Gilbert
3d-gussner
VintagePC
Alex Voinea
Scott Mudge
D.R.racer