Feature Request: Better wipe/Z-hop

[karlzhao314]

Version

2.0.0

Operating system type + version

Win64

3D printer brand / version + firmware version (if known)

Prusa i3 MK3 version 3.7.1

Both enabling and disabling Z-hop presents its own issues.

Enabling Z-hop eliminates blobbing caused by ooze on the side of prints, just as it's intended to do. However, often during the Z-hop move a thin wisp of plastic will be pulled up from the print, which is then dragged/bridged over to the next part of the print to be printed. This creates thin, wispy stringing. This phenomenon happens even when retraction and "wipe while retracting" are enabled - it seems to be an inherent issue simply with the act of lifting the nozzle while the nozzle is over the print.

Disabling Z-hop more or less fixes this, since during the travel move the nozzle is "wiped" clean as it moves off of the finished printed part and no string is pulled up. However, due to oozing during the travel move, a visible blob may be left on the side of new part that the nozzle is starting. This can be improved by making travels faster and tuning retraction settings, but it can't always be eliminated entirely - especially with longer travels.

As I see it the best option here is to combine the two behaviors. To start a travel, the print head would move off the just-finished object without hopping. This would wipe off the nozzle and eliminate the possibility of "pulling" up a string. However, during the travel move the print head would perform a Z-hop move between objects in midair, so that as it crosses the perimeter of the new object, no blob is left. This should be implemented as a toggleable option - it does not have to replace the current Z-hop option entirely.

Is this a new feature request?
Yes

[smartynov]

This is exactly what I've been thinking while trying to find optimal settings for complex prints (lots of small details). This might help to avoid dragging issues and keep away from oozing. It would be nice to have this option implemented.

[wavexx]

I think it's the current behavior of wiping which is suboptimal and I'd love to to see improved.

Slic3r's behavior for wipe is to follow the last path in reverse. It is a good solution in general to avoid artifacts, but since the layer often ends in infill and in a corner (which makes the nozzle be around the same spot for longer), what you get is partial overheating on the surface, which then facilitates molten plastic to be lifted.

Cura fares better in this area, using a different approach to wiping which is called "combing". Instead of following the last path, the wipe is calculated using a different strategy, usually a single straight move going inwards in the print prior to the hop/travel. It's a lot quicker too on small features.

[paulnewall]

I very much agree with the description by karlzhao314. I have experimented (by modifying slic3r) with the idea of doing z lift at the same time as the horizontal travel. The unlift remains as before ie vertically downward.
This is giving me petg prints with much reduced stringing than I would get with vertical z lift, and with much less blobs than I would get with no z lift.

[belm0]

The wipe behavior I've observed is documented at #4655. Notably, PrusaSlicer appears to always do a small wipe (at full travel speed). The "wipe during retraction" option merely extends that wipe into the retraction period.

[andrew-benjamin]

I very much agree with the description by karlzhao314. I have experimented (by modifying slic3r) with the idea of doing z lift at the same time as the horizontal travel. The unlift remains as before ie vertically downward.
This is giving me petg prints with much reduced stringing than I would get with vertical z lift, and with much less blobs than I would get with no z lift.

Hi
I experimented with this and generated a comparison set of prints with Z hop increasing during travel and this worked really well to fix stringing and ooze. I need good layer strenth and reducing nozzle temperature is not an acceptable solution as the less stringy material (PETG in my case) is weaker.

I generated an excel file to post process gcode from PrusaSlicer.

[belm0]

This looks promising!

z-hop increase insufficient at midpoint of dravel

Have you considered a non-linear function?

[andrew-benjamin]

Thanks, the test peices work but it would be nice to trial in the actual slicer,
Cura has the option to avoid printed parts on travel which would help this situation but I think an S curve would be more optimal as you sugeest but makes the path more complex. A G0 command would also alow the Z to reach its position on its own time scale but this could create unpredictable results as z acc'n is often 1/5th of X and Y. I
I would be happy with linear ramp or perhaps a horizontal start minmimum of two wall widths, followed by 30 degree ramp to Z Hop height and then level off.
How easy would it be to programme this?

[karlzhao314]

@belm0 the one thing that worries me about a hop profile like that is that the motion right at the start of the Z hop is still fairly close to pulling the nozzle straight up, which still might result in a wisp being pulled up. As I envisioned it, ideally you'd have the nozzle wipe off the print traveling basically horizontal, then initiate the upward motion after the nozzle is already traveling in midair - something similar to this.

Of course, curved moves put more computational load on the motion planner, so something like this would accomplish the same effect.

I hand-wrote G-code to test the latter case a long time ago, but unfortunately my results were inconclusive because I got no stringing between any of my three test cases - Z-hop on, Z-hop off, and my modified handwritten gcode. Hey, anyone have any ideas on how I could intentionally increase stringing?

[andrew-benjamin]

@belm0 the one thing that worries me about a hop profile like that is that the motion right at the start of the Z hop is still fairly close to pulling the nozzle straight up, which still might result in a wisp being pulled up. As I envisioned it, ideally you'd have the nozzle wipe off the print traveling basically horizontal, then initiate the upward motion after the nozzle is already traveling in midair - something similar to this.

Of course, curved moves put more computational load on the motion planner, so something like this would accomplish the same effect.

I hand-wrote G-code to test the latter case a long time ago, but unfortunately my results were inconclusive because I got no stringing between any of my three test cases - Z-hop on, Z-hop off, and my modified handwritten gcode. Hey, anyone have any ideas on how I could intentionally increase stringing?

I would suggest this is an ideal curve. I modified the GCode using an excel formula set but it is limited to a linear ramp.
I am having a strining issue with PETG- 20 Carbon fibre at higer temperatures 245C. I find if the tempertaure is reduced to limit stringng and ooze blobs at 225 to 230C this is the same temp at which layer adhesion starts to diminish. I suspect this is because the filament is less fluid.

[belm0]

Agreed that curve addresses the problem directly, and linear is probably good enough. If it were parameterized in the slicer, I'd like to have detailed settings for 1) delay before the ramp, and 2) ramp duration. Because it's a tradeoff between stringing / ooze / avoid hitting nearby extrusions, so you may need to adjust it according to the print.

For really advanced slicing, the slicer should know where extrusion has happened on the past few layers, and make sure z-hop has reached maximum height over those areas.

[n8bot]

IceSL (slicer that lots of people have never heard about) generates travel moves in a way similar to this. They add a small segment at the beginning of the travel move, and do a diagonal move. This has many great effects, some mentioned here but also the fact that the Z axis acceleration/jerk/max speed settings slows things downs, allows the travel speeds to be very rapid, but the toolhead will slow down a little bit naturally upon descending with the unlift move, and this helps prevent ringing after travel moves.

IceSL provides the best quality prints I've ever seen: the slices are impeccably accurate and the toolpaths are smooooth as butter. I'd love to have this specific feature in other slicers.

[paulnewall]

I have implemented the single diagonal move, both in prusaslicer and in marlin (for the firmware retract). It's very simple, not much more complicated than deleting the existing z hop vertical move from the retraction, then the next move from the g code (the travel move) will automatically be diagonal.
I did not make the change optional. That would add a lot of programming effort, particularly for someone like me - not familiar with the structure of the code for the user interface.
I have never encountered the problem where blobs wipe onto the print partway through the travel move. That might be because I don't have parts where that might happen very often, or because I use quite a high z lift (1.5mm).

[andrew-benjamin]

IceSL (slicer that lots of people have never heard about) generates travel moves in a way similar to this. They add a small segment at the beginning of the travel move, and do a diagonal move. This has many great effects, some mentioned here but also the fact that the Z axis acceleration/jerk/max speed settings slows things downs, allows the travel speeds to be very rapid, but the toolhead will slow down a little bit naturally upon descending with the unlift move, and this helps prevent ringing after travel moves.

IceSL provides the best quality prints I've ever seen: the slices are impeccably accurate and the toolpaths are smooooth as butter. I'd love to have this specific feature in other slicers.

Thanks for the suggestion, i had a look at IceSL but it would not render the stl files i tried loading and then crashed while slicing so its was too unstable on my PC to use.

[andrew-benjamin]

I have implemented the single diagonal move, both in prusaslicer and in marlin (for the firmware retract). It's very simple, not much more complicated than deleting the existing z hop vertical move from the retraction, then the next move from the g code (the travel move) will automatically be diagonal.
I did not make the change optional. That would add a lot of programming effort, particularly for someone like me - not familiar with the structure of the code for the user interface.
I have never encountered the problem where blobs wipe onto the print partway through the travel move. That might be because I don't have parts where that might happen very often, or because I use quite a high z lift (1.5mm).

Is that something you can share? Which file did you edit? I was only lifting 0.4 so I think you are right that higher lift would be better. Thanks

[mmcglumphy]

I would like to see an option to disable Z-hop on outer top layers. My biggest gripe with the hop is the little sharp Hershey Kiss that gets left behind. On prints with rugged tops, it can get pretty sloppy.

[bubnikv]

My biggest gripe with the hop is the little sharp Hershey Kiss that gets left behind. On prints with rugged tops, it can get pretty sloppy.

Sand paper like surface.

The move IceSL does may be optimal for Deltas, where the Z move is roughly as cheap as any other move. On other kinematics the Z move is much slower than XY, so the diagonal move ala IceSL does not help much.

