[BUG] Config for SKR Mini E3 V2.0 causes bulge in print

[Lord-Quake]

This issue concerns
#define CONFIG_EXAMPLES_DIR "Creality/Ender-3/BigTreeTech SKR Mini E3 2.0"
file Configuration_adv.h

At a certain point in time within commits I noticed a bulge in the print just before the end. The extruder would stop for a split second and then finish the print seen here:

Addíng M400 at the last "G" command did not solve the problem.

I've finally found the cause. It concerns one of the following lines:

// @section motion

// The number of lineear moves that can be in the planner at once.
// The value of BLOCK_BUFFER_SIZE must be a power of 2 (e.g. 8, 16, 32)
#if BOTH(SDSUPPORT, DIRECT_STEPPING)
  #define BLOCK_BUFFER_SIZE  8
#elif ENABLED(SDSUPPORT)
  #define BLOCK_BUFFER_SIZE 32
#else
  #define BLOCK_BUFFER_SIZE 32
#endif

// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 32

// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 32

// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
//#define RX_BUFFER_SIZE 1024

The above values differ from default values which are:

// @section motion

// The number of lineear moves that can be in the planner at once.
// The value of BLOCK_BUFFER_SIZE must be a power of 2 (e.g. 8, 16, 32)
#if BOTH(SDSUPPORT, DIRECT_STEPPING)
  #define BLOCK_BUFFER_SIZE  8
#elif ENABLED(SDSUPPORT)
  #define BLOCK_BUFFER_SIZE 16
#else
  #define BLOCK_BUFFER_SIZE 16
#endif

// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 4

// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 0

After setting the above default values the issue vanished.

@thisiskeithb For your info as being the author :-)

For completeness here my config files: Files.zip

[thisiskeithb]

Someone else added those settings to the other SKR Mini configs after I contributed them, so I transferred the settings over to the V2 config for consistency.

I’ll have to do some digging to find the commit and reason why it was changed. See PR #16247

Several other users have been using this config without issue, so I’m wondering if you need to tune some settings for your specific setup.

[Lord-Quake]

I only really started noticing the issue when I began printing single 0.4 wall prints for tests purposes. This e.g. was the case when we were working on this #17920 (comment) issue.
The Author states: The used STM32 cpu has plenty of RAM -> use greater buffers without real cause it seems.
I'm now questioning the necessity of the change. Personally I've never had any issues with stock buffer settings, either with the 1.2 or 2.0 board.
For those wanting to test can use the boomerang test file as an example, or any other simple object . Marlin config files are in my initial post.

[Lord-Quake]

I was able to narrow down the culprit causing the short delay just before print end:

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 4 // 32 causes a pause just before print end!

Here is another very simple example (printed in vase mode @ 40mm/s)

[swilkens]

As a reference, I tried to verify this on my V1.2 and I can't seem to replicate this.

Using

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 32

This doesn't happen.

Added configs for reference.
Marlin.zip

[Lord-Quake]

Thanks.

Best we stick with the V2.0 board for best comparison.

[thinkyhead]

Changes have recently been made to improve various timing and motion issues. Please test the latest bugfix-2.0.x branch to see where it stands.

[Lord-Quake]

Downloaded todays bugfix.

Bulge is still present when set to 32 as per default configuration (which used to be 4 in the past).

#define BUFSIZE 4 //32 causes a pause just before print end!

I had asked for feedback on Discord (no reactions) and on FB (some Thumbs-up but no one would test) :-(

[qwewer0]

I might or might not have the same problem, but
When "printing" the JD_single_arc_test_quick.zip file, with BUFSIZE 32, a bit before the end of the file it stutters, but there is no stutter with BUFSIZE 4.

SKR Mini E3 v1.2
Configuration.zip

[Lord-Quake]

= confirmed. Thanks for keeping my insanity :-)

[AnHardt]

Where is the blob? How many moves away from the files end?
Could there be a relation between SLOWDOWN, a sudden decrease of speed, and LINEAR_ADVANCEs, reaction in changing pressure?

[qwewer0]

@AnHardt In my case with the JD_single_arc_test_quick.gcode file, it has no extruder moves, so LA shouldn't make a difference, but that is just an assumption from me.

[Lord-Quake]

Where is the blob? How many moves away from the files end?

See above....

Could there be a relation between SLOWDOWN, a sudden decrease of speed, and LINEAR_ADVANCEs, reaction in changing pressure?

No.

[Lord-Quake]

I just downloaded commit 3eef000 to see if the problem still exists before Marlin going to 2.0.6.

Having the buffer size set to 32 as per default, the value is still causing the short pause before end of the print.

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 32

Unless there is a known reason for having to set the value to 32 it is my recommendation to divert back to 4 as it was in the past until the issue is found.

[thisiskeithb]

See MarlinFirmware/Configurations#168 which reverts buffer sizes in SKR Mini E3 V1.0, V1.2, and V2.0-based configs to Marlin defaults.

[qwewer0]

@thisiskeithb What is the theoretical advantage to have BUFSIZE 32, BLOCK_BUFFER_SIZE 32 and TX_BUFFER_SIZE 32, on Mini E3 boards? And is there any disadvantage to changing it back to the Marlin default?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.