ESP32 eeprom saves needs planner sync. #24753
Conversation
It’s not needed for real EEPROMs, at least not on STM32 and LPC:
That and pausing all motion during printing isn’t exactly desirable as a default behavior. |
| // ESP32 boards seem to lose steps when saving to EEPROM during print (see issue #20785) | ||
| // TODO: Which other boards are incompatible? | ||
| #if PRINTCOUNTER_SAVE_INTERVAL > 0 | ||
| #define PRINTCOUNTER_SYNC 1 |
There was a problem hiding this comment.
See #24731 for existing methods of applying this.
|
That's what I did.
…On Sun, Sep 11, 2022, 3:42 PM Keith Bennett ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In Marlin/src/HAL/ESP32/inc/Conditionals_post.h
<#24753 (comment)>
:
> @@ -20,3 +20,9 @@
*
*/
#pragma once
+
+// ESP32 boards seem to lose steps when saving to EEPROM during print (see issue #20785)
+// TODO: Which other boards are incompatible?
+#if PRINTCOUNTER_SAVE_INTERVAL > 0
+ #define PRINTCOUNTER_SYNC 1
See #24731 <#24731> for
existing methods of applying this.
—
Reply to this email directly, view it on GitHub
<#24753 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNCTC73YPS4MIZHPG2335DV5XOTNANCNFSM6AAAAAAQJXPA3Y>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Nope, you enabled it gloabally for ESP32, which is not the best solution. Better make it on |
|
I don't understand. Someone please fix this, losing a kilo of filament to a 2mm layer shift fk sucks. |
|
|
|
Well, none of the hardware i know about have any of these so your variant will do fine in any forseeable future, but futureproofing is always nice :) |
Description
This is related to #17946. On my platform ESP32 there is a delay of around 1-second whenever an EEPROM save occurs, which happens during the print counter save step. This causes layer shifts.
Is there any reason not to enable PRINTCOUNTER_SYNC globally for all platforms?
Requirements
Benefits
Configurations
Related Issues