Using Marlin 2.0.5.x 32bit on a MKS SGENL V2 mainboard.
OctoPrint Version 1.4.2
I have M600 in my gCode on Layer 50
The printer pauses, moves the head to the park position and retracts the filament.
I put in the new filament but cannot initiate a Load or Resume the print.
The Control Tab is completely Greyed out and the Terminal Tabs just shows:
"echo:busy: paused for user"
What did you already try to solve it?
Googled and Googled.
Found one page in this forum that talked about enabling these lines in configuration_adv.h
And that enables the "ACTION_ON_PAUSE" commands now found in host_actions.h
But now...
When I start a print, the bed heats up and then OctoPi switches the Print button to a RED "Restart" button and the Pause button changes to 'Resume'
Once I click on 'Resume' it finishing heating the hot-end and then starts printing.
Then when it gets to the M600 in the GCode, the printer pauses and retracts the filament, but the "Print" button in OctoPi is still depressed, and Pause and Cancel buttons are grayed out as are all the controls on the 'Control' tab
And the Terminal tab just shows:
Recv: echo:busy: paused for user
Recv: echo:busy: paused for user
[...]
Recv: echo:busy: paused for user
[...]
Recv: echo:Press button to heat nozzle
Recv: echo:busy: paused for user
[...]
And the hot-end shuts off because I can't do a dam thing...
I think there was a bug on Marlin side that doesn't send the necessary to host command to OctoPrint to automatically resume when you press the buttons. If I remember correctly someone had submitted a PR to resolve that already, so might be in Marlin Bugfix branch.
I found this, but it refers to the M600 event being trigger due to the filament sensor detecting end of filament. And it was closed due to inactivity with no resolution:
That's a possibility. And it looks like it's in 2.0.6, but I have 2.0.5 from the makerbase fork as support for the mks sgenl V2 is not yet in the Marlin main branch. A PR was submitted, but not yet integrated.
So I'm going to patch my version with those changes and see if it helps.
Nope. That change is already in my code. Looks like MakerBase has been keeping their fork up-to-date. So that fix, being already implemented, doesn't affect this issue.