Cancelling object stops z movement (using Cura 3.6.0)

[BrewNinja]

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.

[paukstelis]

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.

[BrewNinja]

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

[paukstelis]

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]

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.

[thomaspreece]

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.

[paukstelis]

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.

[blight89]

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.

[paukstelis]

Are you using STL filenames that have UTF-8 characters?
Ultimaker/Cura#4949

[blight89]

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 ***@***.*** wrote: Are you using STL filenames that have UTF-8 characters? Ultimaker/Cura#4949 <Ultimaker/Cura#4949> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APr5B94DKViiHIDql1QEYCpJITfFuVPVks5u6k8igaJpZM4Yd3Ik> .

[RuediB]

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

[patriot1889]

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

[paukstelis]

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

[patriot1889]

cancelobject.gcode.zip

[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]

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.

[kb-]

Same problem happens with v0.4.7 and PrusaSlicer 2.4.1

G1 Z.* works. It should just be the default behavior for regular (non sequential) prints.

[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.

[paukstelis]

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.

[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.

[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.

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.

[lettore]

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.

[Ender436]

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.