[BUG] RepRapDiscount Smart Controller almost unresponsive during printing

[PKav89]

Description

HD44780 LCD (REPRAP_DISCOUNT_SMART_CONTROLLER) is very laggy during printing, but works well when not printing.

My setup is:
Delta printer (Kossel Mini type)
SKR v1.3
TMC2209
REPRAP_DISCOUNT_SMART_CONTROLLER

Steps to Reproduce

0. Configure, build and install latest Marlin 2.0
1. Start printing via SD Card or USB from PC
2. Try to enter menu by pressing encoder knob

Expected behavior: LCD menu appears, walking through menu is fast and responsive.

Actual behavior: LCD becomes blank for about 15 seconds, then menu appears, but it reacts very slowly to encoder rotation. Then it returns to the status screen after timeout.

Additional Information

I also tried following:
Switch TMC2209 to standalone mode
Set MINIMUM_STEPPER_PULSE to 0, 1 or 2
Enablle/disable LCD_PROGRESS_BAR

Here is my configuration files and video of the issue.

https://www.youtube.com/watch?v=-G-UiMgzyB4

Configuration.zip

[gloomyandy]

See last few posts in this thread: #12461

[AnHardt]

Your processor load is too high.
If you prefer stuttering over display lag revert #14960.

[PKav89]

But this setup worked well before on Marlin 2.0 about 2 month ago. No stutterintg and responsive display. Unfortunately, that version did not support TMC2209, so I decided to delete it and build latest snapshot from scratch using same configuration.

Also this printer worked well on 8-bit board with same settings And I print at 45mm/s with DELTA_SEGMENTS_PER_SECOND 80, it does not seem to be CPU load issue, it's LPC1768 100 MHz 32-bit CPU.

[AnHardt]

If so, comment https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/module/planner.cpp#L2040 and be lucky.

[PKav89]

This line works only if HAS_SPI_LCD defined, but my LCD is not SPI, it's 4-bit parallel, afaik.

[AnHardt]

I know. :-(
Marlin and naming - i gave up on that - there never was a understandable logic in, now i have hope it will have one day.
I have to follow the complete chain backwards - nearly always. (When I learned the actual definitions they have changed them again.)
HAS_SPI_LCD is defined as.

#define HAS_SPI_LCD          ENABLED(ULTRA_LCD)

So pretty much all displays have HAS_SPI_LCD, regardless of working over SPI, I2C or 4-bit parallel or 4-bit parallel over I2C or ... . Only a few exceptions. Have a look into ...\Marlin\src\inc\Conditionals_LCD.h.

[PKav89]

Well, OK, but anyway, should this behaviour be by default? I have 100 steps/mm XYZ steppers and 410 steps/mm extruders, DELTA_SEGMENTS_PER_SECOND 80. Pretty standard setup, no fancy stuff like I2C sensors or Neopixels, but common standard cheap LCD is unusable during printing. It's not CPU load issue, because even 8-bit board could handle same setup just fine.

[AnHardt]

should this behavior be by default?

Yes! The problem is not, throttling the display if the planer-buffer is not full enough. That's less ugly than updating the display and get lots of stutters for that. The problem is, the not enough filled buffer. The reasons for that are out of my scope. Maybe the SKR 1.3 has a problem, or all SKRs, or all LPC1768 - i don't know. All i know is - i gave my best to make it not worse by display updates.

Could also be a exceptional slow display library on that platform.

[PKav89]

I commented the line 2040 in planner.cpp and now LCD responsive again!
I guess, there should be a define in Configuration_adv.h to turn display throttling on or off, at least for now. SKR 1.3 and LPC1768 is very popular board and MCU now, many users will run into same issue soon.

[AnHardt]

Fight the reasons, not the symptoms.

[PKav89]

True. But no reason exists when this line is commented. No stepper stuttering happens, printed models have great surface finish with no blobs at all. It seems, that there is nothing to fight.

Also, such features should be tested at least on common machine setups before implementing it as default with no way to disable them.

[AnHardt]

It is tested for years, but someone broke it. I just repaired it recently.

[PKav89]

So, what could be possible solution here except migration to FreeRTOS? :-)
Increase BLOCK_BUFFER_SIZE?

[mignolo4]

So, what could be possible solution here except migration to FreeRTOS? :-)
Increase BLOCK_BUFFER_SIZE?

You're a genius!!! 🥇

I mean, really, that works!

With these parameters now it's super smooth:
#if ENABLED(SDSUPPORT)
#define BLOCK_BUFFER_SIZE 64 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
#define BLOCK_BUFFER_SIZE 64 // maximize block buffer
#endif

with the default
#define DELTA_SEGMENTS_PER_SECOND 160

--- let me do some more tests ---
TESTING DONE: IT DEFINITELY WORKS! (at least for me; your feedback would be appreciated)

tried with a value of 32 and it's not good
tried with a value of 64 and it's perfect: with either 25% speed or 300% speed set from repetier host

[PKav89]

Did you have same issue with unresponsive display?

DELTA_SEGMENTS_PER_SECOND 160 is too much. 80 is OK. See: https://reprap.org/forum/read.php?178,807859,808097#msg-808097

[mignolo4]

Thank you for the link ;-)

This particular behavior came out after the recent mod made by AnHardt, as he stated.
The priority has been given to a smooth movement, then, when the cpu has time, it updates the lcd, and it does make sense.

But I've been struggling to find a solution to the stuttering (and so awful printing quality) I always had with this hw combination (now it's only a test bed).
It is really strange that you've never experienced the stuttering... or maybe because of your lower delta_segment_per_second value.

Does it work for you with the increased buffer values now?

[McVillano]

Sorry to comment in a closed issue but i have the same problem.
I have DELTA_SEGMENTS_PER_SECOND 80, and i suffer the irresponsive LCD i see two possible solution here:

1. #if ENABLED(SDSUPPORT)
   #define BLOCK_BUFFER_SIZE 64 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
   #else
   #define BLOCK_BUFFER_SIZE 64 // maximize block buffer
   #endif

2. I commented the line 2040 in planner.cpp and now LCD responsive again!

Witch would be the best path to workarround whis?

[PKav89]

Issue is not closed yet. I checked it and it works without commenting line 2040 in planner.cpp, just increase BLOCK BUFFER_SIZE to 64. But I tested it only on LPC1768. Maybe it should be tested on other MCUs like AVR and STM32.

[mignolo4]

Tested the increased BLOCK BUFFER_SIZE to 64:
it works on Arduino2 too :-)

[boelle]

will close as it seems to be fixed

[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.