Refresh previous_cmd_ms during run_z_probe() to prevent:
stepper shutdown for expired DEFAULT_STEPPER_DEACTIVE_TIME
and extrudes for expired EXTRUDER_RUNOUT_SECONDS
(https://github.com/MarlinFirmware/MarlinDev/issues/238)
Replaced displaying "---" instead of the value of a coordinate when
unhomed or with reduced precision
with blinking the coordinate-prefix-character ('X','Y','Z').
For "unhomed" a '?' is shown every second second - until that axis is
homed. The value displayed is, as before the "---" where displayed, the
relative to the reset position coordinate value.
When the axis stepper was disabled, now we can display a hint on that,
by showing a blinking ' ' instead of the axis letter, when
WARN_REDUCED_ACCURACY is defined.
I suppose the code itself is here the better documentation.
A '+/-' character is in non of our charsets so i decided for a '?' for
now to reduce the work.
There is no additional space on the displays one could use to display
the information, so replacing something is the only option. As the axis
letters are totally redundant with their positions on the display they
contain the least information.
So my decision was to overwrite them.
In the wait loops of M109 M190 idle() is called, what checks
stepper_inactive_time against previous_cmd_ms.
Because we can be several minutes inside the loop, resetting
previous_cmd_ms only outside the loop caused stepper shutdowns.
The name of previous_cmd_ms does not really reflect its use. It's set
not only when a new command was received or executed but also in many of
the movement routines. For that the little extension of using it during
the wait will (hopefully) not hurt.
# 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.
Introduce additional variable axis_homed to replace axix_known_position
when the coordinate display should indicate the axis is not homed.
This is to distinguish between "not homed" and "inexact position possible
because stepper was disabled".
# Conflicts:
# Marlin/ultralcd_implementation_hitachi_HD44780.h
solved
Fix crashes when the Z axis is moved via LCD
by calling `plan_buffer_line` only when there is enough room in the
planner buffer, to avoid endless recursion.
A brief description about what went wrong is in #1166
Protect MarlinSerial against interrupts
by shielding the CRITICAL_SECTIONs
Now with a test if RX_BUFFER_SIZE is in the required range.
Code in peek() and read() is now optimized for readability and showing the similarity between the two.
Maybe a bit overprotected in checkRx() and store_char(), but now some days without detected errors from this source.
@thinkyhead
Hi Scott,
your code from a0f362c@thinkyhead is great, but you forgot to skip the
command.
Symptom `M117 Test`shows `M117 Test` on LCD instead of `Test`.
see also
https://github.com/MarlinFirmware/Marlin/commit/a0f362c735401ebbcd95de3f
6f8e3c2f17ecc770 lines 941, 2851 and so on
Greetings and welcome back
Jochen
* Configuration.h:
* updated header comment
* new UUID feature used
* sync to default config
* typos fixed
* changes better documented
* reflect change in SDSUPPORT feature
* Configuration_adv.h
* updated header comment
* thermal protection tuned to work with K8200
* homing tuned
* sync to default config
* typos fixed
* changes better documented
* reflect change in LCD features
* use long filenames
* use Watchdog
* use Babystepping
* use Auto Filament Change
Replace the "ok" in M280, M301, M304, M851 with output not including an "ok"
to avoid senting two "ok"s for a single g-code.
Doing the same for M105 would break the input filters of the hosts.
For M105 the other "ok" is omitted.
//100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed)
Caveat Emptor —-
I’m not sure that this really makes sense,
but why keep someone from using it?
For some reason that I cannot determine, using a sub-function causes
the Tune sub-menu to act strangely, yet replacing the function call
with its code content works perfectly.