If i level the Bed with G29, the LCD stil says "Printing" and it shows only the printing menu items.
While in Octoprint i can start a print w/o problems.
This is my level code in octoprint Bed VIsualizer which i use to level.
M190 S70 ;wait for heat
M155 S30 ;lower temp reports
G28 ;home
G29 T ;ABL
M500 ;save mesh
M501 ;load mesh
M155 S3 ;default temp report
M140 S0 ;stop heating
Expected behavior:
Printer LCD shows Non-Printing Mode menu
Actual behavior:
Printer LCD shows Printing Mode menu
2.0.x-bugfix
Config:
https://github.com/reloxx13/Marlin/tree/my-marlin/Marlin
@reloxx13 is this still a problem?
yes
thinking of this, does it only happen when printing/leveling from octoprint?
@boelle yes, in my case, it is the only way I see it happen as the levelling is in the start of any job, right in the gcode.
i print from octoprint also but i dont do level before each print, only when print shows its needed
i have #define RESTORE_LEVELING_AFTER_G28 and the only thing i need to check on LCD is that bed level is enabled, if it says off i just click that to make it say on
normally i only do this after i power up the printer and after a disconnect,
and even if i home its enabled, doing level before each print is kind of overkill,
but this does not mean that there is not a bug, its just to figure out if its a problem with marlin or octoprint
yes, i use octoprint.
i only level if needed with bed level visualation tool.
yes, still happens, had it again few days ago.
sometimes i level and want to change filament afterwards oder move z up to clean the bed and i cannot cause it stays in print mode (print mode menu and status text "printing").
had this again a few days ago.
@reloxx13 dusting off this one, is the issue still there?
+
and that means?
positive :D
oki, a shame its still there :-(
is the issue still the same with all the updates in the last 43 days?
btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible
there were leveling changes last days and ill have to re-test.
oki. looking forward to that :-D
@reloxx13 did you retest?
still happening.
e.g. menu shows stop/pause sd print, but printer is idling after bed leveling.
load/unload text is also switched,
load shows text for unload, unload shows text for load, since months.
german fw latest bugfix 2.0.x from today.
i wont answer any further questions if its fixed or not. ask the devs or tell em to properly use git and #issue id in commits.
If you don't plan to be involved in the solution it's likely it won't be fixed unless someone else with the same issue gets involved to sort it out. I personally can't reduced this issue.
@reloxx13 i agree here, you are the only one with this issue so far, i cant reproduce it either and tried many times but it works every single time
and you last 2 lines of comment are kind of uncalled for and belongs to where i call it "nasty"
last 2 lines of comment are kind of uncalled for
Well to be fair, this issue has lingered a long time without a single human capable of investigation coming along to look into it. We could really use more initiative in that area. It can't all fall to me.
@reloxx13 — At a glance, the problem seems to be that you might need M104 S0 (after M140 S0) at the end of your script. Please confirm if this helps!
@reloxx13 —
Ach, that last suggestion is sensible, but you deserve more detail. So here's what I can tell you:
G29 bed leveling.So, if M104 S0 doesn't solve it, see if it helps to add M77 to the end of your script.
It also might help to add M117 to the end of your script, after that.
If these don't do the trick, we can look further.
To remedy this (for future Marlins and beyond) we should take account of bed heating and not just hot-end heating in our evaluation of print job start and stop. Contribs wanting to have a go at this patch should look for PRINTJOB_TIMER_AUTOSTART in M104_M109.cpp and contrast with M140_M190.cpp.
strange as i used a script for UBL on both octoprint and pronterface and it does not produce this effect. i did have it turn off the heat at the end might be why.
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.