[BUG] Print resumes after pause, "wait for print to resume" stays on screen.

[Kaween-prog]

Marlin 2.0.1 Bugfix (all commits I've tested so far) on SKR1.3 and using RRDFGD. Delta printer.

Description
When selecting the "pause print" menu selection, the printer will fully execute all the typical steps for the pause function correctly. However, when the user wants to resume the print, again all steps are executed correctly and the printer DOES correctly resume the print, but the LCD display be stuck at the ""Print Paused Wait for Print to resume ..." message for roughly 3 minutes, after which the LCD finally does get released and the main info screen is shown again.

Steps to Reproduce
Press menu knob on panel
select "pause print"
LCD shows "printer paused"
lifts Z, runs the effector to the correct pause position
waits for user input to resume

after pause has been succesfully carried out, click to resume

Expected behavior:
Print Paused Wait for Print to resume ..." would be displayed until the print actually resumes, and after that the LCD should show the main info screen again.

Actual behavior:
Print Paused Wait for Print to resume ... STAYS on the LCD screen for 3 to 4 minutes, although the printer does correctly resume the print. After a (seemingly) artbitrary 3 to 4 minutes the LCD does return back to the info screen and everythings works correctly.

Hardware :
Anycubic Predator Delta
SKR 1.3 Board
Bigtreetech 2.4TFT with 12864 emulation mode
X/Y/Z/E0 = TMC2208 in Uart mode
latest bugfix 2.0 code used + several older versions (same issue)

Also tested with TMC2100 in Step/Dir to exclude UART functionality as issue. Does indeed behave the same way.

Anyone any idea what I'm missing here ? I'm pretty sure I botched up something, but no idea what or where. Note : using the "change filament" LCD option does not show this issue, and "resume" fully works as intended in that case without the LCD betting stuck on the same "Wait for Print to resume ...." LCD condition.

Update / Clarification :
the issue +only+ exsists when the users choses a manual "pause" function over the LCD. If the printer has to deal with a filament out condition or the manual "load/unload" functions are used, the issue does not occur and the LCD returns to the main menu flawlessly upon resuming the print.

Update 2
Another user (Shitcreek, thank you for chiming in and testing) confirmed the issue on a Cartesian, so it's not related to the type of printer like the block_buffer_size issue seemed to be.

[shitcreek]

Have you tried increasing BLOCK_BUFFER_SIZE?
#15385 #12461

[Kaween-prog]

Yes, tried values 16 (original), 32 and 64. Doesn't make any difference (to THIS specific problem : a bigger block buffer does have a good influcence on motor axis stutter on Delta's with RRDFGD. Must try to see if the issue remains the same if I use a Fysetc Mini instead to exclude the RRDFGD to be the issue itself.

[shitcreek]

Confirm same issue on BigTreeTech SKR 1.3 cartesian. After a print pause, it takes a while for status screen to return and menu becomes unresponsive / glitchy.

[Kaween-prog]

Thank you for confirming the issue is not limited to Delta printers, "Shitcreek". :) (Gah, it's hard to thank someone when their nick looks like I'm insulting them :D )

Will test with another type of LCD screen this weekend to see if it's connected to the code handling of the RepRap Discount Full Graph LCD's or a if it's a more generic issue. May not be very likely but will help to pinpoint the problem.

Have an Fysetc Mini as spare wich didn't suffer from the block size issue either so sometimes oddities do occur.

[karabas2011]

The same problem on deltas with Sbase(modified for ->) + rrd smart controller( NOT GRAPHIC)
Return from pause get blank screen for several minutes. I have already increased buffer to 64 to make display less slow. Marlin 2.0 - 12/sept/2019

[thinkyhead]

To troubleshoot the issue, we will do several small "faux" print jobs and pause them to see what happens. If we can reproduce the long unresponsive screen issue, then we will be able to throw in some logging to see where it's getting stuck. By following the breadcrumbs we will find the exact cause and endeavor to fix it asap.

[AnHardt]

