Instead of including Configuration_prusa.h directly, include
Configuration_var which then includes the proper variant file though a
preprocessor macro.
This allows to keep the existing build system intact, but also redefine
at compile time the final header without having to make copies on the
file system.
- Work-around SOURCE flags being reset for each project when setting the
random-seed property by calling a support function.
- Likewise, set correct flags for reproducibility when creating archives.
- Strip source prefix paths from debug info
This should set the EPOCH using the last git commit date when available,
but it's not currently implemented. Just set the EPOCH to be 0 for now.
Removes a missing return warning.
Looks like we don't handle overflow at the moment and in all surrounding
code, so let's remove the return value for now.
This generates a warning under -Wextra, since in most cases a const
value doesn't prevent buggy code (as copies are allowed) while
preventing some optimizations (such as move operations) to take place.
Consume any pending LCD click after the temperature model calibration.
Since we're already in the status menu, the usual consume action is not
done automatically here.
The current code forces any warning to return the user to the status
screen in order to show the message.
Thermal anomaly warnings can repeat at very short intervals, making menu
navigation (to pause/tune the print) impossible.
We now check if the message to be displayed is the same and only force a
kickback for new messages.
This partially reverts https://github.com/prusa3d/Prusa-Firmware/pull/3600
since we need the string to be null terminated for ease of comparison.
We pad the status line at display time instead using the new
lcd_print_pad() function which achieves the same effect.
In ultralcd_init() do not use lcd_setstatuspgm() to initialize the
welcome message.
The internal call to lcd_finishstatus() requires the serial to be
already available. Split the function into lcd_padstatus() to pre-pad
the string and save some space.
Fix regression introduced in fc10ca3146.
Accept incoming serial commands without line numbers (assumed to be
injected by the host), but do not reset the last line count when doing
so.
Now that lcd_status_message is now initialised correctly at boot-up,
this for-loop is no longer required. Now lcd_status_message is
only set in lcd_updatestatus() which always calls lcd_finishstatus()
lcd_finishstatus() makes sure the message does not exceed 20 characters
Saves 34 bytes of flash
static variables are automatically zero initialised. Now that the
status line message is initialised in ultralcd_init(), we don't
need to set the variable in global scope.
Saves 22 bytes of flash and 1 byte of SRAM
Since mmu_loop() is called in the main loop() function
when the MMU is disabled, we need to utilise the
MMU protocol layer to prevent FINDA runout from happening
if MMU is disabled.
We also need to keep in mind we probably can't trigger
a FINDA runout in the middle of a Q0 query.
So my solution now is to wait for the "Finished" state
and check if the FINDA is off during printing.
When "Finished" state appears, the FINDA value should be up
to date.
During first layer calibration we have the live Z baby step menu
on the LCD and the user can tune their Z offset live.
Once the first layer calibration is done, we want to exit the menu
immediately. For this purpose it is much more efficient to
call lcd_return_to_status(). There is no visual difference
on the LCD for the user.
Change in memory footprint:
Flash: -34 bytes
SRAM: -1 byte
We want to move the Z-axis after the XY move is done.
raise_z cannot be used here because it relies
on current_position[] for all axis.
It is actually 10 bytes cheaper to use the previous method
because syncing current_position with lastpos is surprisingly expensive
Don't render full screen for Loading Filament X
this is already done in load_filament_to_nozzle
so no need to do it twice
Change in memory:
Flash: -54 bytes
SRAM: 0 bytes
This fixes an issue where the assumed slot to use is unknown and
the printer will hang on loading filament 100.
Another good thing is this is an old user feature request which
we have in our 3.12 milestone.
Change in memory:
Flash: +14 bytes
SRAM: -1 bytes
If the endstops kick in, then st_get_position_mm shows the actual travel distance. current_position[Z-AXIS] does not get updated correctly thus we cannot use it when unhomed.
current_position[Z-AXIS] is later set to Z_MAX_POS,
we cannot use that either to calculate the travel distance
Removed the "plan" parameter.
We were incorrectly returning from the function if the printer was homed,
but plan = false. This would leave current_position with an incorrect value
If the printer is homed => finish the move and return the travel distance
If the printer is not homed => rely on end stop to prevent damage,
return travel distance even if the endstop stopped the move.
The current unload sequence does not give good results.
The Marlin 2 sequence looks good on my end. This can be later
used to improve M600
Added all the constants from Marlin 2
* Created a new function raise_z() which will move the Z axis by some
X millimeters. If plan = false, the function will return the
actual travel distance since the move is blocking.
* raise_z_above() is refactored to call raise_z()
Now the M701 and M702 will move the Z-axis relatively, and also
when done, revert the Z axis position when done.
This is a similar behavior as in Marlin 2.
It is only used when the MMU is disabled. With the MMU we use a defined ramming sequence.
When the MMU is disabled I borrowed the usages from Marlin 2.
The L parameter only defines the length for the "fast" load length.
Default value is 70mm, same as M600
- remove virtual methods (we only have one fsensor implementation at a time)
- comment out some of the debugging texts
- remove volatile and replace them with proper synchronized access to relevant variables
Don't start moving the E-motor immediately
Instead of starting the E-motor move when the load to extruder starts,
we can start when we are loading to the fsensor. At that stage
the MMU has changed from a fast load to a slow load.
Because it looks like the communication drop outs are caused by some electrical issues and we can loose even a byte from the version response, which is deadly for future operation.
When a Progress report is started, we set the CustomMsg to MMUProgress.
But there was an issue where, once the reported "Progress" action was done.
We did not reset the CustomMsg to Status. So if we are printing from the
SD card, the file name is not displayed on the LCD.
Communication timeout and Protocol Errors are now distinguished.
In case of a Protocol Error, the printer waits for heartBeatTimeout to allow filling up the input UART buffer (we expect the MMU still produces some bytes).
Once the timeout elapsed, the input UART buffer is cleared and a new Start Sequence is initiated.
Fix the unload procedure when the user has paused a print
then stopped the print after the temperature has reached below 175°C
Now the E-motor will move as expected
This is a draft PR showing the potential 3x retry implementation on the printer's side.
It is much less code and looks more reliable than the same functionality in the MMU FW.
Still, more work needs to be done:
- [ ] Button is sent to the MMU even before returning from the parking position
- [ ] Then the button is sent again
- [ ] Then the printer runs out of retryAttempts
We need to find a better spot to check for "automatic" retry and issuing of the buttons
* Fix MK3S buttons being processed too slowly
After a button is selected on the MK3S MMU error screen, we need to process it before asking for another MMU Query.
Because the MMU Query will make the Error screen return and overwrite the status screen
* Add back CheckUserInput for ButtonPushed event
When a FSENSOR error happens, the first step for the MK3S should be to stop any loading by stopping the E-motor.
From this point, the buttons should determine what the MK3S does next.