*updated* Graphical LCD refresh makes the motors to stutter (Arduino2 and SKR1.3, all 32bit boards?)

[mignolo4]

Hi,
after I found the way to make the LCD work (see issue #12294 )
I 'm experiencing some stutters whem moving x-y axes on my self-made Delta-style 3dprinter (RADDS +FULL_GRAPHIC_SMART_CONTROLLER).

If I send a simple movement like G1 X-140 I can clearly see that the movement in not smooth.
edit: video added - you can find it after the picture I posted below

I tried to narrow down the problem and I found that the movement is smooth if:

• I change DELTA_SEGMENTS_PER_SECOND to something lower than 40

• I deactivate the LCD (the movement are smooth even with DELTA_SEGMENTS_PER_SECOND 300)

• the movement is only in the Z direction

Already tried:

• to restart from a fresh installation with default values and modifying only 4 essential parameters: board, endstops, thermistors, and obviously the lcd

• old releases of bugfix 2.0 (I stopped trying with the 30 september release)

• MEGA shutdown...Solved - Delta Segments Per Second Issue #6703

• Issue with large prints, firmware locks up and skips gcode #7677

No problem at all with other firmwares!
Am I doing something wrong?

[thinkyhead]

You may have the display controller configured in such a way that it takes a very long time to update the display, in which case the planner could experience starvation. However, Marlin times the duration of display updates and throttles back the frequency if it detects that planner starvation is imminent. So the display update time would have to be pretty extreme for planner starvation to occur.

[thinkyhead]

It would help to have your configuration files, as requested in the issue template. Please put them into a ZIP file and drop them on your next reply.

[AnHardt]

Would also be interesting to know if moving slow stutters more than moving fast - much faster.

[AnHardt]

My suspicion is you are moving slow.
Because of segments_per_second the sub moves become small - very small. Much smaller than min_steps_segment. So only every now and than a valid, large enough, segment pases the planer and enters the planer buffer.
Because the algorithm for delaying the display update needs an exception, (It does not delay when the planner buffer is completely empty), and the buffer is almost always empty, it has no chance to fill up because of the time consuming display updates. Also the time needed to step, a that short segment, is too short to get the next valid one planned.

Solution would be to limit the shortness of the sub-moves to about min_steps_per_segment.
AnHardt@793a50b
can limit the size of the subsegments to about the right magnitude. The smallest segments will still be too short. But two of them will give always a usable block, while now it's possible, if slow enough, to need 20, 200, 2000 or more subsegments to make a usable block.

Even when you switch off the display you currently get lots of to short unconnected moves, but the valid ones will be evenly distributed in time, without the breaks for the display update.

Just a theory!

ADVANCED_OK can give the answer - the state of the planner (and other) buffer.

[mignolo4]

edited: added picture + video, look at the bottom!

Hi,
first of all, thank you for your replies.

@thinkyhead:
I'm sorry Scott but I think there's not so much to see in my configuration files because, as I said, they are almost standard!
I download the lastest release, change 4 parameters for a quick test on my delta (board, endstops, thermistors, and obviously the lcd); that's all.

What's not standard is the way I make the lcd work.
Because if I only enable the graphical lcd
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
everything works as expected (but I can't see anything on the display)

Then, when I change this in the ultralcd_DOGM.h file:

#elif ENABLED(U8GLIB_ST7920)
  // RepRap Discount Full Graphics Smart Controller
  #if DISABLED(SDSUPPORT) && (LCD_PINS_D4 == SCK_PIN) && (LCD_PINS_ENABLE == MOSI_PIN)
    #define U8G_CLASS U8GLIB_ST7920_128X64_4X_HAL
    #define U8G_PARAM LCD_PINS_RS // 2 stripes, HW SPI (shared with SD card, on AVR does not use standard LCD adapter)
  #else
    #define U8G_CLASS U8GLIB_ST7920_128X64_4X
    #define U8G_PARAM LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS     // Original u8glib device. 2 stripes, SW SPI
    //#define U8G_CLASS U8GLIB_ST7920_128X64_RRD
    //#define U8G_PARAM LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS 

the lcd starts to work but the movements start to stutter!

@AnHardt
I understood 20% of what you said :-) because I'm not a programmer or similar but only a passionate guy following this amazing project, sorry!
Anyway, I gave a glance at your commit but I noticed the code has changed from that time and I was not able to insert those lines in the last versions.
Concerning the speed I don't think I'm moving slow because the stutter become worse and more visible if I increase the speed (if this was what you meant).

I am available for any test or solution you suggest me.

Here the "quality" of the print with the stutter:

... and a video showing THE stutter :-)
https://youtu.be/SYVsJR98xgk

[mignolo4]

@thinkyhead

A little big step in the right direction (I suppose):

I tried more or less 30 different versions going back in the past and Marlin-604b804125571782a11ff819b29a062b23879ba0 (27sept2017) doesn't show the issue!

I'm going to find out when excatly the problem was introduced!
Do you think it's a good idea or I'm wasting my time?

[marcio-ao]

@mignolo4: Usually if you can find the commit in which something started going bad, it's a great first step. However, over a year ago.... that's a lot of commits to look through!

[mignolo4]

It's definitely something happened from 27th sept to 7th oct 2017!
Going back to check, uhm, not really, going to bed now! :-)

[thinkyhead]

Interesting. If you can narrow it down to a specific day, even better!

[mignolo4]

@thinkyhead

I think I found it!
The last version working well with my configuration is commit: 604b804
If I understand correctly how commits work, the one came immediately after was 88f9194

... and that one last commit introduced the stutter!

Now it's up to you Scott to spread the magic!

[thinkyhead]

I’m glad to hear you found a point in time that works. The referenced commit would not have had any effect, so we’ll have to look at the general timeframe.

[mignolo4]

Does it help if I check one by one all of the commits of that day to see if some of them work well?
So you can focus on the others?

EDIT:
checked some more commit of the same day and only c869dc9 is SMOOTH.

To check my theory I went back compiling some versions of 26th and 24th Sept expecting smooth movements:
surprisingly enough I find out that those versions are NOT smooth again... so now I'm confused.
I think there's not much more I can do with my knowledge.

[mignolo4]

After a lot of time I'm here again to add some information.
I had the possibility to try another LCD, non graphical this time (RRD Smart Display aka LCD2004) with the same configuration and it works flawlessly without any problem.
Any news on that issue?

[boelle]

@mignolo4

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• RepRap.org Marlin Forum
• Tom's 3D Forums
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• Marlin Discord server. Join link: https://discord.gg/n5NJ59y

After seeking help from the community, if the consensus points to to a bug in Marlin, then you should post a bug report.
Before posting a bug report please test with bugfix-2.0.x to check if problem is gone

[mignolo4]

@boelle
sorry, I know I'm not expert at all but honestly I thought that was (is) a BUG and I was trying to be helpful in some way

[boelle]

uppps... i just saw the question label

but is the bug still there in latest bugfix 2.0?

[mignolo4]

:-)
really don't know, last time I tried was one month ago; I'll try again soon

[boelle]

mabe close this one and open a new when you have tested?

[mignolo4]

Just tested with no good news :-(
Do you think it's better to start a new issue for a better visibility?

[boelle]

nope, we just keep this one open

[mignolo4]

I bought a new SKR v1.3 board (LPC1768 32bit board) and the stutter is still there (again: with a delta config).
So now is quite obvious that's a display issue.

edit:
I can give you guys a new information I've never noticed before:
The stutter is there only in the main screen!
It seems that when the screen updates with new coordinates of the axes the stutter appears.
Everything is buttery-smooth if I enter the menu!

Here is a video with the slowmotion function because it was the only way to see it in a video :-)
Pay attention at what happen in the lower-left corner in the left motor
https://youtu.be/SgVZHnPevCo

[gloomyandy]

@mignolo4 Are you still using a modification to get the display to work? If so did you try it with just the standard configuration? If you are still using that modified config, please post the details of the display you are using. Please don't just say it is a FULL_GRAPHIC_SMART_CONTROLLER because we need to know exactly which one it is, there are many different manufacturers of these displays. Please post pictures of the boards and a link to the supplier if possible. Many, many people are using the SKR board with a REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER with no problems (I have two sitting here in front of me working fine), so we need to identify why yours is different.

[mignolo4]

@gloomyandy
no modification with the skr1.3 (only the display define) since it has everything you need onboard for the lcd, so exp1 and exp2 connected directly to the lcd and even working with 2 (two) meters flat cable :-)

Before I write the info about the lcd board... are you using a delta configuration?
Because only with that one the issue occurs!

edit: pictures added

[gloomyandy]

So just to be clear your display works fine with the standard configuration with the SKR board and a recent build of Marlin? You are not making any changes to the U8GLIB settings (as you reported you had made before). The only display related change you have made is to define the display type? What have you got it set to?

When did you download the version of Marlin you are using on the SKR board? I assume you are using standard Marlin not the version from Bigtreetech?

You should probably upload your current configuration files for this new board.

[mignolo4]

Already tried that and it's not my case :-(

[DerAndere1]

@hobiseven regarding high level code architecture. I made a very rough code overview for my own purposes a year ago. It's probably not what you need, but here is the link anyway: https://github.com/DerAndere1/Marlin/tree/Marlin2ForPipetBot/docs

[thinkyhead]

@mignolo — You can get less demanding status screen drawing code by switching off all the fancy additions to the status screen and using the single header image instead of the individual nozzle and bed bitmaps.

If you are using 32x micro-stepping on any of your axes, go down to 16x micro-stepping.

The general problem is not that the screen drawing blocks the stepper ISR. It doesn’t interfere with it. However, screen drawing temporarily blocks the G-code queue from feeding the planner fast enough, and when the queue starves we get stuttering movement as the machine stops and starts.

There are various other things you can also try:

• Use 4 or 8 stripes to draw the screen.
• Use the hollow frame option instead of drawing XYZ inverted.
• Use the lightweight UI.
• Reduce the ST7920 delays to the minimum stable values.
• Make sure the 5V regulator on the board isn’t flaking out due to current draw from the LCD.
• Don’t spin the knob while printing. The LCD redraws the entire status screen on every tick.
• Use faster serial speeds / snazzier SD cards.
• See if the card reader will work in a higher speed mode.
• Turn off all extraneous features that do stuff in the main loop.
• Use the smaller font for the status screen.
• Increase the G-code buffer size.

That’s all I can think of off the top of my head….

[AnHardt]

The good news is: On the 32-bit boards the time used for 'drawing' the screen becomes less and less important.
The bad news is: Even on the AVRs, the time for 'drawing' the screen is lower than that for 'transfering' the data to the display.
The worst news is: We already send the data to the ST7920 as fast it can read them. We will never be able to improve this. Except by reducing the amount of data, like we try to do with LIGHTWEIGHT_UI for the status screen.
Stars at the horizon: We could try to shift away the load for the display updates, away from the main process(or) to DMA or external processors (intelligent displays handling the complete UI).
U8g2 now seems to be able to transfer only 'dirty' areas of the screen. That could decrease the amount of transferred data in the statusscreen (not in the menus where the complete screen contend changes with every encoder event - but in editing a value).

[thinkyhead]

the time for … 'transfering' the data to the display

Yes, this is not something we can do much about with the current u8g library, since each SPI bit requires a small delay, and the transfer is bound to the main loop. If it were possible to rewrite all of Marlin's SPI code and all the external libraries, then we could perhaps do all the SPI transfers in a coordinated interrupt. This would allow us to get back to managing the queues more quickly. Someday, perhaps…

[Roxy-3D]

Also... As a brute force fix to give the main Marlin code more processing cycles... You can change

#define LCD_UPDATE_INTERVAL 100

to 250 ms. The LCD encoder wheel will feel a tiny bit 'sluggish'.
But the main Marlin loop (with the important code executing!!!!) will have
way more time to process stuff.

[thinkyhead]

That's definitely going on the Troubleshooting > LCD / Controller section of the site. The amount of cycles freed up is going to depend on what's happening in the LCD code. There are some general housekeeping tasks and I'm sure the time adds up when doing them 100 times a second.

[AnHardt]

100 times a second

Of course. But it's every 100ms (100 * s/1000), so 10 times a second.

[tpruvot]

see https://github.com/MarlinFirmware/Marlin/pull/14595/files#diff-54ada0858fc4ed0c0dfc06aa12378c1dR834

its doable to improve the menu refresh while scrolling... and let the status screen as is... while printing

[thinkyhead]

At one point @AnHardt worked out a very good throttling mechanism that would prevent the screen from updating if it looked like the planner could starve. As far as I know that is still in place. So I wonder if it might just need to be more aggressive.

[AnHardt]

It's still in place.
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/ultralcd.cpp#L948-L951

A bit of debug output in line 950, printing bbr2 and max_display_update_time, should give a hint where the problem is - if there is one.

[Kaween-prog]

Just wanted to add this observation : When using the Fysetc 12864 mini display routines in Marlin (all builds I tested so far, no exceptions) and a Fysetc 2.1 12864 RGB display, the issue does NOT exist and movement is 100% smooth regardless of the state/menu the LCD is in. Just to confirm : yes, on a Delta (Anycubic Predator with an SKR 1.3 and Marlin 2.0) This makes me wonder :

So whatever is affecting the code routines in the full graphic smart controller and the discount variation, it's not affecting the Fysetc 12864's. (tested the 2.1 and 2.0, not sure about the 1.2 .... but as the only difference between those is the backlight color selection system so I wouldn't presume there's much difference there and the 1.2 will probably work the same way).

Maybe this can help a bit to try and trace the issue. As the issue doesn't show up using the Fysetc display code, it would seem logical to presume the problem should be found in the full graph routines ? Would it be possible to use the code for the Fysetcs and kinda backtrack from there, or even use that code as base to redo a test build for the full graph LCD code ?

