[FR] Cancel object functionality

[MarcPot]

Recently I went over to Mainsail from Octoprint and it works great! Big improvement in combination with Klipper. The only feature I’m really missing now is the “Cancel Object” functionality. So this issue is a feature request to ask for this feature.

I already talked to the Mainsail and Moonrakers devs and they told me that this is a Klipper thing, not a Mainsail/Moonraker thing.

[klipper-gitissuebot]

Hi @MarcPot,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Arksine]

FWIW, this is going to require support from both Mainsail and Klipper. Mainsail needs a gcode viewer for this kind of functionality to be useful. I have plans to add support for exclude region in the future, but I don't have a definitive timeline.

[MarcPot]

Well sure for the exclude region kind of functionality, but I think most people should be fine with a simple (string) list of objects and then the option to click cancel next to the object.

I just use superslicer so I don’t know about other slicers, but superslicer has the function to define objects.

[OldCurmudgeon3DP]

Both Region and Object exclusion are done with Octoprint plugins and don't care about your firmware. I've used both on Marlin and Klipper. Mainsail should be the one responsible for the function if it's even remotely similar to Octoprint in that it just feeds gcode to the firmware. I'm probably talking out of turn as I have only hear Mainsail in passing. (off to do some research now)

[MarcPot]

Both Region and Object exclusion are done with Octoprint plugins and don't care about your firmware. I've used both on Marlin and Klipper. Mainsail should be the one responsible for the function if it's even remotely similar to Octoprint in that it just feeds gcode to the firmware. I'm probably talking out of turn as I have only hear Mainsail in passing. (off to do some research now)

Mainsail and Moonraker are just a webinterface and a webinterface api, it doesn't actually do anything with the Gcode, that's handled by Klipper and the reason it has to be integrated into Klipper.

[Arksine]

Both Region and Object exclusion are done with Octoprint plugins and don't care about your firmware. I've used both on Marlin and Klipper. Mainsail should be the one responsible for the function if it's even remotely similar to Octoprint in that it just feeds gcode to the firmware. I'm probably talking out of turn as I have only hear Mainsail in passing. (off to do some research now)

Moonraker (the backend) does not directly parse gcode files like Octoprint. Instead it exposes APIs with which clients (such as Mainsail) can access Klipper's virtual_sdcard functionality. Octoprint's gcode parser allows plugins like Exclude Region and Cancel Object to intercept gcode commands and exclude them if they fall within an excluded area. The downside to this that there is additional overhead from the gcode processing. Moonraker has very little overhead, thus it can conceivably run together with Klipper on a Pi Zero.

Fortunately Klipper's own gcode parser exposes APIs with which we can transform gcode commands. Writing an extras module to exclude an area/object wont be that difficult outside of dealing with retractions. However I still believe that without a UI using these kinds of modules would be an exercise in frustration. Consider a plate 10 copies of an object, where one object fails. A simple list of objects is probably not going to be good enough for a user to know which object they need to cancel.

I would concede that a full gcode visualizer probably isn't necessary for a usable "cancel object" UI. The object metadata includes bounding coordinates, so a simple UI with selectable "boxes" would probably be good enough for cancel object.

[OldCurmudgeon3DP]

Yeah, I should have looked up the other gits before hitting the keyboard here. facepalm

[BlackStump]

I personally like the fact that Klipper-Moonraker and Mainsail is that efficient to can be run on a Pi Zero.

What I would not want to see is Klipper-Moonraker-Mainsail loose that efficiency to become Octoslow's cousin.
People who want all the bells and whistles multiple useless plugins have a option and it is Octoprint.

I would hope if any addition features are implemented in Moonraker-Mainsail that they include the option to disable them if not required and-or they have a overhead burden.

I never quite got the gcode visualizer, I load a model into the slicer, I slice it and name it appropriately so I know exactly what it is by the name, why do I need to see it again in mainsail. I do not use superslicer but there thumbnails seem like a good option for people that want to visualizer their gcode otherwise drop it back into the slicer that is it's job.

I am a function over form person. efficiency first. Of course my post can be totally disregarded as it is purely my personal opinion.

[Hywelmartin]

If objects are defined in the slicer( assume every row??).. then its just a wait for the object that should be cancelled is getting printed.. no graphical UI is needed, more than a button that cancels the ongoing object

edit start/end of every object is stated

E0.13912
M204 S5000
; stop printing object nanny_PP v1.stl id:0 copy 5
; printing object nanny_PP v1.stl id:0 copy 2
G1 E-0.75000 F1800.00000
G1 F24000.000

[randellhodges]

I think you'd need tie into the virtual sdcard code to implement this. How would you expect this to work? I might take a stab at it in my free time.

When the file is loaded with M23, should it, at that time, scan the file and find/output a list of found objects, or, would you want another command to be executed to do that?

If you went the 2nd way, the flow would be something like (command names to be determined)

M23 file.gcode
LIST_OBJECTS
-> 0:object_1
-> 1:object_2
M24
CANCEL_OBJECT NAME=object_1
or maybe
CANCEL_OBJECT ID=0

