Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print from layer #1197

Closed
wants to merge 3 commits into from
Closed

Print from layer #1197

wants to merge 3 commits into from

Conversation

volconst
Copy link
Collaborator

@volconst volconst commented Jun 1, 2021

Implements #383
Not tested on real printer. Please post feedback
See individual comments
@andreaskielkopf , @kliment ?

volconst added 3 commits May 31, 2021 22:32
Implement resuming a print from a user selected layer.
There is no requirement that the print has been paused or started
in the current pronterface session.
The command is accessed through menu Advanced -> Print from layer.
The layer selection is done with the slider in the standalone 3D view
window, which is opened on double click in the embeded 3D viewer.
The printer is initialized by filtering some commands in the skipped
lines.
The last (top) visible layer in the stanalone 3D viewer will be printed,
so you have to slide to the lower layer to compare visually the printed
object with the 3D visualization and then slide up to select the to be
printed layer.
The Z value in the 3D viewer status should be the same as the first sent
gcode commands.
The layer numbering in this commit does not coincide with the gcode
comments, fixed in the next commit.
The starting commands are shown for confirmation.
The code is not tested on real printer, just with
 ./testtools/mock-printer.
The layer numbers shown in the standalone 3D view now match the
numbering in Slic3r 1.3.0, Cura_SteamEngine 4.6.1 gcode comments.
Gcode comments start with layer 0 and the first command in the layer is
G1 Z...
The printrun parser layer 0 starts at line 0 with whatever content.
Layer numbering may be consistent or not
depending on slicer, retraction, Z hop, etc.
@kliment
Copy link
Owner

kliment commented Jul 31, 2021

@VanessaE can you try this out and see if it works for you?

@VanessaE
Copy link
Contributor

VanessaE commented Aug 3, 2021

I started a print, then after a while, I killed it by unplugging USB (this seemed like the best way and the most likely use-case for this feature i.e. a connection failure). Naturally, Pronterface didn't like that, but it didn't blow up. 😁

I reconnected, jogged the nozzle off the print, then went to Advanced -> Print From Layer. The program popped up a mini 3D view asking me to select a layer to resume from. I clicked around and adjusted the view until it was set for where I killed the print, then closed the dialog with the window manager's [X] button.

I was then left in the usual Pronterface display with the printer still idle -- that is to say, the mini 3D view dialog seemed to do nothing useful... yet.

I then tried to go back in there to double-check things, but this time, instead of showing me the mini 3D view, the program popped up a confirmation dialog asking me if the new start commands are correct.

