Print stuttering with Full Graphics Display

[nickbardom]

Hi,

I just tried to print a complex gcode and I noticed the print stutters if I compile the code using the Full Graphics display. i stutters the same on USB and SD card printing. If I compile without Full Graphics LCD, it prints fine from USB.

[AnHardt]

@nickbardom It's a already well known problem. The display update for character based displays takes about 20-30 ms . For the full graphic displays 80 up to 180ms (depending on the display type) are needed.

In my https://github.com/AnHardt/Marlin/tree/lcd-speedup (https://github.com/AnHardt/Marlin/pull/13) branch i collected all speedups for the full graphics displays i know about. For the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER i reduced the display update to below 60ms. Furthermore that time is not used en block anymore.

I beg for feedback.

[thinkyhead]

the print stutters

@nickbardom If you're using a Delta machine then you can try reducing DELTA_SEGMENTS_PER_SECOND until you get acceptable performance.

I beg for feedback.

I beg for a graphical display… literally… on Patreon and GoFundMe. So far no one has sent me one. :disappointed:

[emartinez167]

Scotty, I think I have a spare one. Email me your address.

On Fri, Mar 11, 2016 at 7:19 PM, Scott Lahteine notifications@github.com wrote:

I beg for a graphical display… literally… on Patreon and GoFundMe. So far no one has sent me one. [image: :disappointed:]

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3129#issuecomment-195324970 .

[nickbardom]

Hi, thanks everyone for replying. My printer is a cartesian type. I just tested the Repetier firmware using the same display and it works flawlessy. So I think there is room for improvement. I noticed the Repetier firmware includes the u8glib(maybe customized?)

[jbrazio]

@nickbardom I have a full graphics display and my printer doesn't stutters.. Couple you please post a complex g-code so I can test on mine ?

[nickbardom]

Sure, here is the file. Is an object from thingiverse. I disabled the extruder and bed heating from the gcode, so it will not print anything as the firmware will not extrude with a cold bed/extruder, but you will see the movements and you will be able to see it stuttering from the beginning of the print(1 layer). I suggest you to test with the display and after that compile without the display support and test again. stutter.zip

[jbrazio]

@nickbardom Could you please try to run this g-code with Marlin RCBugFix and LCD enabled in Prointerface and copy paste the last line i.e. Print ended at: 17:43:49 and took 0:00:44, just to have a reference value between your printer and mine.

[jbrazio]

I've done the following tests, always using the test.gcode I've attached on my previous comment.

Printer Hephestos 2 with LCD using serial at 250kbps with my standard config took 0:00:46 Then I edited the code and made the following change lcd_update() { return; }, printing took 0:00:46 Then I disabled SDSUPPORT on the config, printing took 0:00:44 Then I disabled BQ_LCD_SMART_CONTROLLER, printing took 0:00:44

I see the stuttering but I see no difference between having LCD enabled or not.

This g-code is very "verbose" could it be a throughput limitation on the serial ? I'll try printing from SDCARD and update this comment.

With my initial configuration printing from the SDCARD the same gcode takes 27s to complete. So in the case of my printer the limitation is not either the LCD is enabled or not, is in fact related with serial throughput. (My host is an i7-2600 @ 3.7Ghz)

[nickbardom]

Hi jbrazio, when I get home I will make the test with your gcode and post the results. I already tested the gcode I posted with the RCBugfix and got the same problem. Meanwhile, did you make your tests using Reprap discount Full Graphics LCD too as this is the one I am using.

[jbrazio]

My gcode is basically only the skirt of yours, like this we can time it quickly.

It's the same code base for the LCD, Marlin basically has two groups of LCD, line/char based and dot matrix LCD. Mine is a dot matrix one similar to yours.

[nickbardom]

Hi, I just made the tests using USB connection to the computer. Skipping the homing process(as it can be different between printers). It takes 12s to print without LCD and 35s with the LCD.

[jbrazio]

Let's try do to another benchmark. Start with a clean clone of RCBugFix then issue the following commands:

git checkout -b test-lcd
git remote add anhardt https://github.com/AnHardt/Marlin.git
git fetch anhardt
git cherry-pick --strategy=recursive -X theirs 714a72b

Copy over the Configuration.h and Configuration_adv.h for you printer into the tree, compile and upload that version you'll see on the serial line a debug line like this LCD_update: 2 81 which is the refresh time of the LCD, could you copy/paste the info ? Thanks.

[jbrazio]