The wipe away from the perimeter is worth investigating, and actually this is what @rtyr, who is responsible for tuning our printer profiles, was mentioning while ago. I am a bit worried that one would trade the sand paper Heshey Kiss dots for similar sharp features at the side of an object. Still it is worth investigating.

[mmcglumphy]

That would be an interesting option to investigate.

I currently disable Z hop in the filament overrides (risking collisions) and have had very good success. The difference in quality is night and day for the prints I make, as they are mostly terrain models featuring very organic shapes.

For mechanical parts and such, I re-enable it.

[Shootquinn]

My biggest gripe with the hop is the little sharp Hershey Kiss that gets left behind. On prints with rugged tops, it can get pretty sloppy.

Sand paper like surface.

The move IceSL does may be optimal for Deltas, where the Z move is roughly as cheap as any other move. On other kinematics the Z move is much slower than XY, so the diagonal move ala IceSL does not help much.

The wipe away from the perimeter is worth investigating, and actually this is what @rtyr, who is responsible for tuning our printer profiles, was mentioning while ago. I am a bit worried that one would trade the sand paper Heshey Kiss dots for similar sharp features at the side of an object. Still it is worth investigating.

This could be helped by enabling "Wipe while retracting" on the top layer only somehow. I have the hershey kisses / sandpaper surfaces on parts printed on my Mk3, and a wiped surface on the Mini. On the flip side, I'm about to submit an issue to disable wiping on the first layer. While I envisioned a toggle for disabling wiping on the first layer, the fact that it also affects top layer quality may demand more flexibility. Aside from the top and bottom layer, wiping is mainly to prevent stringing and ooze. For the top and bottom layer, however. wiping contributes/detracts to the finish quality directly.

[Julianus43]