I'm thinking the LIST_OBJECTS (or the M23 when loaded) would scan the file and build a dictionary/position of objects in the file. Klipper would then keep track of which object is currently printing. When you request to cancel it would mark that object as cancelled and then when the layer is complete, the next time it "enters the object" it would skip lines until it gets to the next, non-cancelled object.

Would it be assumed you could ignore every command "between" the objects?

I haven't dug thru the code yet, but, could an extras module access the gcode that was loaded by M23, or would the virtual_sd module need to expose/provide access to the new extras module?

I'm thinking maybe these 2 raise an event. Then then the cancel object (or any others I guess) could listen and respond:

gcode._process_commands: for each command, it raises the event, then if the responded says to ignore then the command is skipped:

virtual_sdcard._load_file: passes the file handler over in an event and lets others read from it

Maybe I'm overcomplicating it, but that gives a way to have these talk together w/o hard coupling them together

[Arksine]

@BlackStump This would be completely optional. That said, I think its implementation would be reasonably efficient and wouldn't add much overhead.

If objects are defined in the slicer( assume every row??).. then its just a wait for the object that should be cancelled is getting printed.. no graphical UI is needed, more than a button that cancels the ongoing object

This could be possible, but lookahead might cause some issues with this approach. Cancel an object too late and it will cancel the wrong one.

I think you'd need tie into the virtual sdcard code to implement this. How would you expect this to work? I might take a stab at it in my free time.

I don't plan to make any changes to the virtual sdcard. While Moonraker does not process gcode files in realtime, it does have a metadata parser that analyzes each file when its uploaded. It won't be a problem to extend it to extract Object headers.

For the real time processing, Klipper's gcode.py checks for comments and ignores them. We just need to add a hook there so the "cancel_object" module can determine if the comment contains an object identifier. In addition to this, we can register a move transform that will "skip" moves if a canceled object/region is detected. The tricky part is handling retractions and detractions. Additional logic will be necessary to ensure that neither is done consecutively.

[MarcPot]

What Arksine said is completely true, just a list of components would probably not be enough, but a list of components with a bounding box as position indicator would probably be enough in 99% of the cases.

Insert this functionality with a [cancel_object] in your printer.cfg would just add this function when you ask for it so it deals with the slowness, but I fail to grasp why this function would be cpu intensive since you just have to skip a few lines?

When Superslicer makes a gcode file every part will be done separately every layer (after layer 1).
When the last part of the line is laid Superslicer inserts a

; printing object Shape-Box id:0 copy 0

This will be followed with the retract and z-hop or whatever. So you just have to skip everything between the first (; printing object) and the next (; printing object). The way I read this gcode file, you dont have to do anything but skip those lines.
Shape-Box.zip Here a simple example with 5 copied boxes.

; stop printing object Shape-Box id:0 copy 4
;BEFORE_LAYER_CHANGE
;0.4

G1 Z0.400 F18000.000
;AFTER_LAYER_CHANGE
;0.4
; printing object Shape-Box id:0 copy 0

It even puts the non object related gcode outside of the (; printing object)

[Hywelmartin]

This could be possible, but lookahead might cause some issues with this approach. Cancel an object too late and it will cancel the wrong one.

It depend on if you cancel ongoing(processed in the look ahead que) or cancel the stated ongoing print.. ( so the status need to be stated.. now printing part 4..) sort of ...

[DroneMang]

Curious, I used to use cancel objects with Marlin and Octoprint, but I havent got it working with Klipper yet. What do you have to configure with Klipper and or your slicer (S3D)?

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[robthide37]

Wish theis never lost steam as it really is a great idea

[Arksine]

I have plans to work on this, but I have no timeline as I'm not sure when I will have time to get to it.

[DanielJoyce]

Klipper firmware just controls the printer, let's keep it simple and not do gcode processing to ignore objects in the gcode. Otherwise you keep adding feature and you're back at Octopi.

To me the place for this should be a middle ware, so Mainsail, or Fluidd, could offer the ability to parse the gcode, remove the objects, and then send it to klipper. Let's keep klipper at 'parse gcode, control printer'.

[MarcPot]

@DanielJoyce This would actually change Fluidd/Mainsail into Octoprint. One of the good things about Moonraker is that it lets Klipper do its thing instead of taking the gcode parsing away from Klipper.

Mainsail and Moonraker are just a webinterface and a webinterface api, it doesn't actually do anything with the Gcode, that's handled by Klipper and the reason it has to be integrated into Klipper.

I'm not a Klipper programmer, but if I'm correct Klipper simply loads the modules you specify in your printer.cfg, so it wouldn't bloat Klipper if the module isn't called.

See this comment from Arksine.

Both Region and Object exclusion are done with Octoprint plugins and don't care about your firmware. I've used both on Marlin and Klipper. Mainsail should be the one responsible for the function if it's even remotely similar to Octoprint in that it just feeds gcode to the firmware. I'm probably talking out of turn as I have only hear Mainsail in passing. (off to do some research now)

