Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Unresponsive LCD #15169

Closed
Glodigit opened this issue Sep 5, 2019 · 35 comments
Closed

[BUG] Unresponsive LCD #15169

Glodigit opened this issue Sep 5, 2019 · 35 comments

Comments

@Glodigit
Copy link

Glodigit commented Sep 5, 2019

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
Copy link
Member

AnHardt commented Sep 5, 2019

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
Copy link
Author

Glodigit commented Sep 6, 2019

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
Copy link

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

@Prelo96
Copy link

Prelo96 commented Sep 19, 2019

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

@Glodigit
Copy link
Author

Glodigit commented Sep 20, 2019

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
Copy link

ghost commented Sep 20, 2019

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
Copy link

ghost commented Sep 21, 2019

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

ghost commented Sep 21, 2019

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.

@ghost ghost mentioned this issue Sep 21, 2019
@Glodigit
Copy link
Author

Glodigit commented Oct 9, 2019

Any new insights into this issue?

@boelle
Copy link
Contributor

boelle commented Oct 12, 2019

@DkOuvE have you tested with latest 2.0.x ?

@boelle
Copy link
Contributor

boelle commented Oct 24, 2019

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.

@boelle boelle closed this as completed Oct 24, 2019
@Glodigit
Copy link
Author

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
Copy link
Contributor

boelle commented Oct 24, 2019

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

@thinkyhead thinkyhead reopened this Oct 24, 2019
@thinkyhead
Copy link
Member

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

@hearnia2k
Copy link

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
Copy link

istyszy commented Oct 31, 2019

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
Copy link

@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
Copy link
Author

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

@Glodigit Glodigit changed the title [BUG] (Fysetc) LCD freeze on delta first later [BUG] (Fysetc) LCD freeze on delta Oct 31, 2019
@thinkyhead thinkyhead changed the title [BUG] (Fysetc) LCD freeze on delta [BUG] Unresponsive LCD Nov 6, 2019
@thinkyhead
Copy link
Member

Reference to earlier PR #14960 "Repair Display Throttling"

@ZhenyaKa
Copy link

ZhenyaKa commented Nov 7, 2019

Change buffer size does not helped me

@hearnia2k
Copy link

hearnia2k commented Nov 7, 2019 via email

@thinkyhead
Copy link
Member

See if the recent merge of 15837 helps.

@sjasonsmith
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

boelle commented Nov 12, 2019

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

@boelle boelle closed this as completed Nov 12, 2019
@sjasonsmith
Copy link
Contributor

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
Copy link
Member

AnHardt commented Nov 12, 2019

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
Copy link

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
Copy link

Ohmarinus commented Nov 14, 2019

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
Copy link
Contributor

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
Copy link

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
Copy link

github-actions bot commented Jul 4, 2020

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.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests