Partially revert previous change: cancelling a single loop would often
advance the gcode stream to the next wait-for loop if executed at the
beginning of an SD print, implicitly turning off the flag again.
Cancel the loop directly in UnconditionalStop() which stops the command
queue as well in an atomic way, handling this correctly.
Remove most of the duplicated code inside temp_runaway_stop(),
making it identical to the other temperature handlers.
Move the lower-level functions required to stop the entirety of the
machine into UnconditionalStop(). Reuse this function inside
lcd_print_stop().
Set the LCD alert message before calling Stop(), as done in other safety
handlers, so that the error is visible while the printer is stopping.
This also avoids other temporary status messages to appear before
the real issue is shown and/or STEALING the first CRITICAL alert
level before we do.
Use the internal lcd_status_message_level for multiple severity levels
of alert messages.
This is needed to distinguish between non-critical alerts (such as FAN
ERROR) from critical ones (any heater issue). During a failure
scenario, a critical error MUST NOT be overridden by a lower-level one.
As such LCD_STATUS_CRITICAL is currently used for all heater-related
errors that result in a safety full-stop.
Make sure to call lcd_timeoutToStatus.start() when the SD card is inserted
into the printer after it was removed beforehand.
(cherry picked from commit 6795843f153aa064f087f80990419a946cdfe857)
Saves 8 bytes of Flash memory
This call is redundant and when moving between menus
it gets called multiple times which results in waste
of clock cycles.
lcd_timeoutToStatus.start() is called from menu_lcd_lcdupdate_func()
which is enough.
The comment behind the ASM MultiU16X8toH16 was misleading.
It actually computes ((a<<8)*b)>>16, or (a*b)>>8.
Correct the comment and C reference implementation accordingly.
In PR #3093 the progmem array FW_VERSION_NR was introduced to store the
version components, however the code didn't read it properly using the
pgm_read_* functions, making version comparisons fail.
Fix the existing/unused is_provided_version_newer() and reuse it in
show_upgrade_dialog_if_version_newer().
Similarly also read/update correctly the version in the eeprom.
- Move D23 into it's own function inside Dcodes
- Correctly include a break in the switch statement
- Show the dumper status (enabled/disabled) after toggling
- Allow to generate an immediate dump via g-code using D23 E for
symmetry with D20 E
When building with GCC 4.9.2 (bundled with PF-build-env-1.0.6.*), -Os
and LTO enabled, PID_autotune gets automatically inlined into
process_commands().
Sadly, due to the massive size of process_commands(), it results in
codegen bug doing a partial stack overwrite in process_commands()
itself, manifesting as random behavior depending on the timing of
interrupts and the codepath taken inside the merged function.
Mark the function as noinline and add a note about the affected compiler
version in order to be checked again in the future.
Instead of using a mixture of int8_t, unsigned char and (incorrectly)
int, use uint8_t consistently for indexing the current block.
This improves the performance of the wait loop in plan_buffer_line,
which currently expands all comparisons to a word for no reason.
This also extends the theoretical limit to 128 entries.
Add some static assertions to ensure BLOCK_BUFFER_SIZE is correct.
This avoids the "busy" output interleaving with regular output in very
rare scenarios.
We should focus in finding which calls are not using manage_inactivity()
properly instead of working it around.
Code running in the temperature ISR needs to be fully reentrant, which
is hard to track down.
Move autoreporting to the main processing loop. This can make the
autoreporting slower or pause at times, but removes the reentrant
restriction, which allows us to use printf_P.
This PROGMEM is currently ignored by gcc, but even if it wasn't it
wouldn't be correct since the following code is expecting to read "item"
without fetching the array itself from PROGMEM.
The longpress function is currently called within the temperature ISR,
which is bogus. Calling the longpress function at the wrong moment
can corrupt the menu buffers.
Move the call to the main loop by changing the logic slightly:
- still sample the lcd buttons inside the temperature ISR, which keeps
scrollong/pressing responsive, but...
- set a flag to indicate that longpress has been triggered instead of
calling the function directly
- call the function on the next manage_inactivity run
Combined with #3180 this removes _most_ unsafe operations out of the ISR
which can happen during a normal run (max/mintemp warnings are still an
exception).
Instead of having to guess the PC where the SP was sampled, always take
both. This allows "seamless" stack decoding for both serial and xflash
dumps, since we don't have to guess which function generated the dump.
Make the core functions (doing the sampling) be ``noinline`` as well,
so that they always have valid frame.
Save SP which is closest to the crash location, which simplifies
debugging. For serial_dump, write SP just before the dump.
For xfdump, save SP in the dump header.
This makes xfdump_dump and xfdump_full_dump_and_reset() equivalent for
stack debugging.
Now that the stack_error function is truly minimal,
we can check for stack errors much more frequently.
Also move away stack_error from ultralcd to Marlin_main.
Rename EEPROM_CRASH_ACKNOWLEDGED to EEPROM_FW_CRASH_FLAG.
Use EEPROM_FW_CRASH_FLAG to always set the last crash reason, which
simplifies handling between the online/offline variants.
Make stack_error safe, by setting the flag and restarting immediately,
so that the error can be shown after restart.
When XFLASH is not available, allow users to request _online_ crash
dumps by using D23 (since these require active user cooperation).
Once enabled, instead of just rebooting, dump memory directly to
the serial.
As similarly done with EMERGENCY_DUMP, we have two features that can be
enabled:
EMERGENCY_SERIAL_DUMP: enables dumping on crash after being requested
MENU_SERIAL_DUMP: allow triggering the same manually through the support
menu.
Create a gap between the BSS and the stack guard.
Set this gap (STACK_GUARD_MARGIN) to 32 bytes in all variants.
The gap serves two purposes:
- Detect a stack overflow earlier (falsely triggering in overtight
situations is OK!), so that we can hopefully avoid smashing
the heap and have a clean view during the dump.
- Reserve spack space itself for the stack dumping machinery,
which is going to grow the stack even further.
Remove get_stack_guard_test_value() which was unused.
As suggested by @3d-gussner, announce to the host that a dump is
available for retrieval using an action "dump_available".
Any kind of dump is announced (even if manually triggered).
To avoid reading from xflash twice, remove some duplication and return
the crash reason directly in xfdump_check_state().
If MENU_DUMP is enabled, a new entry at the end of the "Support" menu is
added that allows to dump memory for offline use.
This allows to trigger a memory dump at any moment during regular usage
(either idling or printing) and to recover the dump later even after a
hardware reset.
If EMERGENCY_DUMP is defined, crash and dump using the new xflash dump
functionality instead of just continuing with an error message.
When an emergency crash is stored, the first restart after a crash
displays a message that debug data is available and to contact support
to submit the crash for analysis.
This requires expanding the dcode_core address type to 32bit type,
thus enlarges the D2/D3 implementation as a result.
Still allow to save all the original space if D6 is disabled, for now.
Allow to read up to 0x21ff, which is the last byte of SRAM. Set default
starting address to 0x200, which is the first true byte.
0x0-200 is mapped to register/io space and could cause issues when read
from bi-directional registers.
Farmers want to abuse a bug from the previous firmware releases
- they need to see the filename on the status screen instead of "Wait for user..."
So we won't update the message in farm mode...
Check for lcd_draw_update to see if the lcd has been altered outside the
function and redraw the screen if full.
This fixes scenarios such as #3129 where the "Card removed" message or
the SD menu is entered from outside the function's control.
This requires checking/resetting bFilamentWaitingFlag carefully to avoid
re-entering this function _twice_ (raise_z_above will run the main
loop until complete).
Scale extruder motor current linearly with speed.
49% less heating when running at low speed and standstill, 4% more torque at maximum extrusion rate (15mm^3/s), 15% more torque in high speed movements (un/retractions).
StealthChop mode is used for low speeds (below 900mm/min)
spreadCycle is used above. Transition speed is well above maximum extrusion rate of 15mm^3/s (275mm/min) so mode transition is not expected to be visible on printed surface.
StealthChop is expected to improve printed surface quality (less artifacts).
Warning you can burn extruder motor if it is not the same impedance as original Prusa i3 Extruder stepper motor. There is no current feedback in low speed so lower impedance motor can be burned by over current.
Even there is no direct current feedback, there is no risk for original motor thermal runaway, as motor resistance increases with temperature, current decreases.
Standstill peak phase current is expected to be 500 mA and linearly increase with speed to 970 mA at 900mm/min where spreadCycle constant current regulation takes over and keeps peak current at 805 mA to maximum speed possible.
As motor heating increases with current squared, lowering low speed current from 700mA to 500mA decreases heating 49% in thate mode, where motor spends most of the time.
Enable E-motor cool mode in farm mode only (and experimental menu) - the experimental menu is visible AND the EEPROM_ECOOL variable has a value of the universal answer to all problems of the universe - i.e. two conditions must be met at the start of the FW to enable the E-cool mode. If the user enables the experimental menu, sets the E-cool mode and disables the menu afterwards, on the next start of the FW the E-cool mode will be DISABLED. This is still subject to discussion how much obscure (security through obscurity) we'd like this option to have .
Additional stuff:
* Add serial debug msg to verify if E-cool mode is on
* Avoid access to E-cool mode switch on machines without TMC2130
* Do not allow only M907 E in case of E-cool mode+warn the user on the serial line that the command was skipped
Co-authored-by: D.R.racer <drracer@drracer.eu>
