[BUG] Unresponsive LCD

[Glodigit]

Description

I am using a BIQU SKR, as well as the latest Marlin 2.0 and config for the Anycubic Linear Plus. The Fysetc RGB LCD screen I have connected works properly unless printing the first layer of a print (through both SD and USB). After a print / second layer, the screen becomes responsive again. While the screen is frozen, pressing the button does make audible feedback.

Steps to Reproduce

1. Flash an SKR with the Anycubic Linear Plus example config
2. Start a print.

Expected behavior:
LCD values to change, opening the setting menu when the rotary encoder is pressed.

Actual behavior: [What actually happens]
LCD freezes until the first later is finished.

Additional Information

Cura start GCODE incase that's the issue

M140 S{material_bed_temperature_layer_0} ; start preheating the bed WITHOUT wait
M104 S{material_print_temperature} T0 ; start preheating hotend WITHOUT wait

M190 S{material_bed_temperature_layer_0} ; start heating the bed and WAIT
M109 S{material_print_temperature} T0 ; start heating hotend and WAIT
M117 Warming Up...

G1 Z150.0 F6000 ;Move the platform down 15mm
G1 Y-110 X-15;Move head out of the way
G1 Z1 F6000
G92 E0
G1 F400 E60 X15 ;Make a line of extrusion
G1 E55 F9000 ;retract 1cxm
G92 E0
G0 Z50 F6000 ;lift up to prevent shroud damage