If I click OK on that confirmation dialog, it begins printing. If I click Cancel, it simply closes that dialog (though I wasn't expecting anything else).

The print did resume from the proper point. There was a slight artifact at the resume point, but nothing that anyone would complain about, and most likely the result of the nozzle running over a small blob that was left on the print from when I initially stopped it.

My impressions:

  • The mini 3D view needs a "Confirm" or "Okay" button, even if it seems redundant. Relying on the window manager's [X] button to finish the layer select step is probably not good UX, as most people would probably interpret that action as equivalent to pressing Esc, i.e. to cancel.

  • I would have expected that start g-code confirmation dialog to show after closing the mini 3D view.

  • There appears to be no obvious way to get back to the mini 3D view once I've been presented with that confirmation dialog -- whether I cancel or resume the print, even if I clear the build plate and restart the print from scratch. Each time I try to get back in, it just presents me with the confirmation dialog again. I have to close Pronterface and restart to get access to the mini 3D view again.

  • The commands presented to me were correct for the most part, but they need G28 XY also, just in case the X/Y motors have powered-down at some point before resuming or if the user has pushed things around. Of course, you'd only include this command if there's a G28 of some form in the original file. Is it possible to query the firmware to see if it's unsure of its location?

    If G28 XY is added as above, then you'll need to check if an M420 variant is present in the original file and include that command after the G28, as some firmwares do not re-enable bed leveling after homing.

  • When the printer gets disconnected as in this test, you should not erase the status line. Or at the very least, replace the normal contents with the layer number, Z height, and other pertinent info, and include some message warning that the print was stopped there.

  • When showing the mini 3D view, it may be a good idea to automatically pan/zoom/rotate the camera to something comparable to the main 3D view. Since the program already shows where the print died (by the red/green split in the mini 3D view's g-code preview), it's probably a good idea to just automatically put the height at that point. The user can always fine-tune up or down from there.

  • Some reasonable way of purging the nozzle when resuming the print would be a good idea. The user would definitely need to define a set of commands for this. The user could perhaps define these commands into a normal macro as used in the custom buttons at the bottom of the window, and call upon this macro when resuming the print.

    For example, the printer could home X/Y, move the nozzle so that it's over a purge bucket, extrude say 50mm, and dwell for a second or two so that the user can snatch the dangling plastic (and then start printing).

    With that in mind, I would suggest redoing the buttons in the g-code confirmation dialog: "Cancel" to abort, "Print" to continue the print with the commands shown in the dialog, and "Purge and Print" to continue the print, appending the purge commands/macro after the new start g-code.


Here's the file I was testing with: BookCover_WithSeam.stl.zip

And here's the g-code, generated by Slic3r (SuperSlicer): BookCover_WithSeam.gcode.zip

Notes:

I git pull'ed Pronterface to HEAD before applying this PR, which was right before writing this, so I'm pretty sure things are current/up-to-date.

I am using Debian 11.0, desktop environment is XFCE 4.16.

@kliment
Copy link
Owner

kliment commented Aug 3, 2021

I have to say, this is the best test report I've ever seen. Thanks @VanessaE this is gold!

@volconst
Copy link
Collaborator Author

volconst commented Aug 3, 2021

@VanessaE , thank you for your time.

I killed it by unplugging USB (this seemed like the best way and the most likely use-case for this feature i.e. a connection failure).

When I coded the "Print from layer" disconnect was not the main scenario. For disconnect the other menu entry "Recover" should be used. I don't know whether it works.
"Print from layer" is intended to be more generic with less assumptions and magic, hence hopefully more robust.

then closed the dialog with the window manager's [X] button

You do not have to close it. The standalone view is an old feature and is opened with double click.

the mini 3D view dialog seemed to do nothing useful... yet

The standalone 3D view utility is to provide the slider. I understand that guiding the user with wizard like experience may be a good thing, but I did not want to change too much the current state without having it first discussed, b/c this risks that the PR is rejected. Because there are less assumptions, the user is having the lead.

  • The mini 3D view needs a "Confirm" or "Okay" button

Stand alone viewer is not dedicated to "Print from layer". Probably this is like GIMP - you have many tools, but it is up to you how you use them.

  • There appears to be no obvious way to get back to the mini 3D view

Yes, it is not obvious, you have to double click the embedded view - old feature.

  • but they need G28 XY also, just in case the X/Y motors have powered-down

I had one assumption though, and it is that the resume is just skipping some lines from the original file. The assumption is if G28 is needed in the resume, then it is needed in the file, thus delegating responsibility to the file creator. I think 'Resuming is skipping' is a good contract. Short and clear, who reads contracts anyway.
Do you have scenario in which the file correctly does not contain G28, M420, but the resume needs them? Or is pronterface erroneously skipping them?

The other ideas are probably good too, it's hard for me to evaluate how much they will be used - this PR did not get much attention for 2 months. Not much compared with the exactly 8 years from issue to PR :)

@VanessaE
Copy link
Contributor

VanessaE commented Aug 4, 2021

For disconnect the other menu entry "Recover" should be used. I don't know whether it works.

I wasn't aware that feature existed at all. I didn't even notice the menu item until this print-from-layer feature came up (I rarely use the menu at all).

You do not have to close it. The standalone view is an old feature and is opened with double click.

The standalone 3D view utility is to provide the slider

Fair enough, but the user isn't asking for the standalone view, they're asking for the print-from-layer feature, and if I'm being a little blunt, they aren't going to care what the dialog they're presented with was originally used for, let alone how else it can be called-forth.

Maybe you could make the "Print from layer" menu item always show the standalone view (and never the confirm dialog), and add the "Okay" button only if that's how the dialog was summoned (omitting it otherwise).

I mean, the user still needs to be presented with the confirm dialog at some point, so that they can actually start the print, and the most obvious way to get it would be an "Okay" button in the standalone view.

Besides all of that, most people don't have the screen space to leave random dialogs open without either burying or minimizing them -- I assume most makers control their printer via a laptop or a common PC with only a single, moderately-sized monitor.

Do you have scenario in which the file correctly does not contain G28, M420, but the resume needs them? Or is pronterface erroneously skipping them?

I'm suggesting that Pronterface is erroneously omitting them. The g-code file I provided has both commands, but neither was present in the g-code shown in the confirm dialog.

If the printer's motors have powered down due to idle timeout (default 2 minutes on Marlin, iirc), then when the time comes to resume, the motors' positions can't be guaranteed, so the printer will have to home X/Y before resuming the print. If it has to home, there's good chance that bed leveling will get turned off. That's firmware-dependent of course, but I know for sure that at least a full X/Y/Z home turns off bed leveling on my printers (I've never checked if X/Y-only homing does so also).

Or, consider the situation where, for whatever reason, the user has paused the print, turned the printer off, and pushed the nozzle off to one side by hand (to get it away from the print), with intent to continue the print later. On power-up, the printer will have no idea where it is, and bed leveling will definitely be turned off at that point.

So, if the file contains a G28 command, I think it's best to always home X/Y and restore bed leveling if applicable, when resuming.

If the file doesn't have it, you can assume the user has some weird setup 😁 that they home manually prior to printing, and/or that won't lose position between sessions.

@volconst
Copy link
Collaborator Author

volconst commented Aug 4, 2021

Maybe you could make the "Print from layer" menu item always show the standalone view (and never the confirm dialog), and add the "Okay" button only if that's how the dialog was summoned (omitting it otherwise).

I see you insist on a wizard like, stateful experience. I do not like wizards, they are too linear, constraining and require additional coding 😁 . Let's first make the feature usable by experts, and then by newbies if ever.
I agree that the (hidden) double click invocation of standalone 3D viewer is bad, and the easiest fix I see is to add a menu item "Select Layer" before "Print from Layer". This way, by adding menu items we are kind of implementing poor man wizard 😁

I mean, the user still needs to be presented with the confirm dialog at some point, so that they can actually start the print, and the most obvious way to get it would be an "Okay" button in the standalone view.

After rethinking several times I would agree that adding a button to 3d viewer (if invoked from "Print from layer") is a good trade off between effort and utility. Indeed, the layer is the most critical parameter of the feature, so it makes sense that 3D viewer is the central control that starts the print. The button should not read "Okay", but "Print from layer". But I consider this lower prio, UI enhancement.

I'm suggesting that Pronterface is erroneously omitting them. The g-code file I provided has both commands, but neither was present in the g-code shown in the confirm dialog.

Ok, today I tested it. What should the sequence be? G0 <layer_z>; G28 O L X Y ?
Is it safe to home at layer z or some offset should be added?
Is there a gcode command to check whether motors were off? Maybe G28 O does just that?
Is there a gcode command to check whether Z was homed after power on? If we are unsure maybe show a dialog instructing the user to home manually.
The M420 seems to be the same as G28 L ? Which is better supported?
Showing the start commands is very good idea, kind of disclaimer for any missing/present commands 😄

@kliment I would like to see your thoughts also about the UI and commands.

@VanessaE
Copy link
Contributor

VanessaE commented Aug 4, 2021

I see you insist on a wizard like, stateful experience. I do not like wizards, they are too linear,

"Wizard-like"? definitely not. I hate wizards, they make too many assumptions that don't always work out (or which I end up having to override later anyways).

(I have no love for warlocks, sorcerers, or magicians either 😛).

My suggestion is linear, sure, but what other logical way is there to go here? Starting with a print that's stopped, the user selects "print from layer", sets a start position in the standalone view, clicks "Okay" (twice), and off it goes printing.

Ok, today I tested it. What should the sequence be? G0 <layer_z>; G28 O L X Y ?
Is it safe to home at layer z or some offset should be added?

I would suggest raising the Z position by a few millimeters before homing X/Y. If you don't raise, then the nozzle may scrape across the print. My printer's firmware automatically does this (for the purpose of avoiding the Z probe potentially hitting something), but others might not.

Is there a gcode command to check whether motors were off? Maybe G28 O does just that?

I just checked, and for me at least, G28 O homes what needs homed, and that's the end of it. But if for example I home X, then immediately send G28 O X Y, the O flag is ignored and the machine homes X again even though it shouldn't need to, in addition to homing Y (which was needed).

In any case, the firmware produces no console output regarding what axes were homed or skipped, and I think those extra flags would be too firmware-dependent to rely on.

Is there a gcode command to check whether Z was homed after power on? If we are unsure maybe show a dialog instructing the user to home manually.

No idea there. The firmware clearly shows this on the printer's LCD (by alternating between a bogus coordinate and "?"), but I don't know if there's any generic way to get that info from the printer.

I checked M114, but it does not show when axes are unknown.

You could send M122 S0, and parse the "Enabled" line in the debug spew, looking for "true" fields indicating if a particular motor is powered, but that only works on machines with Trinamic drivers, and I guess most folks are still hanging out in the A4988/DRV8825 slums. 😄

The M420 seems to be the same as G28 L ? Which is better supported?

Offhand I would say M420 is more supported, or certainly more familiar, but note that M420 just switches leveling on/off (or switches between different saved profiles), without any motion.

On my particular firmware build, G28 L does not re-enable bed leveling after homing, but as I said, that's disabled in my config (it used to not work at all in the past, and I never got around to re-checking it).

Showing the start commands is very good idea, kind of disclaimer for any missing/present commands

That reminds me, I forgot until just now to mention this: you also need to find and re-use the last fan control (M106, M107) and acceleration/jerk (M201, M204, M205) commands prior to the new restart point. The g-code I attached earlier has multiple M106 and M204 commands in it, but nothing related was shown in the confirm dialog.

@andreaskielkopf
Copy link

I have not visited github for nearly 6 month. And i am impressed!
As soon as possible i will try to test this with my own printer.

My problem with the printer where no disconnects, but:

  • running out of PLA
  • clogging of the nozzle
    So the status of printrun did proceed further, because it did not notice the problem.
    May be an hour later i did notice the printer is only printing air :-(

@volconst
Copy link
Collaborator Author

volconst commented Jan 4, 2022

@andreaskielkopf ,
You can try it, but this version is somewhat obsolete.
I took note from VanessaE comments, and then changed the workflow.
The new version is not complete, not published and ... somewhat abandoned.
I do not remember the details.
Instead of showing a dialog confirming or rejecting all lines, I decided that there should be a debugger like editor with step, skip, repeat buttons and the proposed commands should be mixed with instructions for the operator in comments.
The rationale is that some lines may need editing or skipped.
I think this is a very cool feature, but see no demand for it, probably is implemented elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants