Marlin: [BUG] Screen throttling can't handle fast displays
Bug Description
Display with update time less than 1 ms suffers from screen throttling.
uint16_t max_display_update_time is 0 due to really fast display update time.
max_display_update_time-- set max_display_update_time to 65535, meaning next screen update will be in 18 hours.
My Configurations
MKS Robin with reworked LCD subsystem
Steps to Reproduce
None.
Expected behavior: [What you expect to happen]
UI is displayed when printing from SD card
Actual behavior: [What actually happens]
Blank screen when printing from SD card
Additional Information
Possible solutions:
- Replace
max_display_update_time--;withif (max_display_update_time) max_display_update_time--;in ultralcd.cpp (tested) - Change max_display_update_time type to int16_t (not tested)
- Add 1 ms delay to MarlinUI::draw_status_screen() (tested)
jmz52
All 8 comments
Where do you see max_display_update_time--? I can't see it in bugfix 2.0.x sources
GMagician
on 19 May 2020
jmz52
on 19 May 2020
Download bugfix 2.0...it has been changed and there is no more such line
GMagician
on 19 May 2020
Sorry, wrong branch.
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/ultralcd.cpp#L884
jmz52
on 20 May 2020
I found it....I not analyzed how lcd works but it seems you did it and since you found that I think you may post a PR. If in trouble posting it I may do it for you
GMagician
on 20 May 2020
When i wrote the code i never assumed a screen update could be as short as below a ms.
if (max_display_update_time) max_display_update_time--; seems to be the right solution.
If a screen update does not last longer, the probability the planner-buffer runs dry in that time is extremely low. Wasting a ms by an artificial delay would be wrong.
The line exists to make the algorithm adaptive. A very long one time screen-update (for example interrupted by something) should not have influence forever.
AnHardt
on 20 May 2020
@GMagician, thanks for the PR
jmz52
on 22 May 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[bot] picture](https://avatars2.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
on 22 Jul 2020
Related issues
otisczech
路
3Comments
heming3501
路
4Comments
StefanBruens
路
4Comments
Tamonir
路
3Comments
Bobsta6
路
3Comments
Most helpful comment
When i wrote the code i never assumed a screen update could be as short as below a ms.
if (max_display_update_time) max_display_update_time--;seems to be the right solution.If a screen update does not last longer, the probability the planner-buffer runs dry in that time is extremely low. Wasting a ms by an artificial delay would be wrong.
The line exists to make the algorithm adaptive. A very long one time screen-update (for example interrupted by something) should not have influence forever.