M117 Printing Item...```

[AnHardt]

This looks like display throttling by purpose. Recently repaired.
The planner buffer does not contain enough moves (or to short ones) to bridge the time the display update needs and have some rest. It the display update would be done this would likely produce stutters or will print much slower than commanded.
Increase the planer buffer, print with less segments/second, print a less fine model resolution. All that will probably help.

[Glodigit]

I'm assuming with a delta, even straight lines are broken up into segments.

I changed #define BUFSIZE to 32, BLOCK_BUFFER_SIZE to 64 and TX_BUFFER_SIZE to 128. This seems to work until you press the button on the rotary encoder. Then the whole display is blank for approx 3/4 of a second and then frozen on the main menu.

Should the buffers be increased further?

[jimbosims]

I'm having the same issue. MKS Gen L. RepRap Discount Smart Controller. Stock buffer sizes, 150 segments

[Prelo96]

Same issue on skr 1.3 with tmc spi 64 microstep 200segment at ultra low speed too
Duplicate of #15293 ?

[Glodigit]

I should also mention that even when compile is successful, I get the following:

Marlin\src\lcd\dogm\ultralcd_DOGM.cpp:78:24: warning: unsigned conversion from 'int' to 'uint8_t' {aka 'unsigned char'} changes value from '306' to '50' [-Woverflow]
 U8G_CLASS u8g(U8G_PARAM);

.pio\libdeps\LPC1768\U8glib-HAL_ID1932\src\clib\u8g_rot.c:48:27: warning: initialization of 'uint8_t (*)(u8g_t *, u8g_dev_t *, uint8_t,  void *)' {aka 'unsigned char (*)(struct _u8g_t *, struct _u8g_dev_t *, unsigned char,  void *)'} from incompatible pointer type 'uint8_t (*)(void *, void *, uint8_t,  void *)' {aka 'unsigned char (*)(void *, void *, unsigned 
char,  void *)'} [-Wincompatible-pointer-types]
 u8g_dev_t u8g_dev_rot = { u8g_dev_rot_dummy_fn, NULL, NULL };
                           ^~~~~~~~~~~~~~~~~~~~
.pio\libdeps\LPC1768\U8glib-HAL_ID1932\src\clib\u8g_rot.c:48:27: note: (near initialization for 'u8g_dev_rot.dev_fn')

[ghost]

same issue on both of my printers, one Delta with SKR v1.3 + TMC2208 the other one is CoreXY MKS sbase v1.3 with fast decay mod. I used to have external TMC2208 on MKS sbase and firmware was from 2018, and it worked fine.

[ghost]

I'm assuming with a delta, even straight lines are broken up into segments.

I changed #define BUFSIZE to 32, BLOCK_BUFFER_SIZE to 64 and TX_BUFFER_SIZE to 128. This seems to work until you press the button on the rotary encoder. Then the whole display is blank for approx 3/4 of a second and then frozen on the main menu.

Should the buffers be increased further?

I have to increase the "BLOCK_BUFFER_SIZE" to 128 to get it to work, I only changed this value.
at 64, the display only works when the bottom solid layers finished print (mine is 3 layers), at 128 it works anytime I push the encoder.

[jimbosims]

What are risks of increasing BLOCK_BUFFER_SIZE? Default is 16, comments here say 128 effectively resolves this issue. That's a pretty drastic increase, does it conceivably affect other operations?

[ManuelMcLure]

The biggest issue I’ve seen with increasing it is that the Octoprint gcode viewer may “run ahead” of what’s currently printing, and if you cancel a print from the host it will print what’s left in the buffer before stopping.

[jimbosims]

I increased my Block Buffer to 128 and the LCD screen wouldn't respond at all. even after reboot. I dialed it back to 64, still no joy. Setting it to 32 seems to work though. I was able to access my menus during the first layer. Oh, and Delta_Segments is set to 150.

[ghost]

I increased my Block Buffer to 128 and the LCD screen wouldn't respond at all. even after reboot. I dialed it back to 64, still no joy. Setting it to 32 seems to work though. I was able to access my menus during the first layer. Oh, and Delta_Segments is set to 150.

I am not sure if different marlin versions play a role in this problem, have you tried some older commits? I left delta_segments at 200 and still works fine.

My problem is really related to this #15293
I am using a LCD2004 from Micromake.

[Glodigit]

Any new insights into this issue?

[boelle]

@DkOuvE have you tested with latest 2.0.x ?

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[Glodigit]

I keep pulling the latest Marlin every couple of days with no changes in the issue. It's also happening on my Cartesian when going at fast print speeds.

[boelle]

so maybe the printer is so busy that it cant update the LCD?

[thinkyhead]

Someone with the necessary savvy (and two thumbs) will have to do proper troubleshooting to track down the cause of this issue.

[hearnia2k]

I have the issue here too, Anycubic Predator, with SKR 1.3, FYSETC MINI12864 v2.1 RGB LCD.
Increasing BLOCK_BUFFER_SIZE to 32 or 64 does not seem to resolve the issue for me.

[istyszy]

I think changing the buffer size is just a workaround but not a fix, this board still needs:
-software I2C
-support for more UART interfaces like USB + WIFI simultaniusly
-and the I2C display problems that it has...
@thinkyhead Wish i could help but i do not have the necessary knowledge and time:(

[hearnia2k]

@istyszy this is an issue only affecting more recent builds of Marlin, plus more than one board type, so I don't think it's a board issue, or it would have always been present.
I'm not sure what I2C problems you reference, but in terms of the UART I think many people, like me, don't need USB or WiFi.

[Glodigit]

I have the time to fix it but just not the knowledge.

[thinkyhead]

Reference to earlier PR #14960 "Repair Display Throttling"

[ZhenyaKa]

Change buffer size does not helped me

[hearnia2k]

Same for me. Tried 32 and 64. Setting 128 has a compile time warning about interest to uint conversion. Sent from my Samsung Galaxy smartphone.

…

-------- Original message -------- From: ZhenyaKa <notifications@github.com> Date: 07/11/2019 08:40 (GMT+00:00) To: MarlinFirmware/Marlin <Marlin@noreply.github.com> Cc: hearnia2k <hearnia_2k@hotmail.com>, Comment <comment@noreply.github.com> Subject: Re: [MarlinFirmware/Marlin] [BUG] Unresponsive LCD (#15169) Change buffer size does not helped me — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#15169?email_source=notifications&email_token=AEDB26ACYIDVJKITZIUYAITQSPIAPA5CNFSM4IT4UKGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDLUPKQ#issuecomment-550979498>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEDB26DBFJPTASIRAQYO273QSPIAPANCNFSM4IT4UKGA>.

[thinkyhead]

See if the recent merge of 15837 helps.

[sjasonsmith]

I just tried this out on my Anycubic Kossel Linear Plus, with the original Trigorilla mega2560 board.
I have not modified my buffer sizes. BUFSIZE=4 and TX_BUFFER_SIZE=0.

The display was very responsive. I was able to effectively babystep to adjust my print height as the print started, and had no issue navigating menus or adjusting feedrates.

I hadn't updated this firmware since perhaps August or September, and it definitely had responsiveness issues then. In both cases I was printing over USB from Octoprint. It's good to see the usability improved!

[Glodigit]

Just tried it. The difference is night and day. I can also report no issues using the screen on my Kossel now. Screen is as smooth as butter.

[boelle]

I have not modified my buffer sizes. BUFSIZE=4 and TX_BUFFER_SIZE=0.

seems to fix the issue, so more a config issue and not an issue with the firmware as such

[sjasonsmith]

I have not modified my buffer sizes. BUFSIZE=4 and TX_BUFFER_SIZE=0.

seems to fix the issue, so more a config issue and not an issue with the firmware as such

No, it was definitely a firmware issue, it is just fixed! I was pointing out that it works great even with the default values for buffers.

[AnHardt]

I have not modified my buffer sizes. BUFSIZE=4 and TX_BUFFER_SIZE=0

These are irrelevant for this issue anyway. Increasing BLOCK_BUFFER_SIZE still can improve that.

[hearnia2k]

Just for another confirmation: Upgraded my firmware today, and now LCD works fine now.
SKR 1.3, on Anycubic Predator (Delta), with TMC2208, and FYSETC Mini 12864 version 2.1 RGB.
Thanks!

[Ohmarinus]

I have the same issue with a homebrew Delta with the bugfix version from a week ago. I have used the generic Delta example configs to tune my machine. LCD cannot be used during print, also not during UBL or other leveling services. I am in the process of calibrating the new machine, a print has failed but I cannot 'stop' the print because of this haha.

SKR v1.3 - Delta - TMC2208

[sjasonsmith]

I have the same issue with a homebrew Delta with the bugfix version from a week ago.

Try again with the latest commits from bugfix-2.0.x. This was only fixed a few days ago.

[Ohmarinus]

I have the same issue with a homebrew Delta with the bugfix version from a week ago.

Try again with the latest commits from bugfix-2.0.x. This was only fixed a few days ago.

Wow, served with retroactivity. Thanks!

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