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.
* FSENSOR_DIDNT_TRIGGER
* FSENSOR_DIDNT_GO_OFF
The Done button does not Move the E-motor because it
expects the user to have manually resolved the problem
Also if the filament is in the gears, we cannot pull the filament out.
In this case the Retry button is more suited as it will unload the filament.
lcd_encoder_diff would be set to 0 if lcd_update_enable(true)
is called outside ReportErrorHookMonitor
This would put enc_dif out of sync with lcd_encoder_diff and could cause false rotation triggering
It turned out the runout is caused by the ramming sequence in the G-code, which is interpreted before the actual MMU command gets into processing.
The frequency of these errors/runouts differed one machine from another and was really hard to track down.
Therefore - once the MMU is enabled (active and running) we'll disable filament runout handling caused by the printer's filament sensor.
There are still printers which suffer from spurious runouts for no reason.
For testing purposes, runout will be disabled until the real cause is found.
The following situation is now fixed, steps:
1. Load filament through LCD
2. Load to nozzle through LCD
3. Before filament reaches Fsensor => turn off the printer
4. Wait a few seconds and then turn the printer on again
5. Start a print through the SD card
6. Printer will unload and then re-load the filament
Previously in step 6, the printer would start a print without any
filament loaded.
- Dependent on current MMU error being processed
- Includes rename of LEFT_BUTTON_CHOICE -> LCD_LEFT_BUTTON_CHOICE (and right, middle as well) to avoid confusion with MMU buttons' ordering
To render the thermometer and degree symbols
the CGRAM table will instead swap out
the feedrate and clock symbol when
lcd_set_custom_characters_nextpage()
is called.
- We need to take into account additional 35mm move by the MMU.
- While the fsensor is not triggered, reduce the extruder movement each step from 20mm to 5mm. This should help reduce the variance in the filaments position before we run the final load to nozzle sequence.
- Fixed a bug where the feed rate was 60x higher than intended
- Adjusted the sequence via trial and error. The sequence where the filament has not exited the nozzle is 35mm shorter than the previous implementation
- I reduced the feed rate slightly (by 1mm/s) on the fast load sequence
- combined lcd_show_three_choices_prompt_P and lcd_show_two_choices_prompt_P into one function called lcd_show_choices_prompt_P
- Removed third_col parameter
- Added an enum to make the button selection result more readable
- Rename lcd_show_multiscreen_message_two_choices_and_wait_P to lcd_show_multiscreen_message_with_choices_and_wait_P
- Move MMU error screen from ReportError() to ReportErrorHook()
- Fix the menu selection to work for menus with either two choices or three choices
- The buttons shown on the MMU error menu are now determined by the definition of btnOperation[]
getFilamentPresent returns the state of the IO pin of the sensor.
So we should use AT_FSENSOR instead of IN_NOZZLE
since the fsensor does not know if the filament is actually in the nozzle.
Such that:
MMU2:E=32766ErrorTitleTextDescription
Becomes:
MMU2:E=32766 ErrorTitle TextDescription
Also simplified the process of combining ErrorTitle and TextDescription
into the msg buffer by using snprintf. This is saver since we only
use dstSize in one place instead of two.
This could cause the printer to crash. The Serial Stream would show
a garbled string.
Also included in this commit:
* The buffer size is increased from 64 bytes to 192 bytes. We need to
take into account the length of the ErrorTitle and ErrorDescription.
* Fix overwrite in ErrorCode message buffer.
When snprintf() if called we need to read the return value to see how
many bytes were written. Then when we call strncpy_P() through
TranslateProgress(), we need to tell the code to start writing
at byte 'len', or &msg[len]. Also we need to update the byte size
which strncpy_P() is allowed to write (64 - len).
This could cause the printer to crash. The Serial Stream would show
a garbled string and the same corruption would appear on the Status
Screen's status line.
makes the code a bit shorter as well, because the compiler can be sure
that the variables are not accessed from the outside of the
fsensor.cpp compilation unit.
Update fw-build.sh
- Output used space of each translation (easier to troubleshoot)
- Read config.h max size per translation
- output variant .map files (easier to troubleshoot and finding missing/unused messages)
This message is never actually shown on the LCD (it's immediately
overwritten by other content). It also include g-code in a translatable
string, which is not a good idea. It's also otherwise identical to
MSG_V2_CALIBRATION, which we should have used.
Just remove it and save some space in the process.
Having the original PRINTER_ACTIVE macro copied at multiple spots doesn't make sense.
Refactoring it into a non-inline function saved ~400 bytes of code.
It should be safe in terms of performance, all occurrences are at non-time critical spots.
Add an additional parameter to control the position of second choice
prompt position (while defaulting to the old).
This allows Yes/No prompts to be equally spaced.
Modify lcd_show_multiscreen_message_two_choices_and_wait_P to also
handle single-screen or empty (no-clear) prompts, making other functions
redundant. Saves 76 bytes.
Change existing functions to simply call
lcd_show_multiscreen_message_two_choices_and_wait_P with the correct
arguments.
This changes the prompt of existing Yes/No messages: the previous prompt
would use the last two lines of the LCD, while the new prompt is using
just the last line of the LCD instead.
Translation do not require updates, since the Yes/No translation was
already the same in both implementations.
Allow running the model checking during autotuning, with the only
exception being the parameter estimation stage where we alter the same
value which is used by the checker (done to conserve memory/code).
With previous changes the model checker will disable/enable itself when
passing through an unavailable R vector entry, allowing to start the
calibration by checking only the stages where the part fan is disabled.
The C/R0 values should be stable enough to provide a fail-safe mechanism
for printers of the same variant right from the factory.
Instead of assuming the model state is always valid, allow NAN values to
pass-through the various check/estimation stages.
This allows running the model checker with incomplete parameters (for
example, missing entries in the R vector) and resume automatically.
3d-gussner
D.R.racer
Guðni Már Gilbert
Alex Voinea
VintagePC
Yuri D'Elia