Now that we are at it you can test the full patch from @AnHardt. Start with a clean clone of RCBugFix then issue the following commands:

git checkout -b test-lcd2
git remote add anhardt https://github.com/AnHardt/Marlin.git
git fetch anhardt
git merge -X theirs anhardt/lcd-speedup

Copy over the Configuration.h and Configuration_adv.h for you printer into the tree, compile and upload, you'll notice a different info screen:

Print again the smaller benchmark file, did it improve ?

I have exactly the same results with and without the patch, it seems that in my specific case the driver chip for the LCD is a lot faster making the serial line the bottleneck.

[nickbardom]

I will do that, meanwhile I tested your gcode file from SD.. Without LCD(skipping homing: 12s. With LCD(disconnected from the computer):50s!!!

[nickbardom]

I tried to install git on the laptop connected to the printer, but it is not working. Maybe Windows 10... Could you please post the RCBugfix with the patch so I can just exchange the Configuration.h and Configuration_adv.h and test it?

[jbrazio]

Here you have, the patch against 7bb7ac8. @nickbardom if you need the hex file just drop here a config bundle for you printer and I'll build it for you.

[AnHardt]

Thanks for testing. You can reactivate the lcd-benchmark here (https://github.com/AnHardt/Marlin/blob/lcd-speedup/Marlin/ultralcd.cpp#L1733) It's helpfull to observe the buffer usage. You'll get the output with ADVANCED_OK. When the p-buffer runs dry you get the slowdowns. Then - being slow again, the buffer fills up again. Testing with RepetierHost gives you a relative exact timestamp. With that, you can count g-code lines/0.1 seconds. Can you find irregularity's about 1/sec - that would be the display update in the unpatched Marlin.

@nickbardom What display are u using? (exact type in the configuration?) The display is refreshed regardless of plugged in or not. You have to comment the setting for it and recompile to get an effect..

@jbrazio Hephestos display runs the same code as the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. By changing PAGE_HEIGHT (https://github.com/AnHardt/Marlin/blob/lcd-speedup/Marlin/ultralcd_st7920_u8glib_rrd.h#L16) you can distribute the display update better, but it will increase the overall time for one display update. Can you observe a positive effect on stuttering?

[AnHardt]

I know, the display update, in the menu, with the 'distributed update patch' feels a bit blurry - like it has been about a year ago. Is this acceptable for you?

[jbrazio]

#define PAGE_HEIGHT 32 took 0:00:52

#define PAGE_HEIGHT 16 took 0:00:52 -- Display corrupted:

#define PAGE_HEIGHT 8 took 0:00:50 -- Display corrupted:

I know, the display update with the 'distributed update patch' feels a bit blurry - like it has been about a year ago. Is this acceptable for you?

@AnHardt You mean "blurry" as in the opposite of sharp pixels on the display ? Or do you mean the overall look and feel i.e. user perception of the display ?

[AnHardt]

Hmm, sorry. Looks as if i have to rework the calculation when to display what stripe. Or, something got lost at the transition to the new HEAD of RCBugfix. I'm sure you had to solve some merge conflicts. Sorry, no tests here before Monday.

With blurry i meaned it takes a while (up to a second) until the display is refreshed completely.

[AnHardt]

I think i got it. I forgot to mention you have to adjust DISPLAY_STRIPES from 2 to 4 or 8. (dogm_lcd_implementation.h in the section for U8GLIB_ST7920_128X64_RRD )

[jbrazio]

There were some merge conflicts but I went for your version vs. the RCBugfix. Yes indeed the refresh rate is a bit on the "low-end".. :-/

I should only test 8, 16 and 32 PAGE_HEIGHT ? If I got you right for PAGE_HEIGHT 8 DISPLAY_STRIPES must be 8.

Btw there is a typo at dogm_lcd_implementation.h, the define is DISPLAY_SRIPES which is missing a "T".

[AnHardt]

Don't care about the typo for now - that is consistent (copy-paste).

PAGE_HEIGHT 32 -> DISPLAY_STRIPES 2 PAGE_HEIGHT 16 -> DISPLAY_STRIPES 4 PAGE_HEIGHT 8 -> DISPLAY_STRIPES 8

64 / PAGE_HEIGHT = DISPLAY_STRIPES

I'd like to calculate that, but PAGE_HEIGHT is not defined in dogm_lcd_implementation.h.

All other combinations can not work.

[jbrazio]

Done the test with #define PAGE_HEIGHT 8, #define DISPLAY_SRIPES 8 and display corruption is gone but I don't notice any improvements with my BQ_LCD_SMART_CONTROLLER when comparing RCBugfix vs. your lcd-test.

The test is also consistent when printing from SD:

• Printing from SD is faster than from serial
• But having LCD or no LCD active on the config file does not affect the print time/stutter for both RCBugfix and AnHardt-lcd-test-branch

Why am I having these unconsistent results vs. people with REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER which seem to have improvements using your branch ?

[AnHardt]

I think you are seeing the same as with the original REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. My measurment are made when idling. The time for the display refresh was reduced from ~80ms to ~60ms with 2 stripes. For more stripes the win is smaller or negative, because then we again draw the same things more than once. 80ms -> 60 is a respectable improvement of ~ -25% for the display update but ~20ms/1s is only ~-2% overall. So my hope was - and that was untested, updating the display in portions (stripes), not all at once, but a bit distributed, could give the system enough time to fill the the p-buffer again - between displaying the stripes.

Printing from SD is faster than from serial

We don't need a 'ok - next-line' handshake here. We don't have to mess with line-numbers and checksumms.

But having LCD or no LCD active on the config file does not affect the print time/stutter for both RCBugfix and AnHardt-lcd-test-branch

If that is true, updating the display is not the weak point in the system. Hurray! We don't need my speed-patch.

[nickbardom]

Hi,

@AnHardt I am using the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. Does the Marlin firmware requires any feedback from the display controller to keep going(like an ACK)? I am asking that because as you said, it will print slow(stutter) even with the display disconnected.

@jbrazio What should I so with the file you posted? Sorry, I don`t have any github experience.

[AnHardt]

@nickbardom No. It does not need an ACK. But Marlin keeps calculating the display content and sending it into the dark. So with unplugging the display you get no loss but also no win.

[jbrazio]

@nickbardom upload to this thread the Configuration.h and Configuration_adv.h for your printer, I will produce the Marlin.hex you need to flash it using Cura or any other method you prefer to update the firmware image of your board.

[nickbardom]

@jbrazio Thanks for helping. Attached are my configuration files.

config_files.zip

@AnHardt Thanks for the info. So it doesn`t matter if the display is slow or fast(from different manufacturers). All of them will be slow as there is no ACK, right? Did you take a look at the Repetier firmware? The display works fine with no stutter or slow down on it.

[jbrazio]

@nickbardom here you have: Marlin-7bb7ac8-with_lcd_enabled.ino.hex.zip Do you mind taking a video of you printer stuttering (with LCD) and not stuttering (without LCD) so we can have a visual of it ?

[nickbardom]

@jbrazio I just tested it with the hex you sent. It worked better. Printing time:14s(SD or USB) vs printing time 12s(SD or USB without LCD). So there is a problem in the LCD code. As AnHardt said, the LCD does not send an ACK message back to Marlin, so I wonder why you cannot reproduce the error if your LCD uses the same driver. Maybe your USB serial bottleneck? Did you try to print from SD without LCD(using the host software to browse the files in SD)? What is your printing time?

Please check your movement settings on the configuration.h to see if you have similar feed rate than mine.

Usually when I am debugging the code I write for microcontrollers, sometimes the bug could be elsewhere. I saw the patch lowered the printing time with LCD, but as you cannot reproduce it, maybe there is another problem. I use an unusual setting that is Z_DUAL_STEPPER_DRIVERS in Configuration_adv.h. I cannot test my printer without it, but if you are not using the Extruder 2 and using just one Z driver, you can enable it and test. See if your printing time changes.

[jbrazio]

I will have it a go and report back the findings as this is intriguing me why we see such different results.

[AnHardt]

There is no MISO-line at the displays - no chance for an ACK

[AnHardt]

What host programs do you use? Foosel i fighting a relative high delay in OctoPrint this week. (https://github.com/foosel/OctoPrint/issues/450 )

Maybe there are relevant differences between the hosts.

[nickbardom]

@AnHardt

As there is no output line, the problem cannot be a hardware difference as I stated. If the host question is for me, I tried almost all of them and have similar results. As the problem occurs using SD card too, it is not related to the host. But if the question is to jbrazio, it could be his host that is slow or maybe he is using Octoprint ;-)

About the Foosel Octoprint issue: It is a whole different problem: serial bottleneck on Raspberry Pi. I tested this issue here too. I posted in their issues a few weeks ago about that.

[jbrazio]

I'm testing from a moderately beefy i7 using Pronterface.

[nickbardom]

@jbrazio So your computer is way better than the notebook I am using! This makes the issue more intriguing!

[nickbardom]

@jbrazio Hi, did you make the tests?

[jbrazio]

@nickbardom I will do the testing today when arriving home, I haven't had the time yet, sorry.

[nickbardom]

@jbrazio

Hi, no problem at all and thanks for replying. Please let me know the results when you test :-)

[AnHardt]

test: brim. Without homing nozzle at the position of the last test. speedbranch untested but probably in between clcd and glcd. What does not make a big difference.

green -> OK red -> stutter

FR -> FeedRate clcd -> REPRAP_DISCOUNT_SMART_CONTROLLER glcd -> REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

extension

-          sprintf_P(time, PSTR("%i " MSG_END_HOUR " %i " MSG_END_MINUTE), hours, minutes);
+          sprintf_P(time, PSTR("%i " MSG_END_HOUR " %i " MSG_END_MINUTE " %i seconds"), hours, minutes, t - (hours*60*60) - (minutes*60));

What do we see: As long we have time enough it does not make a difference if or what display we have. sd-printing is faster than USB-, if not limited by the mechanical speed. When under heavy load there is a tiny difference between the displays. High feedrates cause more stuttering - the result is not significant faster. Stuttering does not begin when the planner buffer runs empty, but when filled less than 50%! (SLOWDOWN)

bool mq = moves_queued > 1 && moves_queued < (BLOCK_BUFFER_SIZE) / 2;
    #if ENABLED(SLOWDOWN)
      //  segment time im micro seconds
      unsigned long segment_time = lround(1000000.0/inverse_second);
      if (mq) {
        if (segment_time < minsegmenttime) {
          // buffer is draining, add extra time.  The amount of time added increases if the buffer is still emptied more.
          inverse_second = 1000000.0 / (segment_time + lround(2 * (minsegmenttime - segment_time) / moves_queued));
          #ifdef XY_FREQUENCY_LIMIT
            segment_time = lround(1000000.0 / inverse_second);
          #endif
        }
      }
    #endif

Is this correct? Maybe we can make it a bit smoother.

[jbrazio]

@AnHardt as I have SLOWDOWN disabled I did debug the buffer using the test g-code and I found to have an empty buffer during every curve of that g-code, just only during the two "straight lines" the buffer got something inside.

[AnHardt]

That does not make me wonder. All the segment in the curves are quite small. Without SLOWDOWN the buffer runs dry. When the buffer runs dry, there is a slowdown to 0. That really hurts. But even with SLOWDOWN the breaking seems to be not smooth. Tomorrow i'll try a deeper planner buffer, to see if the steps in speed get smaller. There is also an alternative algorithm (OLD_SLOWDOWN) i want to try. But i'm already quite sure there is an error in the calculation. When SLOWDOWN kicks in, inverse_second seems to change the magnitude - at least for the input values i tried.

[jbrazio]

Disabling SLOWDOWN in fact makes things worse ? Ok that can explain why my printer takes more time for the same gcode. Will check the behavior with the option active an see if it behaves differently.

[paulusjacobus]

@thinkyhead I just installed the RCbugfix release to test it on my Prusa It2. I noticed that the printer stutters as well. Normally I print at 60mm/s which I have taken down to 40mm/s but still I see a lot of hesitations (stutter). I do run a display S1306 OLED with ramps1.4/Mega.

[jbrazio]

The SLOWDOWN flag has no effect on the issue, in fact I can't even tell if it is really doing something as the print job time is exactly the same with or without it and I'm positive my buffer goes zero during the print job.

[paulusjacobus]

Noticed the issue with small arcs, like for example printing a "gt2 belt clip". Other forms line lines and big arcs work well.

[jbrazio]

Yes that was already confirmed.. in the end of the day this could be in fact an issue from the slicer.. So far I only saw this behavior with the test g-code found on this thread an another print which I don't recall exactly what it was.

[paulusjacobus]

could be in fact an issue from the slicer.

@jbrazio I already thought so, since it just happens with little (better tiny) arcs

[thinkyhead]

I'm voting for this being a slicer issue. I've seen this behavior when I slice models that have too many facets. It should actually improve if you enable G2/G3 arcs in the slicer. So far I can't see any extra stuttering on my i3 with Mega2560.