Moonraker (the backend) does not directly parse gcode files like Octoprint. Instead it exposes APIs with which clients (such as Mainsail) can access Klipper's virtual_sdcard functionality. Octoprint's gcode parser allows plugins like Exclude Region and Cancel Object to intercept gcode commands and exclude them if they fall within an excluded area. The downside to this that there is additional overhead from the gcode processing. Moonraker has very little overhead, thus it can conceivably run together with Klipper on a Pi Zero.

Fortunately Klipper's own gcode parser exposes APIs with which we can transform gcode commands. Writing an extras module to exclude an area/object wont be that difficult outside of dealing with retractions. However I still believe that without a UI using these kinds of modules would be an exercise in frustration. Consider a plate 10 copies of an object, where one object fails. A simple list of objects is probably not going to be good enough for a user to know which object they need to cancel.

I would concede that a full gcode visualizer probably isn't necessary for a usable "cancel object" UI. The object metadata includes bounding coordinates, so a simple UI with selectable "boxes" would probably be good enough for cancel object.

[alfrix]

The proper Gcode for this implementation would be M486
https://reprap.org/wiki/G-code#M486:_Cancel_Object

[MarcPot]

Or just CANCEL_OBJECT since it’s Klipper. With an optional accept or abort after.

[NameOfTheDragon]

This is really a needed feature, because with the best will in the world, sometimes parts do pop off the build plate. With a large build plate, it can be an extremely frustrating experience. I'm posting this comment in the hope that it might bump the issue.

[zztopper]

That's a very useful feature that is requested by many people in community, so maybe this comment would bump the issue

[moebis]

I just tried entering in the console "M486 P1" in hopes it would cancel the part lifting up.... have to restart a 10 hour print now. The 1st object was fine. Please implement this.

[jdobyns]

Not sure why a feature request like this would get closed ...

Do we need to create a new one?

This needs to be a feature in Klipper

[ElGranPepo]

one more for hope to get this implemented!

[kageurufu]

In progress, there's a lot of moving parts to get right :)

[Czarnyszarf]

Any updates ? This feature would make octoprint irrelevant as we have webcam support, a way to access it remotely and in future - cancel objects.

The basic stuff for printer management far from home.

[TeddOravec]

I am also very much looking for this. Those of us with a large bed who like to print many parts at once could really use this feature! Nothing worse than having to cancel a print where 15/16 parts are printing fine but that one will ruin the rest when its spaghetti gets in the way of the other parts.

[robthide37]

Pause print at start of layer. Open slicer then replace without that part but everything else the same and delete your start code and find same z height then cancel print and start new file . It's not great but better then losing the print as long as you don't home again it will be seamless

…

On Tue, Dec 14, 2021, 9:52 AM Tedd Oravec ***@***.***> wrote: I am also very much looking for this. Those of us with a large bed who like to print many parts at once could really use this feature! Nothing worse than having to cancel a print where 15/16 parts are printing fine but that one will ruin the rest when its spaghetti gets in the way of the other parts. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APNYI6EH63ERNVOMD42IZCLUQ5K2VANCNFSM4R3TXPKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[TeddOravec]

You're not wrong, and this is what I and likely most of the others here have been doing to compensate, but then you've got to go through all of that hassle and worry about getting a good first layer again on likely smaller footprints, not an ideal situation. If we could simply say "hey stop printing that one" it would save the hassle.

[robthide37]

Well a solution for now is pause the print at the end of a layer then reslice the file without that object then edit the file to start at that layer and cancel the print then restart it from that point . Its not ideal but its better than losing the whole print if its a big platter

[andrey-kk]

Really like Klipper and moved from Octoprint more than a year ago now having two Voron and Mega S but this feature is really needed. I often have issues with adhesion especially after changing from one filament to another. Would save a lot of plastic otherwise it is always a decision to stop print and lose good objects or go on and possibly spoil good ones with leftover plastic from popped up objects. Writing this a looking and my v2.4 printing with PLA and half of the objects popped up in the middle of 350mm2 print. So now full of spaghetti...

[Arksine]

This is being worked on, you can follow progress at PR #4716. As previously mentioned, there are several moving parts and its taking some time to make sure that all known issues are resolved before merging.

[andrey-kk]

Thanks! Will follow.

[robthide37]

I agree but just making sure you shouldn't be redoing the first layer with my method ? I assume you just meant resuming on the object in which case ignore what I said lol

…

On Sat, Jan 22, 2022, 11:20 PM Tedd Oravec ***@***.***> wrote: You're not wrong, and this is what I and likely most of the others here have been doing to compensate, but then you've got to go through all of that hassle and worry about getting a good first layer again on likely smaller footprints, not an ideal situation. If we could simply say "hey stop printing that one" it would save the hassle. — Reply to this email directly, view it on GitHub <#3375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APNYI6DGODS5SSK6CQTFXB3UXN62PANCNFSM4R3TXPKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>