I think its not only important that the z-hop happens later in the travel move by an diagonal or jump function like movement, but also that the nozzle dosnt move straight to the next point, instead it could be better to travel inwards away from the outer perimeter first like Cura does it. As i described with images in the closed dublicat mentiond (Ref #5781)

[burner-]

It i nice to see that also others have seen this current solution as problem. I opened ticket at 2019 of that same problem/solution
#2019
Anwyay it is good to see that finally there is some plannig around of this. With large printers this dragging problem is serious issue.

[jeremy-wendelken]

Hi all!

Another MK3S+ user here with dreams of eliminating all stringing!
I note that this issue is almost 2 years old now!

I have read through the comments above, and the lift Z pathing suggested seems unnecessarily complex to me and I suspect it wouldn't solve stringing as effectively as a simple wipe inside the print.
Lifting the nozzle in any direction always has a chance of a small string developing, which is why many disable lift Z to reduce stringing.
The travel move/combing inside infill after/during a retraction physically cleans the nozzle from any leftover plastic and seems to all but eliminate stringing.
See the Prusa forum post for the night and day difference:
https://forum.prusaprinters.org/forum/original-prusa-i3-mk3s-mk3-how-do-i-print-this-printing-help/stringing-with-prusaslicer-solved-with-cura/

What is the current status of a feature such as this being implemented?
Or is another route being taken to resolve this issue?

TL;DR: Cura combing stops stringing, let's do that too :)

[andrew-benjamin]

Hi,
This was my suggestion after trials. Although I have found stringing to increase with moist filament, the wipe path overlap would help reduce zits caused by stationary retraction and maximise smoothing of the outer surface while minimising stringing. The aim is to provide a wider range of tolerance on the retraction settings.

Esentially: The perimeter should finish by retracting while moving over the start of the current perimeter and then wiping inward. Retract and wipe is a combined move.

Blobs from any subsequent ooze during travel cause trees to form on the surface, using z hop should also mean the nozzle should approach the work piece like an aircraft landing so any blob formed during travel is drawn out in the print direction and then overprinted at the end overlap stage.

The nozzle should not stop as it currently does (especially in Cura), the nozzle should never be stationary against the face of the work piece. A stationary nozzle can create a spot with either excess filament or localised ironing/reheating so must be avoided. Moving the nozzle during retraction would ensure any ooze is distributed over a travel length reducing any spot problems.

Final move wipe inward toward infill before travel with Z-hop if required. This happens with the nozzle having no filament pressure and from relatively cool surface so stringing is minimised. This could be a specified distance or number of outer layer multiples.

Currently, increasing retraction length actually causes a longer dwell time at the end of the print line and can increase stringing as material in the nozzle tip is fully heated and connected to a molten hotspot on the workpiece. Coasting is very unpredicatble due to multiple dynamic factors and I think should be avoided.

[karlzhao314]

I have read through the comments above, and the lift Z pathing suggested seems unnecessarily complex to me and I suspect it wouldn't solve stringing as effectively as a simple wipe inside the print.
Lifting the nozzle in any direction always has a chance of a small string developing, which is why many disable lift Z to reduce stringing.

In the end, the point is that the Z-hop move would occur in midair after the nozzle has completely left the part. It won't be able to pull up a string, because there's no print below it to pull up a string from.

[n8bot]

PrusaSlicer already does add a small move inward at the end of a path. (Or only the end of the loop? I forget) Look at your gcode. It's there.

There is also the ability to "comb" a little bit. PS feature: Wipe while retract. It's actually a decent feature and in the code base it's easy to alter the behaviour if needed.

[andrew-benjamin]

The Wipe is nearly there however at the end of the perimiter all the speeds are reduced and retraction doesn't start before the end of the perimiter. If the option to 'Retract before Wipe' is selected the retraction is completed when the head is stationary. At the end of the wipe there is another very short retraction when the nozzle effectively stops before the move to start infill.

Here is a gcode extract, 1mm retraction and 50% retraction before wipe. It appears the nozzle has two unneccessary stationary points before the moves. The feature request is to make 'Retract before Wipe' occur during nozzle movement.

......G1 X171.234 Y151.368 E0.12659
G1 X174.536 Y151.368 E0.09130
G1 E-0.50000 F2700.000 - This is the 50% Retract Before Wipe and it is stationary, it would be beneficial if the nozzle did not stop at this point.
;WIPE_START
G1 F7200.000
G1 X173.203 Y151.368 E-0.47500 - This is most of the remainning retraction following the path
;WIPE_END
G1 E-0.02500 F2700.000 - here is the final retraction with the nozzle effectively paused again before the travel.
G1 X139.078 Y151.056 F9000.000
G1 E1.00000 F2400.000 - here is the nozzle prime starting the next perimiter.
;TYPE:Perimeter
G1 F900
G1 X139.078 Y158.944 E0.21809.....

Adding in 2mm of Z Hop
The z lifts vertically at the end of the wipe just after the final mini retract. The second feature request is the Z should lift diagonally up and inward as part of the move so filament is not drawn from the nozzle but continues to be wiped before moving to the next location.

;WIPE_END
G1 E-0.05000 F2700.000
G1 Z8.720 F9000.000 2mm vertical lift
G1 X139.078 Y151.056
G1 Z6.720 - 2mm vertical drop
G1 E1.00000 F2400.000

[jeremy-wendelken]

Ahh yes I see that travel movement retracing the last bit of the path.
I also see that it lifts Z after performing that movement.

I notice that Cura by default is doing infill before perimeters, and then doing a wipe after the outer perimeter is done.
PrusaSlicer by default does perimeters and then infill, followed by a wipe back across the last infill path.

Is there a chance that doing perimeters last could reduce stringing?
I will have to experiment.

As far as Lift Z goes, I have had some success by setting it to 5 micron (0.05mm).
My thoughts is that this is high enough to reduce most of the scarring, while still being close enough to wipe any residual plastic off the nozzle.

[andrew-benjamin]

As far as Lift Z goes, I have had some success by setting it to 5 micron (0.05mm).
My thoughts is that this is high enough to reduce most of the scarring, while still being close enough to wipe any residual plastic off the nozzle.

If you refer back to my post on 28 Aug 2020 the blobs that build like trees from the side of a print are from filament that has oozed during the travel and these tend to be ~0.5mm diameter so Z lift would need to be larger than this to tolerate oozing. The oozing in this material was due to moisture and drying can resolve the issue but I am keen that the printer path setting suggested could be capable of tolerating moist filament and therefore making the 3D printing process more robust for less experienced users.

[jeremy-wendelken]

Yes I find that tree building occurs especially with PETG and even with filament which I have dried for over 36 hours.
I am only using default retraction of 1.4mm, and I had lift Z at 0mm.

Perhaps if I had lift Z at 0.2mm and print infill before perimeters it could help with that issue?
The lift z would carry the ooze over the perimeter and deposit it in the infill where it can't be seen?
As opposed to dragging it onto the outer perimeter and causing the unsightly tree effect.

Thoughts?

[n8bot]

G1 E-0.02500 F2700.000 - here is the final retraction with the nozzle effectively paused again before the travel.

That move likely triggers no motion whatsoever on your machine. If it does trigger motion, it takes such a small fraction of a second as to be imperceptible. It also occurs not at the "end of the path" but at the end of the wipe -- there is no artifact there, in all likelihood. The wipe while retract feature works surprisingly well, IMO (though I wouldn't say it is mandatory or the be all end all, it just works better than you'd expect).

What the move I quoted is doing, is quickly ensuring the extruder position is where it should be. The algorithm purposely under-calculates the retraction while moving, so as to not go faster than intended. Long story short, I've tested with removing that and it made absolutely no difference at all.