Doesn't move away so burns print

[TheCableGuy99]

I've been a little busy so not reported this but around 2 weeks ago I did a print, cancelled an object and the nozzle sat there wondering what to do next, unfortunately this was where the last print finished which as I cancelled the object before it was due to move on to the it.

This resulted in the previously finished print being burnt and melted slightly by the nozzle.

[TheCableGuy99]

Confirmed again with another print today... I set it printing, cancelled the remaining objects so there was nothing else to print and had a small burn and indentation where the nozzle remained before the nozzle moved away and actually cancelled the print.

[paukstelis]

What hardware are you running OctoPrint on? What plugins are installed? Can you provide the plugin_canceobjects.log file, please.

[TheCableGuy99]

Hi,

I'm running a Pi4 8GB.

Plugins are: Bed Visualizer (1.0.0) BLTouch Plugin (0.3.4) Cancel Objects (0.4.4) Creality-2x-temperature-reporting-fix (0.0.4) Dashboard (1.17.0) Detailed Progress (0.2.7) DisplayLayerProgress Plugin (1.25.3) Dragon Order (0.1.7) Exclude Region (0.3.0) Filament Sensor Reloaded (1.3.4) Floating Navbar (0.3.4) GcodeEditor (0.2.10) Octolapse (0.4.1) OctoPod Plugin (0.2.9) PrettyGCode (1.2.4) PrintTimeGenius Plugin (2.2.7) Resource Monitor (0.2.8) Simple Emergency Stop (1.0.4) Tab Order (0.5.12) Themeify (1.2.2) WebcamTab (0.2.0)

plugin_cancelobject_cancelobject.log

Logfile attached

Lastly, the issue appears to mainly be when cancelling objects and there are none left following the current one. So if printing something and whilst printing it I cancel all following objects. Once the current object finishes it sits there and burns the end of the current object. It's like it's sat there going through the GCODE looking for the next object then realises after a little while there is nothing left and then moves.

A simple Z+10 at the end of each object before thinking would be great if possible.

[paukstelis]

There should not be any thinking, or the time should be very short. Can you provide gcode used for your test?

[paukstelis]

Additionally, if you can change your slicer to relative extrusion (looks like from logs it is absolute) and do your same test, that would be appreciated.

[TheCableGuy99]

I forgot to mention that I print sequentially rather than going layer-by-layer which might mean it has to search through more code, hence the thinking time? Just a thought?

This isn't the exact same one as I deleted it so have re-created it. It should be the same though...

So if you set it all printing it should print the front first, while printing it cancel all the others. When it gets to the end of the front it will sit there a little while before it finishes everything and what causes the burn.

I'm not sure what you mean by changing to "relative extrusion"?

Thanks for your help pal.

Attach file extension changed to .txt from .gcode to allow upload. Parts.txt

[paukstelis]

OK, this makes more sense with sequential printing. Yes, it will take longer because it has to skip much more. You can use the before/after gcode sections in the options to add a relative Z move up and then down if this is an issue.

Something along the lines of:

You probably don't even need the After gcode if you are doing sequential, just put the G90 at the end of the Before gcode.

[TheCableGuy99]

Great!

I just need to clarify something though as I'm no expert...

You said to put G90 at the end of the "Before GCODE", but in your example the only G90 I see is at the end of the "After GCODE".

Please can you clarify what I should put and where?

Thanks again!

[paukstelis]

Because you are doing sequential, it will reset the Z-height for the next object, so you really just need the following in Before skip GCODE and leave the after skip gcode empty:

G91,G1 Z10 F400,G90

[TheCableGuy99]

thanks buddy, appreciate the help :)

[forkineye]

Is this is similar to the issue this guy was having? https://www.reddit.com/r/octoprint/comments/bf3emm/be_careful_using_the_cancel_objects_plugin/

[paukstelis]

Is this is similar to the issue this guy was having? https://www.reddit.com/r/octoprint/comments/bf3emm/be_careful_using_the_cancel_objects_plugin/

No. That was an issue with not having the end gcode markers. Recent version handles this even if those markers are missing.

[TheCableGuy99]

Hey,

Sorry but this is still happening.

This was the end of one object with sequential printing and the next object was cancelled. I wasn't there to monitor it but it appears to be the same issue where it thinks about what to do next going through the GCODE and melts the object as it's staying put.

Attached are also the settings you suggested previously I am using.

Thanks.

[paukstelis]

What slicer are you using? I don't think you need the Allowed Gcode line. It will do every G1 Z command while it is skipping with that in there.

[TheCableGuy99]

I’m using Simplify3D but also use Cura now and again.

What do you suggest for both please mate?

[paukstelis]

From what I can tell, from looking at a Cura sliced file and an older S3D sequential gcode file is that you should not need anything for before/after/allowed gcode. Just remove them all. It would be a good idea for Cura to turn combing off.

[TheCableGuy99]

okay removed, i'll see how that goes, thanks again.