# This is the 1st commit message:
MCP4728 consistency & fix ultralcd.cpp
The MCP4728 DAC controls the stepper motor current strenth on the
PRINTRBOARD Rev F and RIGIDBOARD V2 boards.
PR #5792 on 9 FEB 2017 implemented default drive percentages but only on
the RIGIDBOARD V2.
This change moves the default settings to Configuration_adv.h.
Also, ultralcd.cpp won't compile because of a type def conflict.
Changed it to match the one in stepper_dac.cpp
===========================================================
reword stepper curent section for clarity
===========================================================
change name & improve comments
===========================================================
changed name from A4JP to SCOOVO_X9H per PR #6139
# This is the commit message #2:
fix typo
The offset for Z_DUAL_ENDSTOP (z_endstop_adj) is already in Marlin.
This PR just makes it a configuration item.
z_endstop_adj is initialized in two places so both had to be modified.
Made the double touch portion a conditional compile based on the
PROBE_DOUBLE_TOUCH flag.
==============================================
Bugfix
The current G38 only stopped a move if it involved the Z axis.
Moved all the G38 code to it's own section and put it where it would
always be executed no matter what axis was moving or if the endstop was
enabled.
Also added a comment to configuration_adv to alert the user the double
tap had to be turned on.
==============================================
Change G38 back to using Z_MIN_PROBE
There's no Z_MIN endstop if Z_DUAL_ENDSTOPS is enabled and you have them
set to the top of the gantry.
G38 started out as using the Z_MIN_PROBE pin. I don't remember why we
changed it to the Z_MIN endstop.
The target here is to update the screens of graphical and char base
displays as fast as possible, without draining the planner buffer too much.
For that measure the time it takes to draw and transfer one
(partial) screen to the display. Build a max. value from that.
Because ther can be large differences, depending on how much the display
updates are interrupted, the max value is decreased by one ms/s. This way
it can shrink again.
On the other side we keep track on how much time it takes to empty the
planner buffer.
Now we draw the next (partial) display update only then, when we do not
drain the planner buffer to much. We draw only when the time in the
buffer is two times larger than a update takes, or the buffer is empty anyway.
When we have begun to draw a screen we do not wait until the next 100ms
time slot comes. We draw the next partial screen as fast as possible, but
give the system a chance to refill the buffers a bit.
When we see, during drawing a screen, the screen contend has changed,
we stop the current draw and begin to draw the new content from the top.
lcd_update can take so much time that the block buffer gets drained if
there are only short segments. This leads to jerky printer movements for
example in circles and a bad print quality.
This change implements a simple check: Only if the block currently
executed is long enough, run lcd_update.
This also means the printer will not show actual values on the LCD nor
will it respond to buttons pressed. A option that keeps the menu
accessible is also available.
Aditionaly, slow down if a block would be so fast that adding a new
block to the buffer would take more time. In this case, the buffer would
drain until it's empty in worst case.
1) modified 3 code files
Marlin.h
Marlin_main.cpp
endstops.cpp
2) modified config files so I could test on my machine
Testing was done on an AzteegX3pro based machine.
The probe was hooked to the Z_MIN endstop.
My controller doesn't have a dedicated Z_PROBE input so I couldn't test
that functionality.
Verified that a large file (without any G38 commands) executed the same
before and after the changes.
Verified that the head moves as expected when G38.2 and G38.3 commands
are issued. Single & multiple axis moves were tested along with + and -
directions.
Code was added to the main ISR. In normal operation only one extra IF
statement is evaluated. I didn't notice any performance degradation
because of the added code.
The G38 commands are expected to be issued manually by the operator
during machine setup. The G38 commands wait until the machine is idle
before proceeding. That way the other commands are minimally impacted
by the extra ISR overhead when a G38 command is in the queue.
The G38 commands are very similar to the G28 commands except 1) only the
Z_PROBE is used and movement can be in the + or - direction.
See issue 4677 for a discussion on adding G38 commands to Marlin.
Feature request: add ability to use G38.2 command (CNC)
MarlinFirmware/Marlin#4677
About Configuration.h:
・Fix the PR #4899 (ABL: Enable by type. Bilinear for all.)
Remove Duplicated contents
・Fix the PR #4305 (Custom boot screen feature improvement)
Revert from "during boot" to "during bootup" in all the example
Configuration.h
・Fix the PR #4207 (Clean up, simplify and generalize the Allen-key-probe
code.)
Resolve and relocate the duplicated definitions in Z_PROBE_ALLEN_KEY
section
・Follow-up the PR #4805 (Additional documentation of Configuration.h)
Add forgotten changes to all the example Configuration.h
Adjust spacing
About Configuration_adv.h:
Add missing description of SLOWDOWN for DELTA
Adjust spacing
Similar to the current Arduino HardwareSerial
but with max. 256 byte buffer-size.
Deactivated by default.
The boards with AT90USB processor (USBCON) already use a TX-buffer.
Add an emergency-command parser to MarlinSerial's RX interrupt.
The parser tries to find and execute M108,M112,M410 before the commands disappear in the RX-buffer.
To avoid false positives for M117, comments and commands followed by filenames (M23, M28, M30, M32, M33) are filtered.
This enables Marlin to receive and react on the Emergency command at all times - regardless of whether the buffers are full or not. It remains to convince hosts to send the commands. To inform the hosts about the new feature a new entry in the M115-report was made. "`EMERGENCY_CODES:M112,M108,M410;`".
The parser is fast. It only ever needs two switch decisions and one assignment of the new state for every character.
One problem remains. If the host has sent an incomplete line before sending an emergency command the emergency command could be omitted when the parser is in `state_IGNORE`.
In that case the host should send "\ncommand\n"
Also introduces M108 to break the waiting for the heaters in M109, M190 and M303.
Rename `cancel_heatup` to `wait_for_heatup` to better see the purpose.
Includes:
*firmware version / branch / date.
*extruder count
*board information (name, serial details, power supply type)
*thermistors (names, min/max temperatures)
*printer statistics (PRINTCOUNTER details)
Thanks to @thinkyhead for contributions.
No compromises for the manage_heater(). manage_heater() will return immediately when there is nothing to do, but needs a constant detaT to work proper.
Calling idle() only every 200ms results in a display update every ~2 seconds - that should be enough.
For the other functionalities in idle() and manage_inactivity() 200ms is a lot but hopefully works.
When setting the bed temp via M140/M190 if the thermistor does not read an increase of WATCH_BED_TEMP_INCREASE degrees by WATCH_BED_TEMP_PERIOD seconds then it will throw "Error:Heating failed, system stopped! Heater_ID: bed" and call the kill() function.
Conflicts:
Marlin/Configuration_adv.h
Make stepper shutdown after inactivity dependent on a new set of
#defines.
DISABLE_INACTIV_X
DISABLE_INACTIV_Y
DISABLE_INACTIV_Z
DISABLE_INACTIV_E
And make exemplaric Configuration.
Names can be discussed.
This makes the disabling of the steppers independent from the DISABLE_?
settings witch shut down the steppers immediately.
- `SD_DETECT_PIN` replaces `SDCARDDETECT`
- `SD_DETECT_INVERTED` replaces `SDCARDDETECTINVERTED`
- Revise the description of `SD_DETECT_INVERTED`
- Add a note about the override of `SD_DETECT_INVERTED` in
`Conditionals.h`
As suggested in #2521
- Move `ABORT_ON_ENDSTOP_HIT_FEATURE_ENABLED` because `SDSUPPORT` is
also required.
- Add a note that endstops must be enabled for the feature to have any
effect
- Make thermal protection for all hotends and/or bed into simple
switches
- Now enable `WATCH_TEMP_PERIOD` when `THERMAL_PROTECTION_HOTENDS` is
enabled
- Move detailed thermal parameters to `Configuration_adv.h`
- Add sanity checks to warn about old configurations
- Change `WATCH_TEMP_PERIOD` to seconds instead of milliseconds
- Add “Level Bed” menu item for auto bed leveling
- Hide the option if homing has not been done yet
- Arrange the Prepare submenu more logically (?)
- Add documentation comments, some white-space
- Apply some coding standards here and there
- Move old encoder multiplier debug option to `ultralcd.cpp`
This addresses comments in #1956 and #1079. In particular, this is useful
when both endstops are stationary on a CoreXY system, and the Y axis needs
to be homed before the X so the flags are aligned.
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
Z_DUAL_ENDSTOPS is a feature to enable the use of 2 endstops for both Z
steppers - Let's call them Z stepper and Z2 stepper.
That way the machine is capable to align the bed during home, since both
Z steppers are homed.
There is also an implementation of M666 (software endstops adjustment)
to this feature.
After Z homing, this adjustment is applied to just one of the steppers
in order to align the bed.
One just need to home the Z axis and measure the distance difference
between both Z axis and apply the math: Z adjust = Z - Z2.
If the Z stepper axis is closer to the bed, the measure Z > Z2 (yes, it
is.. think about it) and the Z adjust would be positive.
Play a little bit with small adjustments (0.5mm) and check the
behaviour.
The M119 (endstops report) will start reporting the Z2 Endstop as well.
- 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
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.
- Fixed issue when BAL area probing is shorter than it should be for
grid probing
- Warning when BAL activated with Delta Kinematics
- Fix XY_TRAVEL_SPEED when homing Z axis
Tosh stepper drivers need to be driven slower, so the stepper code
was interleaved to separate the pin HIGH from the pin LOW. This adds
enough instructions to make it work, without needing nops.
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.
Firmware retraction now stores the retract and recover speeds in mm/s
instead of mm/min. This makes it match the units of the maximum
feedrate, and fixes problems with modifying the value via LCD control
panel. From gcode, the values are still taken in mm/min to match the
units of G1 and similar, and they are converted to mm/s before they are
stored.
I also lowered the default retract feedrate to make it less likely to
cause problems for geared extruders when the user hasn’t bothered to
set a reasonable maximum feedrate, though users should be setting both
of these values to suit their hardware.
Scott Lahteine