move dedge preprocessing out of tmc2130_setup_chopper
We can use default_dedge_bit to initialise
the dedge bit in the chopconf constuctor later
No change in memory
Previously Z-axis would not be reset to
TMC2130_GCONF_DYNAMIC_SGSENS
in tmc2130_home_exit() when
TMC2130_STEALTH_Z is defined
Pulled configuration code into one common function
this ensures the registers are set correctly like in tmc2130_init()
Change in memory:
Flash: -206 bytes
SRAM: 0 bytes
The variable always takes a value of subtraction
between two int16_t values. It will also fit into int16_t
Change in memory:
Flash: -50 bytes:
SRAM: 0 bytes
When scrolling through menu items, the rotation event on the knob
takes care of updating the LCD by setting lcd_draw_update.
The menu code doesn't need to do it as well.
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
This is by far the simplest solution to prevent the user from sending
a Load command to the MMU when the FINDA or Filament sensor
is detecting a filament. This may even happen if the sensors are poorly positioned.
Either way a Load in this scenario will make the MMU seem to hang as the
state machine will reject the command.
We could add a full screen message to let the use know
but it would require some memory resources.
For now, just hide the menu item.
Change in memory:
Flash: +16 bytes
SRAM: 0 bytes
Fixed printer_smodel_check for non MMU machines
Commit 136ef96 broke the compatibility check for MK3S without MMU.
May have fixed bug for older MMU machines.
Only comparing up to the length of the value from the g-code, would return equal on older MMU machines trying to run g-code sliced without the MMU.
Unfortunately if that is a feature, it will cause the different printer warning.
as requested in Prusa-Error-Codes PR#97
There will be more separate sources of MCU power errors in the future and reporting each of them separately doesn't make much sense
- especially when the only thing a user can do about it is to check the connectors.
So based on this, the error title has changed a bit (we are not using the full text description in 8bit FW)
Also, update perform the related changes in PO files + add (machine generated) translations.
planner_abort_hard() calls planner_reset_position() which
will set current_position vector to the machine position.
We want to save this position when there is no position already saved
(i.e. when there is no partial back-up or a saved print in RAM)
When a power outage comes, the printer is in the middle of a gcode move.
And at the moment a gcode is executed by the planner, the planner will update
current_position vector to the final destination vector. This means current_position
vector is invalidated during a power outage and so we must check what the
actual machine position is instead and save it.
This was working correctly before, this commit only fixes the regression
in my pull request.
Change in memory:
Flash: -2 bytes
SRAM: 0 bytes
A partial backup is needed in scenarios where the extruder may be
parked after a print is saved. For example during a blocking wait for the user in M600
Or during a MMU error screen.
A sudden power panic at this point would previously save the parked position
into EEPROM. When the print is recovered it would print in mid air.
1) current_position[Z_AXIS] is not always correct. saved_pos[Z_AXIS]
should always represent the correct resume position for the Z-axis
2) Use the saved position to fetch the Z-offset value from
the mesh bed leveling grid. In case the extruder is parked during
power panic, the previous code may extract the wrong mesh
bed leveling offset (due to extruder being located at different
X and Y axis coordinates)
I verified via printf that sizeof(saved_start_position) = 16 (i.e. 4 float values)
We simply want to write 16 bytes to address
EEPROM_UVLO_SAVED_START_POSITION
Change in memory:
Flash: -160 bytes
SRAM: 0 bytes
This allows us to restore the position of all axis saved in RAM
If the extruder had been parked to the side for example
due to filament runout. Then the original position (before parking)
should now be restored
Change in memory:
Flash: +40 bytes
SRAM: 0 bytes
If a print has been saved to RAM such as during a filament runout,
do not overwrite these saved values if a sudden
power panic appears.
Additionally, change the saved types to be the same as power panic when saving to RAM:
- Bed target temperature is uint8_t (0 to 255) instead of float
- Extruder target temperature is uint16_t instead of float
Doing this change allows us to re-use the same global variables and
avoid creating local variables during power panic.
Change in memory:
Flash: -246 bytes
SRAM: -5 bytes
These functions should be able to be re-used during a power panic
- save_print_file_state
- restore_print_file_state
No functional change at the moment.
We're assigning step_rate with the 16-bit value of final_rate
I would expect the comparison to be 16-bit also then.
Change in memory:
Flash: -32 bytes
SRAM: 0 bytes
The filament is never in the nozzle at this point so there
should be no oozing.
When a single material MMU print, I can hear audible noise
from the motor after executing Tx code. After some timeout
(while the heaters still heating up) I can hear the firmware
disable the E-motor. But we can safely disable it immediately
after the try-load-unload sequence.
Change in memory:
Flash: +4 bytes
SRAM: 0 bytes
Guðni Már Gilbert
Yuri D'Elia
Addio
D.R.racer
RoboMagus
3d-gussner