With these changes the output of `M503 S0` is all you need to restore
the EEPROM. Building on this it is straightforward to save and restore
the EEPROM state using the SD card or external GCode file.
- Added `M145` to set “heatup states” for the LCD menu
- Added `M420` to toggle Mesh Bed Leveling
- Added `M421` to set a single Mesh coordinate
- Extended `Config_PrintSettings` with added M codes
- Cleaned up some comments here and there
Centralised beep code to lcd_buzz().
From gcode_M300() and lcd_quick_feedback().
Enforced max. duration for M300 to 5 seconds.
Corrected description in 'Configuration.h'
LCD_FEEDBACK_FREQUENCY_HZ 0 gives now a silent delay of
LCD_FEEDBACK_FREQUENCY_DURATION_MS.
- MENU_ITEM causes lcd_quick_feedback to be called, so only those calls
to `lcd_goto_menu` outside of the `MENU_ITEM` macro need to set the
`feedback` flag when calling `lcd_goto_menu`.
Because we now can use utf8 with up to 3 bytes per symbol,
lcd_status_message[] must be 3*LCD_WIDTH wide.
Filling up the message, or cutting to length, are fixed to.
Fix for #1832 about at the end.
In 'if (encoderPastThreshold || LCD_CLICKED)' lcdDrawUpdate was not set.
'lcd_status_update_delay'-loop was not effective in function
lcd_status_screen().
The loop prevented the update of the status screen but not the displays
update.
Shifted the loop into lcd_update().
- Some messages should not expire with `PROGRESS_MSG_EXPIRE`.
- Simplify conditional for progress bar with sanity checks.
- Rename `messageTick` to `expireStatusMillis` and make it the expire
time.
I've updated the minimum values from the LCD.
It has been a while that i want to at least fix this.
I have an inductive probe and often i need to set my zOffset to something lower than 0.5.
With the current implementation, the default LCD value is set to 0.5 for some reason.
On my case i need to be able to set it down to 0.0 as my inductive probe can be lower than 0.5.
Before with the LCD we couldn't change this value below 0.5. We had to flash the firmware every time which was painful.
Now we are able to change this value down to 0.0 if needed.
I've also changed the minimum value for Z min acceleration.
In the default configuration it's set to 25 but on the LCD the minimum was 100 which is not coherent.
I've changes the minimum to 10. On this axis, depending on the mechanics/motor drivers we might require very low acceleration, so i guess 10 is somehow realistic.
- Add `Conditionals.h` with calculated configuration values
- Add `SanityCheck.h` with checks for configuration errors
- Remove equivalent code from all configurations
- Move error checks from some sources to `SanityCheck.h` also
- Fix initialization of count_direction in stepper.cpp
When one hit "Stop Print" option in LCD menu, the command buffer was not
cleared. The printer keep moving until the buffer has been emptied.
Actually I could not clear the command buffer as well.. I don't know
why, it doesnt work as expected.
I need to implement a routine inside Stepper ISR to handle such
situation.
Conflicts:
Marlin/dogm_lcd_implementation.h
Marlin/fonts/make_fonts.bat
Claerd conflicts with my own #1621. (His was easy. :-) )
corrected typo in fonts/README.fonts
Applied changes to the new delta-configurations
and deletet there some extra whitespace at the line-endings.
While bunting an other bug I stumbled across:
ultralcd.cpp:1250: warning: comparison between signed and unsigned
integer expressions
Changed to the type of lcd_next_update_millis.
- Add BIT and TEST macros
- Add _APPLY_ macros to stepper.cpp to help with consolidation
- Consolidate code in stepper.cpp using macros
- Apply standards in stepper.cpp
- Use >= 0 instead of > -1 as a better semantic
- Replace DUAL_Y_CARRIAGE with Y_DUAL_STEPPER_DRIVERS
Added option to set Travel Acceleration (non printing moves).
The M204 options was a non sense (S for printing moves and T for retract
moves).
It has been changed to:
P = Printing moves
R = Retract only (no X, Y, Z) moves
T = Travel (non
printing) moves
I will add this info o G-Code wiki in reprap.org. I also advise to put
this info in Marlin next version changelog.
- Fix bug in lcd_control_temperature_menu
- Remove test menu-item left in from multi-line command feature
- Replace literals with translatable strings
- Reduce lcd_preheat code redundancy
- Reduce menu macro redundancy
- Clean up formatting
Introduced lcd_strlen() and lcd_strlen_P().
Replaced the old functions where necessary.
Reworked language_ru.h.
Speeded up test for zero length string in cardreader.cpp
* Adds config parameter `PID_PARAMS_PER_EXTRUDER` - allows single PID
parameters to be used where this would be preferable (e.g. dual
identical extruders)
* When disabled, will use `float Kp, Ki, Kd, Kc;` as before.
Preprocessor macros used to switch between.
* ultralcd.cpp defines extra menus for extra parameters only where
required
* M301 reports `e:xx` only if independent pid parameters enabled
* EEPROM structure still leaves space for 3 extruders worth, when undef
will save single parameter to all extruder positions, but only read the
first
* Switching off saves approx 330 B with no LCD enabled, 2634B with LCD
(RRD) enabled: this is significant.
* LCD modifications should be tested.
* Depending on extruder count, will add menu items for ultralcd to edit
individual PID parameters for each extruder
* Added menu items to each language_xx.h
* Builds OK, but recommend testing with typical LCD
Small changes (and formatting to confuse the diff’er) which first
allows DOGLCD and LCD_PROGRESS_BAR to be enabled in tandem, then a
#warning (rather than error) that the extra progress bar / message
options don’t apply to graphical displays at this time. This leaves
open perhaps combining the progress bar and message area in some future
(or forked custom) graphical LCD display arrangement (at which time the
relevant variables may be moved into ultralcd.cpp with externs in
ultralcd.h). I also added a conditional error that the progress bar and
the filament display may not work well together.
This is the optimal code for a self-contained formatter, although the
original code is crafty in being smaller and simpler, and can be
evaluated as using the original output as a scratch pad for state,
making the final formatter more straightforward. While this code is
longer, all code-paths are minimal.
This is the optimal code for a self-contained formatter, although the
original code is crafty in being smaller and simpler, and can be
evaluated as using the original output as a scratch pad for state,
making the final formatter more straightforward. While this code is
longer, all code-paths are minimal.
Moved PSTR() macro to correct place which was causing the " initializer fails to determine size of '__c' " when attempting to compile with BABYSTEPPING enabled.
Changes to support displaying the real-time filament width and the
volume factor on a 20x4 LCD. The data is displayed on the 4th line.
First the status message is displayed for 5 seconds, and then the
filament data is displayed. The status message can be seen by
re-selecting the info screen in the menu.
FW retraction is extended onto swap retraction invoked by 'G10 S1'.
Bookkeeping of the retract state of all extruders allows for having one
extruder fw standard retracted while another extruder is swap retracted.
An LCD menu item for the swap retract and recover length was added.
This is _not_ automatically the cronological, since deleting a file will free
the filesystem descriptor for it, which then will be used by the next file copied on it.
Since this makes the auto0.g file very inaccessible, I put the option back, to have it in the prepare menu.
this should satisfy https://github.com/ErikZalm/Marlin/pull/373
as a reminder, auto0.g will be executed every time after a boot with sd card present and file present.
thereafter, if there is a file auto1.g this will be done. Thats IMHO the best place to put settings, and prepare heating.
I also execute again after each (now again via the prepare menu) before starting a new print/ after a failed one.
It for me 100% replaces any start.gcode form the slicers.
also, removed some trouble for compilation with corexy.
I think that babystepping is only possible in z for a delta tower.
not sure if it would be usefull to step individual motors on a delta, i don't own one
It is a realtime control over the head position via the LCD menu system that works _while_ printing.
Using it, one can e.g. tune the z-position in realtime, while printing the first layer.
Also, lost steps can be manually added/removed, but thats not the prime feature.
Stuff is placed into the Tune->Babystep *
It is not possible to have realtime control via gcode sending due to the buffering, so I did not include a gcode yet. However, it could be added, but it movements will not be realtime then.
Historically, a very similar thing was implemented for the "Kaamermaker" project, while Joris was babysitting his offspring, hence the name.
say goodby to fuddling around with the z-axis.
