Marlin: [BUG-CONFIRMED] Lcd gcode command + SDPrint = Printer freeze/stuck - BUGFIX 2.0

[studiodyne]

Hi , after installing the current bugfix 2.0 , can you please start a sd print , go to lcd menu and ' change filament ' , if the printer freeze , please report confirmation here. Or anything that use lcd_enqueue_one function

No bug on bugfix 2.0 version of 2020 03 19

Thks

[BaBBa71]

Confirmed.
I started the printing, chosen from the menu the CHANGE FILAMENT option, after choosing the extruder, the printer stuck.

[studiodyne]

Confirmed.
I started the printing, chosen from the menu the CHANGE FILAMENT option, after choosing the extruder, the printer stuck.

Thk you very much

[swilkens]

Seems to be fine on 2.0.5.3 - it stopped the print, moved the head and started retracting the filament, then asked me to feed new filament - no problems.

[Roxy-3D]

Do we have a commit we can look at and see the change that fixed this?

The reason I'm asking is I've got a 5 day old copy of Marlin Bugfix v2.0.5. I just had the printer freeze while trying to do a filament change while printing from the SD-Card. The trouble report is here: https://github.com/MarlinFirmware/Marlin/issues/17442

[studiodyne]

Do we have a commit we can look at and see the change that fixed this?

The reason I'm asking is I've got a 5 day old copy of Marlin Bugfix v2.0.5. I just had the printer freeze while trying to do a filament change while printing from the SD-Card. The trouble report is here: #17442

No bug on bugfix 2.0 version of 2020 03 19

[studiodyne]

Seems to be fine on 2.0.5.3 - it stopped the print, moved the head and started retracting the filament, then asked me to feed new filament - no problems.

In the 2.0 release , all is right , but in bugfix 2.0 since 2020 03 19 , the issue appears

[Roxy-3D]

That isn't that big of a time window... That shouldn't be too hard to isolate.
We probably should revert what ever Pull Request is causing the problem and have a discussion about what the author was trying to accomplish.

[studiodyne]

The starting point is 2020 03 19 , we must compile each commit and try it , to find the break or wait the author wake up 👍

[Roxy-3D]

If we can find the commit that broke things... It shouldn't be too hard to figure out what is wrong with it and get it fixed.

[thinkyhead]

I'm taking the approach of just delving directly into lcd_enqueue_one to see where it's losing the plot. I'd planned to do this 2 days ago but… stuff.

[thinkyhead]

Before I dive in, I think one thing that it could be is that the G-code buffering from SD used to always leave one space in the buffer so that we could get an immediate command in there. It might no longer be leaving that space, and that might mean the buffer is always full during an SD print. So while the "inject" functions will work in the LCD menu, functions that want to wait for a space in the queue will get stuck waiting.

A theory to check….

[thinkyhead]

Here's a hint: The next command in the queue is only processed when the firmware returns back to loop. Anything that calls idle in a loop suspends G-code processing, so the buffer can't empty.

One solution is to advance the buffer and process the command before calling idle (which handles the UI). This ensures the buffer will have at least one space empty when the UI is processing.

Another solution is to always leave an empty space in the buffer when gathering commands from serial and SD. Generally speaking, if one or two empty spaces are always maintained for use by internal stuff then there should be few or no blocking problems in future.

[studiodyne]

It's a good theory , the bug appears only on printing , not when stopped , because buffer is full , and the ' do while ' that waits enqueue return can loop forever.
And .... If i send the command by the serial , while sd printing , it works.... because at the end .

[Roxy-3D]

Don't worry @studiodyne This is a pretty obvious bug. Somebody will find the root cause and fix it pretty soon. I suspect Thinky is right that the buffer doesn't have room to insert the command, and in my case (with the filament change) if idle() isn't looping taking commands out of the buffer... well, the code is locked up and can't ever insert the needed commands. So the machine hangs.

[studiodyne]

I have my old version that works fine , i have the time 👍

[Roxy-3D]

Another solution is to always leave an empty space in the buffer when gathering commands from serial and SD. Generally speaking, if one or two empty spaces are always maintained for use by internal stuff then there should be few or no blocking problems in future.

Certainly in the case of printing from the SD-Card... Leaving an open slot in the buffer is not a big deal. The SD-Card can read GCode commands so fast that the full buffer depth isn't needed to keep smooth operation.

[thinkyhead]

The buffer can still get clogged, such as when the buffer is nearly full and a long move is going for a while, and during this time you press the LCD button a few times to insert commands…. same problem. So I've added an extra (SRAM) injection buffer in the PR linked above.

[studiodyne]

I will try it tomorrow

Admiration , nothing else to say !

[studiodyne]

WORKS PERFECT !
Thk you very much

👍 you can merge tool migration 😄 , i've all updated and tested

[studiodyne]

@thinkyhead
Please can you explain me , in my account there is an issue , i've given you a video of the bug , of the bad z axis resume on tool change , i juste have one question , why single nozzle disabled ?
Why ' SINGLE NOZZLE ' is disabled and other configuration not ?
I have deleted '&& DISABLED(SINGLENOZZLE) all works fine

#if HAS_LEVELING       // && DISABLED(SINGLENOZZLE)  <------- ?????                   
   // Set current position to the physical position
   TEMPORARY_BED_LEVELING_STATE(false);
#endif

[Roxy-3D]

@studiodyne Can you do a quick check and see if the filament change while printing from an SD-Card works now too?

[studiodyne]

Test ok , tool change , tool migration , filament change

[Roxy-3D]

Thank You!!!

Closing the other issue now...

[github-actions[bot]]

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.