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
Do we still need ENSURE_SMOOTH_MOVES? #5466
Comments
@esenapaj you wrote about a problem with |
The reason for the performance boost is that we now yield back to the command parser after each screen segment, and that's a good strategy when the planner is in danger of starving. I think it still makes sense to keep the sum of all segment times and to be able to use that to inquire whether the machine is in danger of falling behind — for example, if the planner were to be blocked by a screen-segment update. The one change I would make is to use that information to decide whether to draw the next graphical segment now, or to release control back to main loop and command parser. if the printer has the free cycles and the planner is in no danger, then it makes sense to update one more segment now. This would make the display much more responsive, yet still retain the ability to return time to the planner when needed. |
You know.... If Atmel wanted to do it... They could make a 64 MHz version of the AVR tomorrow. I think they are trying to encourage people to move to the 32-Bit platforms. |
@thinkyhead that makes sense, so we don't decide about updating or not, but about updating another stripe instantly or not. In this case, the value for the check shouldn't be very critical, so it should be able to find one valid for nearly every display. If it's a little bit too high, the display will be slower but not unresponsive. Maybe this can be incorporated with #5430? I wasn't looking into this PR in detail, but maybe it's possible to replace the In this case I would recommend to use a fixed value in long_move() to keep the config easy - we only have to find a valid one. I far as I have it in mind, the longest update now takes ~20ms, which would mean about 40ms (factor 2 as a worst case rule of tumb with ISRs). |
I'll make some experiments with the following concept: Keep track of the times for partial screen updates. Continuous update a max.-value. Reset it by homing/booting or what ever. (Can differ considerably - SREENROT_180) That could work without configuration. |
Looks and feels great! Debug output format - printed only when display updated short moves
status screen idle
Turning nob in menu
PR tomorrow. |
Preview at 'Adaptive screen updates AnHardt#71' |
Adaptive screen updates for all kinds of displays #5495 |
I had enabled it only for compilation error and warning detection. |
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. |
I wrote this feature because of the very long LCD update. In fact, short time after this PR the slow update was fixed by updating the LCD in stripes. I did some tests today to see if it's still useful. I wasn't able to get a drained buffer at 115kbaud without it.
Aditionaly, @AnHardt pointed out that it's not easy to find good values for it.
I can't speak for other printers and I'm also not sure if I found a proper worst-case scenario for the test this time. Therefore I want to ask if someone is using this feature in RCBugFix or RC8 with a positive effect?
If it's not useful any longer, we could clean up the Configuration_adv file a little bit and avoid confusing users with another feature by removing it.
The text was updated successfully, but these errors were encountered: