Octoprint-Cancelobject icon indicating copy to clipboard operation
Octoprint-Cancelobject copied to clipboard

Cancelling object stops z movement (using Cura 3.6.0)

Open BrewNinja opened this issue 5 years ago • 22 comments

I upgraded to Cura 3.6.0 yesterday (it was officially released) and needed to cancel a single object. The plugin now does see the objects from Cura (the good news). However, after I canceled one of the objects, the z axis was no longer triggered, so it kept trying to print at the same height for each layer. TH3D Marlin firmware on an ender 3, octoprint 1.3.9 on octopi 0.15.1.

BrewNinja avatar Nov 14 '18 14:11 BrewNinja

I'll take a look. Are you using relative or absolute extrusion? I have found some bugs with absolute extrusion tracking, so I highly recommend making sure that relative extrusion box is checked.

paukstelis avatar Nov 14 '18 16:11 paukstelis

I am using absolute. Its the default setting. Ill try relative later and see if that fixes things. Thanks!

BrewNinja avatar Nov 14 '18 16:11 BrewNinja

Also, make sure you don't cancel the NONMESH object. It contains extra movements (including Z movements if you aren't using Z-hops). I didn't really want that to be in there, but it is just the way Cura is organized as a slicer.

paukstelis avatar Nov 14 '18 16:11 paukstelis

Also, please let me know how things go when you do more testing. There hasn't been a lot of feedback from Cura users yet.

paukstelis avatar Nov 14 '18 20:11 paukstelis

I've also had this problem using Cura 3.6.0. Using the default settings for ender3 and after I cancelled the printer started making lots of noise due to the steps the bed and extruder was skipping. Didn't cancel the NONMESH object. I'm using a standard Marlin firmware on an Ender 3 rather then the TH3D variant.

thomaspreece avatar Nov 25 '18 21:11 thomaspreece

Did it happen right away after you cancelled, or did it take a few layers?

You should always use relative extrusion (under special modes). Absolute extrusion works in some cases and not others. It is inconsistent enough that I haven't figured out what is failing.

paukstelis avatar Nov 25 '18 23:11 paukstelis

I have also had this same thing happen on my Ender 3 with the TH3D version of the firmware slicing with Cura 3.6.0. I'm guessing I'm in absolute extrusion mode but will try changing and see what happens.

blight89 avatar Dec 19 '18 13:12 blight89

Are you using STL filenames that have UTF-8 characters? https://github.com/Ultimaker/Cura/issues/4949

paukstelis avatar Dec 19 '18 14:12 paukstelis

I do not recall any special characters. Typically my STL has something like example_name_object.stl I noticed if you multiply the same STL Cura then adds example _ name_object(1).stl. Also note that the print I'm my case was several layers high previous to canceling the failed object. So Z height was changing.

On Wed, Dec 19, 2018, 8:37 AM paukstelis <[email protected] wrote:

Are you using STL filenames that have UTF-8 characters? Ultimaker/Cura#4949 https://github.com/Ultimaker/Cura/issues/4949

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/paukstelis/Octoprint-Cancelobject/issues/17#issuecomment-448617575, or mute the thread https://github.com/notifications/unsubscribe-auth/APr5B94DKViiHIDql1QEYCpJITfFuVPVks5u6k8igaJpZM4Yd3Ik .

blight89 avatar Dec 21 '18 04:12 blight89

Hello, I just had the same problem. When I examined the G-code, I noticed that the layer change happened within the first object. Since I canceled the first object but also the layer change was skipped. Cura 4.0

RuediB avatar May 17 '19 18:05 RuediB

I just came across this issue. Gcode was created by PrusaSlicer.

patriot1889 avatar Apr 13 '20 21:04 patriot1889

I've never seen PrusaSlicer do this. Please provide gcode file.

paukstelis avatar Apr 13 '20 21:04 paukstelis

I do now recall seeing this before. I don't see it normally because I have Z-hop enabled be default. This resets the position at the start of each object. I will put in a feature request with PrusaSlicer to see if it might be possible to include a re-positioning of Z at the start of each object.

paukstelis avatar Apr 13 '20 23:04 paukstelis

One way to get around this is to use the "Allowed Gcode" section. Just put G1 Z.* there and it will allow your Z-moves in the cancelled object.

paukstelis avatar Apr 26 '20 18:04 paukstelis

Same problem happens with v0.4.7 and PrusaSlicer 2.4.1 image G1 Z.* works. It should just be the default behavior for regular (non sequential) prints.

kb- avatar Apr 15 '22 20:04 kb-

I'm on Superslicer and have the same problem, if the Z change is inside the canceled object then there's no layer increase and no Z height change. I was lucky to have Obico stop my print before the disaster.

;LAYER_CHANGE
;Z:0.48
;HEIGHT:0.28
;BEFORE_LAYER_CHANGE
;0.48


G92 E0
;WIPE_START
G1 F7200
G1 X180.901 Y184.768 E-0.01917
;WIPE_END
G1 E-0.8 F1800
; stop printing object C9.1.stl id:1 copy 0
M486 S-1
G1 Z0.48 F9000
;AFTER_LAYER_CHANGE
;0.48

Superslicer is nicely formatting the Layer change, it should be quite simple to see when a Layer change is inside the canceled object and then keep at least the G1 Z command. If adding G1 Z.* to Gcode exclusion is mandatory why it's not on as default? It's quite obvious that when you have 2 objects a layer change happens inside the canceled object, so in this way the plugin is NOT working by default.

lettore avatar Oct 25 '22 08:10 lettore

I'm on Superslicer and have the same problem, if the Z change is inside the canceled object then there's no layer increase and no Z height change. I was lucky to have Obico stop my print before the disaster.

;LAYER_CHANGE
;Z:0.48
;HEIGHT:0.28
;BEFORE_LAYER_CHANGE
;0.48


G92 E0
;WIPE_START
G1 F7200
G1 X180.901 Y184.768 E-0.01917
;WIPE_END
G1 E-0.8 F1800
; stop printing object C9.1.stl id:1 copy 0
M486 S-1
G1 Z0.48 F9000
;AFTER_LAYER_CHANGE
;0.48

Superslicer is nicely formatting the Layer change, it should be quite simple to see when a Layer change is inside the canceled object and then keep at least the G1 Z command. If adding G1 Z.* to Gcode exclusion is mandatory why it's not on as default? It's quite obvious that when you have 2 objects a layer change happens inside the canceled object, so in this way the plugin is NOT working by default.

The plugin works fine, I would say that the slicer is not working by default. The reasons why there are options in the plugin is because there is no consistency with how slicers do things. For SuperSlicer, you probably want to check the Use object stop tags setting which will take care of this.

paukstelis avatar Oct 25 '22 12:10 paukstelis

I'm quite disoriented as info of Use object stop tags says: Keep unchecked if you use Superslicer and use wipe+retract on layer change. I'm using wipe while retracting, so is it impossible to use this plugin with this setting active?

This is from the README:

PrusaSlicer/SuperSlicer
Enable Label objects in the Output section
Object names can be modified in the object list in the right panel. Note, this only works for objects that are imported independently, not on copies/clones of objects.
For the end custom GCODE, include at the start: ; printing object ENDGCODE

It's possible that you need to rewrite the README as these settings are not working as default.

lettore avatar Oct 25 '22 16:10 lettore

I'm quite disoriented as info of Use object stop tags says: Keep unchecked if you use Superslicer and use wipe+retract on layer change. I'm using wipe while retracting, so is it impossible to use this plugin with this setting active?

This is from the README:

PrusaSlicer/SuperSlicer
Enable Label objects in the Output section
Object names can be modified in the object list in the right panel. Note, this only works for objects that are imported independently, not on copies/clones of objects.
For the end custom GCODE, include at the start: ; printing object ENDGCODE

It's possible that you need to rewrite the README as these settings are not working as default.

Slicers change how they do things all the time, and I have no way of knowing when changes will impact the plugin. I can update the README to reflect these changes, but basically you have two options with SuperSlicer from what I can see: use Object Stop tags, or use some small amount of Z-hop, which will re-write the Z-height at the start of each object.

paukstelis avatar Oct 26 '22 13:10 paukstelis

I understand that you can't know how the plugin is behaving with all the slicers around, that's why I'm writing here, because I found that with the proposed settings your plugin is not working with Superslicer. I enabled Object Stop tags and I will see if that does the trick.

lettore avatar Oct 26 '22 14:10 lettore

I added G1 Z.* to the list of allowed gcode, but the issue still persisted. I am using orcaslicer. Any help or info would be great, it's looking like for now I'll just have to add a small z hop or something.

Ender436 avatar Feb 09 '24 16:02 Ender436