We do see a increasing number of "delayed display updates" issues since (Repair display throttling #14960).
For some increasing the planner buffer depth seems to improve the situation.

But i guess the key to the problem is on the other side of the equation, in the time measured for the display updates.

    // then we want to use 1/2 of the time only.
    uint16_t bbr2 = planner.block_buffer_runtime() >> 1;

    if ((should_draw() || drawing_screen) && (!bbr2 || bbr2 > max_display_update_time))

A rough guess about the minimal runtime of the planner buffer is compared to the maximum time a partial display update took (decreased by 1ms fo every time the partial display update was skipped)

When i created this i had only status screen updates in mind. They always run for a relative constant time. Only these should be measured and delayed. When being in the menus a immediat response is expected. (And if the user sees the printer stutter its relative easy to see it as a consequence of playing with the display.)
It looks as if delaying and measurement is done for all kinds of screens now.
For most menus this should not be a real problem.
But:

• If reading the SD-directories is done while the time for the update runs that could cause relative long update times.
• If some "requesters" are waiting for users response or have delays of more than a few ms while being timed, this will cause mayor problems.

[thinkyhead]

increasing number of "delayed display updates" issues since (Repair

I have already been peeking at the throttling code to see if anything obvious stands out. One of the timing vars is 16 bit, and maybe it overflows. The long delay of ~3 minutes could just about correspond to the count range of a 16-bit number. I have seen some delays of up to 30 seconds at the start of a print, so this might be very reproducible. Or, I can induce some artificial conditions and see if the issue gets triggered. If it turns out to be a simple sign-compare issue, that would be great.

[AnHardt]

        // To translate µs to ms a division by 1000 would be required.
        // We introduce 2.4% error here by dividing by 1024.
        // Doesn't matter because block_buffer_runtime_us is already too small an estimation.
        bbru >>= 10;
        // limit to about a minute.
        NOMORE(bbru, 0xFFFFul);
        return bbru;

This will not overflow uncontrolled. The 16 bit value is carefully controlled. The 32bit µs value will hold up to about 70 minutes.
If a measured display update should last longer than 0xffff milliseconds (more than a minute) something went wrong. It shouldn't last longer than a few dozen milliseconds. 100ms should be exceptional long. (My best ever measured number for a status screen update was 4ms for a char display at a SKR PRO. Worst about 100ms for a complete screen VIKI2 with the old driver and rotated 180° on a 16MHz MEGA . Both values without stepping in the background.)

[AnHardt]

Start point for debugging could be printing max_display_update_time and correlating unusual high numbers to "actions" or configurations.

[Roxy-3D]

Start point for debugging could be printing max_display_update_time and correlating unusual high numbers to "actions" or configurations.

And if nothing else... Backing up 250 lines of GCode from that location and starting to 'Print' would give a very repeatable, quick way to debug and locate the issue.

[Kaween-prog]

Update / new observation.

I'm currently using the affected machine for an urgent print job so I can't really play with it too much, but it would seem the "delay time" of 4 minutes can, for whatever reason, become a lot, lot longer.

The 3 to 4 minute delay time seemed pretty much constant on previous test prints, but currently I'm doing a "real" part and yesterday I just thought to check the condition and behavior on that one too.

The basic end effect stayed the same : so apply pause, machine pauses, click resume machine resumes but the display maintains the "print paused, waiting for print to resume" as before, but it didn't clear after 3 to 4 minutes this time.

It took 11 (!) minutes for the display to return to the previous menu state (so the location where the pause function can be chosen) AND and this is the first time I saw this behavior : it would LOCK there too, just like the "print paused, waiting for print to resume" for about 4 minutes. So I saw the lcd return to the menu sub system which allows me to select pause, but it got STUCK there now for 4 minutes, the LCD being totally unresponsive and no navitation/selection was possible.

After those 4 minutes, the submenu position would release and the main info screen would come back on, this time in full normal working state.

We're talking about the same machine (obviously), same firmware build, and the same SD card but with a (much) bigger gcode file to process.

I tested it a second time after that, while still printing that same gcode file and a largely comparable condition showed : this time the "print paused, waiting for resume" stayed on screen for 16 minutes, and again the LCD would lock down on the menu postion where the Pause function is displayed for just below 4 minutes before returning back to the main info screen. During that time, the LCD was completely unresponsive.

So there's no use trying to connect the previously reported "waiting to resume" to a fixed time out. It clearly can vary depending on print job/gcocde file, and it can have a influence on the LCD menu system even beyond the initial "waiting for resume" condition.

Again : during all this, no printer issue (in terms of the actual printing process) occurs. The machine gladly continues to print and no slow down/stutter or quality degradation takes place.

When I've completed the current running print, I can do some extra tests if that would be helpful.

[AnHardt]

11minutes means the previous partial screen update was measured with at least 11*60 = 660ms
4 minutes would be 4*60 = 240ms.

Oh wait. The time is only decreased by 1ms if an attempt to draw is made - so 1/s only on the status-screen. If in the menu, what is tried to update only at an "event" this could last forever - or at least, the time begins to run only after returning to status-screen.

    // This runs every ~100ms when idling often enough.
    // Instead of tracking changes just redraw the Status Screen once per second.
    if (on_status_screen() && !lcd_status_update_delay--) {
      lcd_status_update_delay = 9
        #if HAS_GRAPHICAL_LCD
          + 3
        #endif
      ;
      max_display_update_time--;
      refresh(LCDVIEW_REDRAW_NOW);
    }

As said before. Originally this was only ought to delay status screen updates.

[AnHardt]

Maybe something like that:

@@ -982,11 +982,11 @@ void MarlinUI::update() {
     #endif
 
     // then we want to use 1/2 of the time only.
     uint16_t bbr2 = planner.block_buffer_runtime() >> 1;
 
-    if ((should_draw() || drawing_screen) && (!bbr2 || bbr2 > max_display_update_time)) {
+    if (!on_status_screen() || (should_draw() || drawing_screen) && (!bbr2 || bbr2 > max_display_update_time)) {
 
       // Change state of drawing flag between screen updates
       if (!drawing_screen) switch (lcdDrawUpdate) {
         case LCDVIEW_CALL_NO_REDRAW:
           refresh(LCDVIEW_NONE);
@@ -1025,11 +1025,11 @@ void MarlinUI::update() {
           first_page = false;
 
           // The screen handler can clear drawing_screen for an action that changes the screen.
           // If still drawing and there's another page, update max-time and return now.
           // The nextPage will already be set up on the next call.
-          if (drawing_screen && (drawing_screen = u8g.nextPage())) {
+          if (on_status_screen() && drawing_screen && (drawing_screen = u8g.nextPage())) {
             NOLESS(max_display_update_time, millis() - ms);
             return;
           }
         }
 
@@ -1043,11 +1043,11 @@ void MarlinUI::update() {
         lcd_clicked = false;
       #endif
 
       // Keeping track of the longest time for an individual LCD update.
       // Used to do screen throttling when the planner starts to fill up.
-      NOLESS(max_display_update_time, millis() - ms);
+      if (on_status_screen()) NOLESS(max_display_update_time, millis() - ms);
     }
 
     #if HAS_LCD_MENU && LCD_TIMEOUT_TO_STATUS
       // Return to Status Screen after a timeout
       if (on_status_screen() || defer_return_to_status)

```
could help, as long the screen is not changed during `run_current_screen()`.
(I'm currently again far away from any hardware to test.)

[Kaween-prog]

Thank you for chiming in and looking into the subject. Print still running, will try ASAP unless somebody beats me to it.

[stefi01]

sometimes when i pause a print using park feature, after i press to continue printing the lcd goes blank, the print carrys on ok but just blank screen, other funtions through lcd i can use without the lcd going blank,and other times the screen becomes unresponsive when i try bring up the menu but does not go blank its a smart discount lcd and this problem does not always happen when i pause a print about 50/50, i tried changing buffer size to 32 from 16 but that just makes the screen blank from start up
marlin_2.0_rambo.zip

[karabas2011]

and when you eject the sdcard image immediatly appears. I set buffer 64

[AnHardt]

If printing from SD and removing the card the buffer is dry after a short moment. Buffer dry is the second criteria to allow display updates. (no movement -> no stuttering) (Try during diagonal infill and observe a longer delay until display updates.)

[Kaween-prog]

Well, I implemented the changes Anhardt suggested (the 3 lines) in ultralcd.cpp

The result is "kinda different than hoped". :D

The info screen is shown, seeming normal. When pressing the rotary selector to enter a menu,
the LCD now becomes totally unresponsive and stuck on the Main Info screen. No way to select any submenu, pressing the rotary does sound the "beep" of the keypress, and then freezes for 25 seconds.

When "released", rotating the encoder does change the Fr speed indicator (100%) correctly, the XYZ positions are changing between a "???" and "0" ever second.

That is, untill you PRESS the encoder button again.
When you do, the XYZ indicator freezes again, the menu stays in the main info screen in a frozen state, and remains static again for 25 seconds.

The LCD RELEASES after 25 seconds allowing the rotary to change the speed Fr indicator again.

Not possible to get out of the main info screen, not able to enter any other menu.

I fully appriciate the efforts, Anhardt. I know full well how hard it is to do stuff like this when being away from the equipment. I'm sure you'll be able to crack this nut when you got your stuff available for testing.

[stefi01]

i tried the changes too, also went blank and then yesturday i tried the new bugfix that was released 9th october and the lcd refused to even come on when the printer started and the buzzer started randomly buzzing and the motors went nuts, i thought the blody thing was haunted haha, i had to put 1.1.9 back on to fix it

[thinkyhead]

i thought the blody thing was haunted

That can happen sometimes. We've been doing a lot of cleanup and refactoring, and typos have been known to fall in even after testing. It may help to enable the EEPROM_AUTO_INIT option, just in case bad EEPROM data is preventing a proper boot.

[stefi01]

i wiped eproom, enabled auto init, re-uploaded firmware, wiped eprom yet again, now the 2004 just freezes after a while again plus now ubl leveling probing fails lol

[Kaween-prog]

I would start to suspect the display throttling is having some unwanted side effects. Not implying there's something wrong with the code itself, but it seems very much as if these issues are starting to escalate ever since thinkyhead asked to reactivate the display throttle system.

Is there an easy "disable" flag for this feature ? Just for debugging purposes or to exclude/pinpoint issues, as I fully understand and agree with the principle behind it.

[Ugars]

Hi,

I updated my main board with skr mini e3 (with TMC2209) on my Ender-3 today, I downloaded latest marlin 2.0.bugfix and compiled it. I tried a filament change (by Cura) and same thing written on this topic applied.

Filament changed and print continued but LCD stuck on "wait for print to resume" screen, after couple of minutes it came back to info screen but this time knob didn't give any response for a minute, then I got some response from the knob but it halted on a random menu screen, waited for less then a minute it returned to info screen again but responsiveness and randomly locking/halting of the menu continued.

I'm no expert on these kind of issues and I don't have time to deal with them, can I flash 1.1.9 to the new board (is it compatible)?

[Kaween-prog]

No. Not possible.

[Ugars]

No. Not possible.

Flashed the firmware from SKR's github, no issues for now. Posting this just for information.

[Kaween-prog]

Well, I'd hope so. But that's not a 1.1.9. :) (hence the "no not possible" response : you asked if you can flash 1.1.9 inside an SKR board).

[boelle]

Flashed the firmware from SKR's github, no issues for now. Posting this just for information.

not cool to push people off to a fork, would be better to compare and point out the problem

[boelle]

@Kaween-prog i assume this is still an issue?

[Ugars]

Flashed the firmware from SKR's github, no issues for now. Posting this just for information.

not cool to push people off to a fork, would be better to compare and point out the problem

I'm not pushing anyone to a fork, I just gave information about my quick fix until the real problem solved!

[Kaween-prog]

@boelle : yes, it is.

[thinkyhead]

See if the recent merge of 15837 helps.

[thinkyhead]

I'm not pushing anyone to a fork, I just gave information about my quick fix

No worries. "Pushing to a fork" is not something we actually worry about. Some forks may be better!

[boelle]

@Kaween-prog did merge of 15387 help?

[boelle]

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.

[Kaween-prog]

Well, the issue is "solved" in the way the issue itself is resolved (meaning, the delay period between actual resume and the display status" in the new buids is now gone).

HOWEVER, the new builds re-created the existing issue of the "motors running very jerky, destroying print quality on a Delta when using RepRapDiscountFullGraph displays" to the point where the print quality is totally unusable.

So "solved" is a matter of opinion.

As I understand it, the problem started out with the "motor running very jerky" status.
Then, measure were taken to resolve or at least fix that.
Those measures resulted in display update issues.
Repairing the display issues breaks the smooth movement of the motors again .... :(

It's like this jerk movement issue on Delta's simply can't get solved on Marlin in a correct manner ? It has been first reported sometime in 2018, and so far there's not been a real solid fix to the issue : either the solutions break another function, or they don't fix the initial problem.

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