Severe Issue: End G-code not run and Octoprint must be rebooted after print.

[sgano]

This issue is repeatable. If I cancel the last object (haven't tested cancelling other objects). When the print is complete the end G-code is not run and the printer's nozzle and bed temperatures are left high while the nozzle is directly in contact with the top of the printed part.

Also I have to then reboot the OctoPrint system to get back control of the printer from OctoPrint (even though it seems I can connect and disconnect, the controls don't work).

OctoPrint/Pi versions: OctoPrint 1.4.0 running on OctoPi 0.17.0

I am using PrusaSlicer v2.2.0. (printing with a Prusa MK3S). I have followed all the directions on the GitHub main page: 1) Enable Label objects in the Output section 2) Added "; printing object ENDGCODE " at the very start of the custom "End G-code" field (after this is where the nozzle and bed are turned off, the nozzle is raised etc - which is never executed.).

I have not canceled the object "ENDGCODE" that appears in the cancel object list.

[paukstelis]

I cannot reproduce as it works fine here. Can you please paste just the cancelobjects section from your config.yaml? If you are seeing ENDGCODE in the cancel object tab you have some non-standard settings (it should not be there). Also, attach your uploaded gcode file as a txt file so I can see what's happening there.

[sgano]

I did find at least one other person who ran into this issue too: https://www.reddit.com/r/octoprint/comments/bf3emm/be_careful_using_the_cancel_objects_plugin/

Attached is the G-code file. Planetary_Body_Easier_Print_x3_PLA_MK3S_4h14m.txt

I searched through /home/pi/.octoprint/config.yaml for "cancelobj" and only found two references - one in the "appearance" section for the tab order, and then another reference under the "taborder" plugin. But no section for "cancelobjects" either in the plugin section or otherwise in that file. Could that be part of the issue? I only installed it recently -- maybe the installation/registration process is different in the new Octoprint version? Or possibly it isn't appearing in the file because I haven't changed any of the settings?

[paukstelis]

They likely just didn't have the ENDGCODE at the start of their closing gcode.

If you don't have a cancelobjects section in config.yaml that means it is using all defaults. In that case, it doesn't explain how you would even see the ENDGCODE in the Cancel Tab, since by default it should not be displayed. I THINK this is because you have an extra space after ENDGCODE, but I will confirm that. This might be something that can be looked for to avoid.

I think some of your "Before Layer Change" gcode and wiping are causing issues with your quality after cancelling. There is no need to have that G92 E0.0 there. Not sure where the extensive wiping is coming from, but all that stuff is going to be lost if you cancel that object (id:1 copy 1).

; stop printing object Planetary Body Easier Print.stl id:1 copy 1
M106 S255
;BEFORE_LAYER_CHANGE
G92 E0.0
;0.4

G1 F5760.000
G1 X137.811 Y56.871 E-0.27364
G1 X137.393 Y56.715 E-0.15451
G1 X137.215 Y56.677 E-0.06317
G1 X137.018 Y56.665 E-0.06841
G1 X137.427 Y57.074 E-0.20026
G1 E-0.04000 F2100.00000
G1 Z0.800 F7200.000
;AFTER_LAYER_CHANGE
;0.4
M104 S210 ; set temperature

[paukstelis]

Confirmed that having a space after ENDGCODE is responsible for this issue. Going to look into how to fix it, but for now I will make a note in the readme.

[sgano]

Thanks for tracking that issue down and I removed the space from my profile settings!

For the quality after canceling issues: the 'G92 E0.0' is actually the default value in the Prusa Printer Settings config for the before layer change G-code. The other G1 moves are then also generated by the slicer (it seems by default as I don't see any of my non-default settings changes that should cause that). --- Looking around there are two settings "Retract on Layer Change" and "Wipe while retracting" that are turned on but those are default values -- but they may be creating those lines. I will experiment with them; but it seems if they are default it may be nice to be able to retain them when canceling an object -- as others would have that issue too who use PrusaSlicer.

[manolitto]

Just had the same issue with "Cancel Objects (0.4.1)" in "OctoPrint (1.4.0)" with "Prusa Mini (4.0.5)":

1. Printed just one object
2. Cancelled that object in the middle of a layer
3. Printer just stopped there - no end GCODE was run
4. Tried to cancel the whole print - OctoPrint got stuck in "Cancelling..."
5. Had to reset printer to move head away
6. Had to restart OctoPrint for being able to reconnect

I use PrusaSlicer with enabled "Label objects" option and have "; printing object ENDGCODE" in my end gcode

[paukstelis]

Can you provide your gcode and at least a screen shot of your CancelObject settings?

[manolitto]

Just found something... The file that I was actually printing (and I just grabbed from my OctoPrint instance) is missing the ; printing object ENDGCODE line... This must be some issue with PrusaSlicer 2.2.0 - because when I just reopened the "3mf" file and re-generated the GCODE again, that line was in! So, it seems that PrusaSlicer does not include the correct end GCODE if you just have edited the printer settings. Saving and re-opening PrusaSlicer seems to solve that... will try to reproduce this - just wanted to let you know.

However: What IS included in the gcode (see attached file) is the line ; stop printing object Patron2.stl id:0 copy 0 So, my question is: couldn't you just skip to after that line if there is no ; printing object ENDGCODE line in the file? Just to make this plugin more resilient - having to restart OctoPrint and reboot printer on a failed cancel is not nice ;-)

Anyway - thanks for that nice plugin! :-)

my plugin settings:

    cancelobject:
        allowed: G1 Z.*

Patron2.gcode.txt

[paukstelis]

This issue has been fixed in several ways. First, it does now use ; stop printing comments from PrusaSlicer/SuperSlicer to exit skipping blocks. Second, I've now made sure that the skipping flag is reset if a print completes/cancels/etc. I'm not sure how I did not have this in before. I've also chosen to turn off the heaters if the print finishes while it is skipping since there is the possibilities of missing heater turn off commands in that scenario.

Current release (0.4.2) already has stop comments incorporated. Next release will fix the flag reset.