Also, Bigtreetech has a "hybrid" TFT these days which allows TFT and 12864 emulation (TFT function run over the internal serial port like all other TFT's do, the 12864 emulation runs over the EXP1/EXP2 ports like a "real" 12864 would.) This screen also shows the "stutter" issue when Marlin is configured to use the 12864 reprap full graph routines (and the discount version too ... obviously).

But I find it interesting the Fysetc 12864 mini's do not show the same stutter issue using the same machine, board and Marlin build, and I don't think anyone has mentioned this so far.

Hope this can help people way smarter than me to have a new look at the issue and try to solve it.

[AnHardt]

The Fysetc 12864 mini display uses a completely different display driver chip (ST7567). Probably you have to transfer only half the amount of data and can do that at a much higher speed then with the ST7920 of the RRDFGDC. The ST7920 is really bad! I was a bit shocked when i discovered the new shiny color displays try to emulate exactly that crap.

[AnHardt]

Time for a 1/4 screen update on a BBT SKR PRO 1.1 (F407 168MHz)
MINIPANEL ~1-2 ms
RRDFGDC ~7-8 ms

The processor is at least 10 times faster than a AVR, but the time for updating the RRDFGDC is about the same.

[mignolo4]

So... something has definitely changed in these last weeks...

I downloaded today's version (22 august 2019) and made my usual modification:

• modified the strings in the ultralcd_DOGM.h file
• chosen the delta xl config as a starting point
• modified the board define (I use a RADDS)
• chosen the RRDFGSC as a lcd
• oddly enough I had to downgrade the u8g lib from v1.19 to v1.18. because of a compiling error

Now the movements are super smooth but... because the lcd doesn't react at all if it is printing:

• static info screen, no button functionalities so it's impossible to enter the menu.
  If I pause the printing process the lcd starts working again, the info are updated, the rotary encoder works too.

I suppose this is a bug but everything considered I would say I'd prefer a display not showing the coordinates during the movements instead of the stutter... but I know, this is not a request thread ;-)

[AnHardt]

I repaired the display throttling last week. (Repair display throttling #14960)
Now, again, the display is updated delayed if there is not enough time in the planner buffer.
If there is not enough time in the buffer to run longer than the display update lasts, the buffer would run dry and you get a stop or at least slowdown. To get smooth printing and smooth display updates, print longer lasting segments (on a delta less segments per second), use a faster processor and/or a faster display, A longer planer buffer also may help in border cases.
Smooth printing has priority over the display now again.
Even under full load the display and knobs should work - but may be delayed up to ~10+ seconds. We measure the time the update lasts for every done update but decrease that time by 1 ms for every not done update.

[mignolo4]

@AnHardt
I've tested what you said and:

with a test gcode sent with repetier host (it moves from x-140 to x+140) the display didn't update or react for the whole lenght, about 4 minutes.
Then I modified the speed from repetier and I could see almost immediately the difference from the motors; the screen updated after 1 minute and 20 seconds!!!

p.s. 32bit board (arduino 2 +radds), DELTA_SEGMENTS_PER_SECOND 160

[AnHardt]

4 minutes for 280mm?
Don't wonder when the segments are short.
4*60 = 240. 240*160 = 38400. 280/38400 = 0.00729167 mm/segment -> 137.14 segments/mm.
240 seconds/38400 segments = 6.26 ms/segment (= 1000/160).
If i remember right the display does not show the actual position but the last accepted g-code. Try 10 moves of 28mm instead.

Yes, for the character displays the update is done in one big block and can last about 30 ms (if i correctly remember) -> so update can be delayed by about 30 seconds. Planner buffer needs to contain at least 2*30ms/6.25ms/segments = ~10 segments to be in time.

[mignolo4]

4 minutes for 280mm?

oh sorry, I meant "it moves from x-140 to x+140" repeatedly for about 4 minutes

edit:
tried to lower the segments per second: now at 16
well... it works quite well:
the encoder reacts instantly; when I send a command it takes a couple of seconds to update the lcd and the movements seams smooth even because the update happen at the end of the movement and not in the middle (don't know if it's clear what I mean)

the odd thing is that the reaction is proportional to the speed I set:
at 100% printer speed the reaction is about 2/3 seconds
at 25% the motors slow down and the display updates after 29 seconds
isn't it strange? (edit2: ah wait... if the info in the buffer are always the same and it takes longer to finish the movements this behavior could be normal)

[mignolo4]

So guys I think we are close to a solution here!!! 👍

Have a look here: #15045
Thanks to @PKav89 for the hint!

To summarize:
with these parameters (configuration_adv.h) 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

...a value of 64 instead the default 16 one; not even with 32 it works

[Kaween-prog]

Very interesting, really must try this too. See if the BTT Hybrid agrees with these values too (pretty sure it does, as the issue even happened without an LCD connected in my case).

[Roxy-3D]

There isn't room on the 8-bit AVR's to have this value set that high.

It would need to be something like:

#ifdef CPU_32_BIT
  #define BLOCK_BUFFER_SIZE 64
#else 
  #define BLOCK_BUFFER_SIZE 16 
#endif

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