Slow travel to cancelled object on every layer #62
Comments
|
Please provide sample gcode. First guess is that it is related to wipe moves. |
|
Sure, here's the file I'm printing right now that is showing the issue. I don't have Wipe Between Layers on, but Outer Wall Wipe Distance is set to 0.2 and Infill Wipe Distance is at 0.125 (both Cura defaults, I think). |
|
It is certainly related to the wipes. Here is the first snippet: You see that it is doing the G0 moves that are the wipe for the previous object (part B) after the |
|
It looks like there is some new behavior in Cura with respect to the types of movements they are also putting in NONMESH between objects on layer changes that is causing issues as well. |
|
Oh interesting. Though, it seems like the G0 moves are part of the travel to the other part, so it kinda makes sense that they're after the tag. If I step through the actions in the Preview, it seems like those moves include all the combing moves required to get "out" of the current part and to the starting point in the next part. So I guess what's happening is those moves to get TO the cancelled part are gone, but the moves to get BACK out of the cancelled part are still there. Doesn't really explain why it goes so slow though, does it? |
|
If you look at the NONMESH object you'll see the problem. There is an F600 move. I believe if you cancel the last object in the list you'll do this F600 to the cancelled object. |
|
It does seem to largely be related to combing, but also some redundant moves in the NONMESH. |
|
Yep, you're totally right. Thanks for figuring that out so quickly! I might experiment with turning combing off, though it does seem to help quite a bit and I rarely need to cancel objects... but when I do, it sure is a lifesaver. 😅 |
added a setting that if enabled will attempt to remove X and Y components from NONMESH z-hop moves to avoid a slow travel move across the bed for details see Ultimaker/CuraEngine#1369 (comment) and paukstelis/Octoprint-Cancelobject#62
|
Hi, i just installed octoprint as getting into multi object prints, and badly needed object cancellation and remote monitoring so i can stop an object rathen than the whole print. This plugin is great thanks. im using cura 4.8 |
|
here is my gcode around the time it happens, there is a move from the back of the bed (high y) to the front (low y) and a z layer change, could it be the problem that its happening at F300 speed ??
|
|
As it says above. Turn off combing. Cura writes some unneeded position/feedrate commands when combing is active. |
|
ok ill try that next print, as ive been wanting to try without it for other reasons, i did find the suspect command in the original gcode too, at the start of a nomesh section |
|
I turned off combing and regenerated the gcode to inspect manually while waiting for print to finish, and it makes no difference it still has the z change line pasted in last comment with 300 speed part of nomesh |
|
I would complain to Cura devs. I've tried to get them to not do stupid things, but it falls on deaf ears. They pretty much only care how it impacts Ultimakers. |
|
PrusaSlicer/SuperSlicer work nicer. |
|
I can look into those. But wouldnt it be possible to just look at the nonmesh section after the cancelled object and strip any x y movement from the z change ? |
|
Possible, sure. I'm not really keen on writing a bunch of exceptions for each individual slicer. |
|
yeah i can understand that as its a bit hacky too, how does this plugin 'cancel' an object ? is the does it intercept the gcode live or modify the loaded gcode in memory or file ? |
|
The only way it can work is to do it "live". OctoPrint has the ability to modify commands before they are sent to the printer. It just watches that queue, and if the object is cancelled it just skips sending those commands to the printer. |
|
I just had a look at Cura 5, and it looks like it fixes this problem. |
|
dang, im on win 7 which doesnt support 5.0 |
|
And to clarify, it seems to fix with combing turned off or to infill only. Same behavior if combing is set to all. The other thing that is puzzling about your gcode is how slow that first move is. Even before Cura 5 (I only had 4.11 on hand) it would at least use the travel move speed and not the Z-move speed. So if you can upgrade even a bit the results will be better. |
|
i tried combing off and it didnt change the gcode output order. |
|
that is stock settings, this is with combing off: |
|
someone discussing a similar problem https://community.ultimaker.com/topic/33422-insert-g-code-before-layer-change-is-at-the-wrong-place/ |
|
actually these last 2 posts would be ok, as the z rise is at the original y position ( Y185.615 back of plate), will try it out next time |
|
Trying adding Z-hop and see how it looks. |
|
sorry, very confused back when i was reporting on combing i was just looking at only which block the z change was, not its y position, i will investigate further and get back to you |
|
after putting this down and reflecting on it some, I cant see how it can be possible to get around this while the unskippable z layer change has a x and y coord mentioned in it, as there will always be a object skipping scenario where the z change is out somewhere there is no objects anymore and the head inadvertently travels to that x y at the slow z speed to make that z change. the only way around this is to strip out the x/y , can you think of any scenario where it would need to be there ? |
|
I installed superslicer to look at its output and it has the Z change by itself (no XY): G1 Z0.8 F9000 |
|
This why I was telling you to take it up with Cura devs. Cura puts in unnecessary moves. The thing you might look into is why that motion is so slow on your profile. F300 is ridiculously slow. In all my profiles that same movement is F10800, so while the behavior is the same, it doesn't string because it is just a very fast travel movement. |
|
So im running Creality Slicer 4.8 which im assuming is just cura 4.8 rebadged with their profiles, as it has a ender 3 S1 Pro profile and came with the printer, if i use the default standard slice profile it still has F300 as the Z speed, if a set a custom FFF printer profile it goes to F600. I set up a custom printer profile in cura 4.13.1 and it is atleast not setting a Z speed wheres as the ender 3 pro profile i tried earlier (as closest to mine) was still fixed at 300. |
|
Im going to have to leave this again for a few days, now i cant stop 4.13.1 from putting in F600 on z change now and cant work out how that happened or how to stop it... |
|
Ok I narrowed in on where the F300 or F600 is coming from in Cura. It is the Z Hop speed !! But regardless of if Z hop is enabled or not and thus the setting is shown or not it is still being used. and it is defaulting to the printer profile for the json setting machine_max_feedrate_z and for my creality based profile it would not let me go above 10mm/s (F600) without it going red and blocking slicing. A custom profile however can go above this, but it seems a bug that it would be being used even when z hop is off, I will try a cura github issue to get some clarification. Ultimaker/Cura#12658 Still cant work out how I got it to not mention the speed F600 in that layer change.... |
|
o dear, it was right under our nose all this time |
|
So it seems the easiest way to get around this for now for me, is actually just set the Z hop speed to 0, i then get F0 in the layer change, and luckily for my printer it doesnt just stop, and travels at what seems to be my normal travel speed ! another option would be to set it to your travel speed if F0 doesnt work for you, it still does the x y moves to the layer change location, but at least what seems to be fast enough to stop stringing. As a side note Im also migrating to cura 4.13.1 with custom printer profile |
|
The other option would be to look into this https://github.com/shinmai/cura-M486 |
Say I'm printing two parts, A and B, and I cancel part B after a few layers. From then on, on each layer, when it gets to the end of the extrusion for part A, it does this:
This takes up time, but more importantly it allows plenty of material to ooze out during the slow travel, causing some unsightly blobs on part A (and increased risk of catching one and knocking the part).
Yes I'm using relative extrusion, Cura 4.8, Marlin 2.0.x. Is there any way to avoid this? :/
The text was updated successfully, but these errors were encountered: