Feature request: Airplane Z lift

[burner-]

Current prblem:
Currently z axis of travel are planar or you can add z lift to travel. Also z lift with wipe is possible. With travel at plane without zlift with high speed can cause damage for printer, head or print when it hits to blobs. With large prints & nozzles it is some times quite rough ride when extruder travel long distances without z lift. Z lift helps for that but it slow down prints and with large nozzles it cause even more blobs and random failures to prints because when you hit 200-300mm/s to blob with 1.2mm nozzle it is quite hard collision.

Solution:
Solution for that would be make dynamic sine wave or ballistic shape z lift. It can work by calculating time for xy acceleration from print speed to max travel speed and calculating z acceleration so that lift will take same time than zy acceleration but it is made simultaneously with xy travel. Because x&y need time to accelerate it will give soft lift ramp at same time. When x/y speed is increased to dangerously high also z is already lifted to safe distance. When travel start slow down also z will start come back to print plane. Basically Z height is then just factored from current travel speed. That way z lift wont make blobs and it will not slow down print at all and it will reduce failure possibility with high travel speeds.

[CCS86]

I think it's an interesting feature.

It seems like it could be more simply implemented where you define a lift height, and an accel/decel length. Then any retracted travel move greater than: 2 * accel_length, would be broken up into 3 moves:

XYZ move from starting position, to the lift height, and in the direction of the finish point, for a distance of accel_length
The remainder of the XY move
XYZ move to final position

I know this deviates from your suggestion, but IMO above some clearance plane, further lifting adds no additional benefit. You really just need to clear any plastic erroneously above the current layer plane, due to cupping, over-extrusion, etc.

[robthide37]

think this is an amazing idea

[burner-]

CCS86 you are right. There is no point to make it infinite height lift. Anyway that should be more like max lift cap instead of static plane (as current is). I think it does not make much different for end result where from that ramp is calculated as far end result is mostly same ramp angle at all lifts regardless lenght of travel. If travel is very short then it just does not reach full lift. At the end what ever is easiest/robust way to do it is most likely best. At least better than current straight lift what slow down printing and leave blobs where other travels can collide.

[burner-]

I found this kind conversation prusa3d#2507

[supermerill]

I can add a box to enter the zspeed for z-hop, and it will be baked into the xy move.

  ____ 
_/    \__

[robthide37]

did you ever get chance to add this ?

[Goury]

Bump.
Please do.

[mann1861]

Also looking for a feature like this however I prefer the nozzle dropping vertically at the end like standard z hop which means any blobs formed during travel from oozing are hidden inside the object and not deposited externally when crossing the perimeters

[nmw01223]

I raised #2912 - details are there but it appears to be the same as mann1861 is saying above.

However good retraction settings are, especially with PETG, there is some oozing, and any travel ooze builds up as a vertically ascending thick string at the destination perimeter, gradually moving away from the perimeter as it climbs. This occurs because the ooze hits the perimeter on arrival, and then earlier deposits on subsequent arrivals on higher layers. Z hop stops it.

However, Z hop tends to pull out thin strings at the travel departure point, so what is needed is no Z hop at departure, Z hop by arrival at destination.

This could be a travel move with no Z hop for set percentage of travel, then rise, then continue to destination, then drop, or alternatively, rise linearly from travel start to destination, then drop.

So, all these desired travel profiles including those that started this issue could be put in place by a single option that allows setting one of a number 'flight profiles' for Z hop.

One further refinement. The amount of Z lift needed is related to travel distance and speed, because the nozzle oozes at a roughly constant rate, over a short or small distance (<20mm) no Z hop is needed, by the time I get to 100mm (travel speed 100mm/s), between 0.2 and 0.4mm is needed. Therefore it would be desirable if the Z hop distance in this case could be specified as mm list per mm travelled.

[simpat1zq]

So I created a dupe feature request #3019 because I didn't see this one. I didn't have much to add, but the picture I threw together might be useful for visualization.

[samuellazea]

any info when could this be made available please?

[robthide37]

curiousif this is still in works?

…

On Fri, Apr 8, 2022 at 8:33 AM mann1861 ***@***.***> wrote: Also looking for a feature like this however I prefer the nozzle dropping vertically at the end like standard z hop which means any blobs formed during travel from oozing are hidden inside the object and not deposited externally when crossing the perimeters — Reply to this email directly, view it on GitHub <#927 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APNYI6FJRUXGBJXFTI73X5TVEARTFANCNFSM4WZXA2GA> . You are receiving this because you commented.Message ID: ***@***.***>

[bamhm182]

Just commenting to say I would also like this feature.

[nmw01223]

... but the picture I threw together might be useful for visualization ...

It would be a really useful feature, I can see no way of dealing with the issue without it at the moment.

However of your three diagrams, not sure the bottom is actually necessary (doing a steep climb before a halfway perimeter). The reason I think this is that as far as I can see, regardless of the amount of retraction etc, there is a steady ooze to some degree during travel. The rate of ooze is probably dependant on (1) what filament it is (PETG especially bad), (2) how hot it is (ie how easily it flows). How much actually oozes therefore depends on how long the move is, which in turn is proportional to travel distance and travel speed. Therefore, if there was a halfway perimeter, only half the oozing would have happened by that point, so a steady climb from start to end should still do it.

So, in my opinion, what is needed is not a fixed 'Z rise to Z by end of move' figure, but a 'mm rise per mm travel' figure, the slope in other words. Might be quite small - a gentle slope - maybe 0.25mm per 25mm travel, ie 1% slope, or perhaps double that, don't know.

But, it would be really useful to have.

[burner-]

https://youtu.be/OAXi_apvgl4 looks that there is now also video where whole thing is explained

[burner-]

Also looking for a feature like this however I prefer the nozzle dropping vertically at the end like standard z hop which means any blobs formed during travel from oozing are hidden inside the object and not deposited externally when crossing the perimeters

it will be safer but also slow down printing. Specially with long bownden E speed and accel with PA is already major factor for printing speed. That why I suggest that landing ramp is optional.

[nmw01223]

I guess there are different people who are trying to solve different problems, where Z hop could be a factor. So maybe there is a desire for different Z hop profiles depending on what one is trying to solve. I've never had issues with the nozzle hitting the print on a move, but I have with blobs being deposited at the end of a move, hence the desire for a ramp up and vertical drop. Depends what is being printed, the filament and circumstances, I'd guess.

…

On 21 Jan 2023, 10:42, at 10:42, Tapio Haapala ***@***.***> wrote: > Also looking for a feature like this however I prefer the nozzle dropping vertically at the end like standard z hop which means any blobs formed during travel from oozing are hidden inside the object and not deposited externally when crossing the perimeters it will be safer but also slow down printing. Specially with long bownden E speed and accel with PA is already major factor for printing speed. That why I suggest that landing ramp is optional. -- Reply to this email directly or view it on GitHub: #927 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[jernejp21]

I have implemented one of the proposed solution on my fork of SuperSlicer. Branch is called airplane_z_lift-WAL. For Linux, appimage is attached under releases. SuperSlicer version should be "Airplane Z Lift - WAL". Under Help -> System Info, check that version is "2.4.58.5-airplane-WAL". WAL stands for Wipe And Lift.

Under Printer Settings and Extruder, there is new offset parameter - XY offset. Z offset is previous Lift Z.

How it works is, you enter Z offset and XY offset. XY offset is how much you go towards next point, before you lift the nozzle. Lift is vertical, but it isn't at a printed object.

This is how it looks XY offset = 1 mm

And XY offset = 2 mm

I would appreciate if people would try this feature and comment if it's good or not. I plan to do also lift in the middle of two points - distance will be calculated automatically. When that version is available, I will comment.

[burner-]

I would appreciate if people would try this feature and comment if it's good or not. I plan to do also lift in the middle of two points - distance will be calculated automatically. When that version is available, I will comment.

This feature will most probably resolve some of problems but it will also give huge speed penalty because there is multiple movement stops and accel/deaccel ramps at that movement. Even normal z lift is total killer for printing speed and this will make that even worse.
Yes it most probably will help to original problem. But another hand I am quite worried that if it got implemented that way will it be "good enought" and no one will bother implement it properly later. I think that @supermerill suggestion of banking would be better.
If stringing is one of problems it may give benefit to have possibility to add hosizontal wipe lenght before banking. But anyway even with wipe I prefer to see that implementation wont force full XY stop at Z move.

And I agree with @nmw01223 that there is multiple different things what this same feature can resolve. But it needs to implement right that it resolve those all and is not tradeoff with speed or quality.

So my suggestion is that lets throw my original idea of ballistic ramps away. Take @jernejp21 idea of configurable ZY offset (wipe lenght) and @supermerill linear ramps and add configurable climb and land ratio to that (1 normal horizontal z lift, 0.5 is 45degrees and 0 wont rise at all and so on). So by setting 0 to wipe and 1 to both rates it is just normal z lift.
It will looks then something like this

[robthide37]

Hey i have been having Merril help with a custom version of super slicer that i am making for my machines and commercial clients i was seeing if you would be interested in letting me play you to develop some features like this or even just debug and help since merril is very busy so its hard sometimes to keep things moving forward. I plan on making things better for idex and toolchangers mainly but also have started adding some stuff for print quality etc . If interested lmk.

…

On Sun, Jan 22, 2023 at 6:30 AM Tapio Haapala ***@***.***> wrote: I would appreciate if people would try this feature and comment if it's good or not. I plan to do also lift in the middle of two points - distance will be calculated automatically. When that version is available, I will comment. This feature will most probably resolve some of problems but it will also give huge speed penalty because there is multiple movement stops and accel/deaccel ramps at that movement. Even normal z lift is total killer for printing speed and this will make that even worse. Yes it most probably will help to original problem. But another hand I am quite worried that if it got implemented that way will it be "good enought" and no one will bother implement it properly later. I think that @supermerill <https://github.com/supermerill> suggestion of banking would be better. If stringing is one of problems it may give benefit to have possibility to add hosizontal wipe lenght before banking. But anyway even with wipe I prefer to see that implementation wont force full XY stop at Z move. And I agree with @nmw01223 <https://github.com/nmw01223> that there is multiple different things what this same feature can resolve. But it needs to implement right that it resolve those all and is not tradeoff with speed or quality. So my suggestion is that lets throw my original idea of ballistic ramps away. Take @jernejp21 <https://github.com/jernejp21> idea of configurable ZY offset (wipe lenght) and @supermerill <https://github.com/supermerill> linear ramps and add configurable climb and land ratio to that (1 normal horizontal z lift, 0.5 is 45degrees and 0 wont rise at all and so on). So by setting 0 to wipe and both rates it is just normal z lift. It will looks then something like this [image: image] <https://user-images.githubusercontent.com/3836115/213913462-dc112824-6e41-44cd-ae4c-21e331919fc2.png> — Reply to this email directly, view it on GitHub <#927 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APNYI6B7XNVZ7ICRC6CQOPLWTUK67ANCNFSM4WZXA2GA> . You are receiving this because you commented.Message ID: ***@***.***>

[jernejp21]

@burner Your idea with climb rate sound good! I think it would be possible to implement it like this:

• remove z lift from GCode::retract()
• add z travel to "acceleration to travel" and "decel to extrusion"

Hop from one point to another is now made by 2 moves - "acceleration to travel" and "decel to extrusion". If climb and land rate are 45°, it's easy to just calculate new point. Instead of gcode looking like G1 Xxx Yyy Fffff, we can add XYZ travel - G1 Xxx Yyy Zzz Fffff. If you want different climb and land rates, you will have to generate 2 points for "acceleration to travel" and 2 points for "decel to extrusion".

In the code it says GCodeWriter::travel_to_xyz needs fixing (speed calculation). We need to decide on the speed of XYZ travel. Is XYZ speed the same as XY? For example if you have rapid move G0 X1 Y1 Z1, is this the same as G1 X1 Y1 Z1 Fffff or is it G1 X1 Y1 Fffff, G1 Z1 Fffff? If we don't want to loose speed, XYZ movement should have the same speed as XY movement.

[jernejp21]

Added Climb rate and Land rate. New version for linux here.
All movements use "travel speed".

Climbing goes from XY offset to the point of acceleration to travel. Landing goes from decel to extrusion to the point where extrusion starts again.

Climb rate 1; Land rate 1;

Climb rate 0.5; Land rate 1;

Climb rate 0.5; Land rate 0.5;

Climb rate 0; Land rate 0.2;

[burner-]

@burner Your idea with climb rate sound good! I think it would be possible to implement it like this:

• remove z lift from GCode::retract()
• add z travel to "acceleration to travel" and "decel to extrusion"

Hop from one point to another is now made by 2 moves - "acceleration to travel" and "decel to extrusion". If climb and land rate are 45°, it's easy to just calculate new point. Instead of gcode looking like G1 Xxx Yyy Fffff, we can add XYZ travel - G1 Xxx Yyy Zzz Fffff. If you want different climb and land rates, you will have to generate 2 points for "acceleration to travel" and 2 points for "decel to extrusion".

In the code it says GCodeWriter::travel_to_xyz needs fixing (speed calculation). We need to decide on the speed of XYZ travel. Is XYZ speed the same as XY? For example if you have rapid move G0 X1 Y1 Z1, is this the same as G1 X1 Y1 Z1 Fffff or is it G1 X1 Y1 Fffff, G1 Z1 Fffff? If we don't want to loose speed, XYZ movement should have the same speed as XY movement.

I am not totally sure what you mean (there is language barrier because english is not my native language) Anyway if you calculate rate from lenght instead of speed then it is more correlated to degrees. Naturally then user need to know what is maximum suitable climb/land rate what them can use without affecting to speed. But most probably it will still give more predictable end result than speed rate and is easier to implement? Then at F value we can use just normal max travel speeds and machine keep care of accels. If I understand right those images was made with speed rate?
By my understanding with lenght rate 0.5 & 0.5 should look like this:

Most probably at many machines 0.5 & 0.5 will cause some slow down depending of accels.
Ah btw with rate I mean ratio. So if Z lift is 2mm then 0.5 is 2mm to XY vector and 2mm to Z vector at same movement. 1 is just 2mm to Z vector. 0.25 is 2mm to Z and 4mm to XY vector. And 0 basically disable Z lift because climb lenght is then infinite.
That also allow remove whole old Z lift because user can just use 1 & 1 to get old style lift.

[jernejp21]

English also isn't my native language. I will try to explain again what I implemented and what the numbers mean.

Black line shows how Z lift works now.

• From base it goes to P1. Feed rate is travel speed z.
• From P1 to P2 speed is travel speed xy and acceleration is travel acceleration (parameters are located in Print Settings -> Speed). Move from P1 to P2 is called "acceleration to travel". You will find this comment in G-gode.
• Move from P2 to P3 is called "decel to extrusion". Again comment in G-code. Speed is travel speed xy and acceleration is travel acceleration.
• Then the nozzle moves down to base again with Z feed rate.

In my implementation:

• Climb rate 1 is red line. Speed and accelerations are the same as current Z lift. They don't change. Climb rate 1 represents move from base under P1 to P2. This is actually 3D move, since all 3 axes (X, Y and Z) move at the same time.
• Climb rate 0.5 is green line. Nozzle climbs to Z lift half of distance between P2 and P1. This is also 3D move.
• Climb rate 0 is blue line. Nozzle goes to Z lift point P1.

What climb rate represents is distance between P1 and P2. With climb rate 1, we reach Z lift in point P2. With climb rate 0.5, we reach Z lift in The middle of P1 and P2. With climb rate 0, we reach Z lift in point P1.

The same logic applies for land rate. I used this logic, because point P2 is always present. It was easier for me to use it, than to implement new point calculations.

I hope this better explains my implementation.

[simpat1zq]

Just a suggestion, but I don't think it should start moving upward immediately. I think it should do that only after it moves off of P1 horizontally.

[jernejp21]

@simpat1zq

Just a suggestion, but I don't think it should start moving upward immediately. I think it should do that only after it moves off of P1 horizontally.

That is what XY offset parameter does. It goes horizontally towards P2, before it stars climbing. Illustration is just for explaining climb and land rate.

[burner-]

@jernejp21 ok I think I understand. I am quite worried that if we touch to feed we will get quite unpredictable results and cause slow down for print. After all at optimal situation machine always do travels with full speed & accel. What why I try suggest that rate is only ratio of lenght A and B. Then we need only touch to XY coordinate but F will be same as it was at traditional Z lift.

By my undesrstanding at this case if machine Z max feed and deaccel is big enough P2 point wont cause slow down at all because XY speed wont change at it. Only Z will do accel and deaccel ramp. Naturally if Z travel speed is too slow machine will cause slow down also for XY when rate is over 0.5.
If you use rate as feed rate it will cause that every time when user change travel speed also ramp lenght will change (it will behave different way than other features). If you use it as lenght ratio then only climb/landing rate affect to path (and at some cases to speed) but travel speed affect only to speed. I am worried that if we start add features what can modify paths depending of what kind travel or print speed is used, that will cause situation where people have very hard time to get their printers tuned properly.

[nmw01223]

That is all very interesting, and goes quite some way towards solving the issues, but it depends which particular issue is trying to be solved. The issue I am most interested in is avoiding blobs being deposited at the end of travel when it crosses a perimeter, and not having a set Z hop from the start to assist with that, because it causes stringing. (Of the two, I prefer the stringing at the start to the blob at the end, easier to remove). Therefore, it seems to me that in relation to that specific issue which is caused by oozing while travelling, (1) no Z lift at all is desirable at the start of the travel, (2) the rate of Z lift during travel should be able to be set to match or just exceed the ooze rate - and it's a constant rate for any given filament and temperature and (3) the resultant total Z lift should therefore be determined solely by travel time - travel distance / travel speed - and therefore in this case not be a settable figure. It may well be that retraction before travel delays the start of oozing (it won't stop it for reasons that are not clear to me at the moment), and in that case if travel time is less than some limit, no Z lift at all is desirable, or that it only start to lift after that time. So it's a sawtooth, possibly with a flat first stage, then a gradual climb at a constant rate, followed by vertical drop. That seems to me to model what goes on in the case of this particular issue. The problem is, there are quite a few issues from different people, and they all have different solutions. What has been implemented therefore is not precisely that, but goes quite a long way towards it. I look forward to trying it.

…

On 23 Jan 2023, 11:50, at 11:50, Tapio Haapala ***@***.***> wrote: @jernejp21 ok I think I understand. I am quite worried that if we touch to feed we will get quite unpredictable results and cause slow down for print. After all at optimal situation machine always do travels with full speed & accel. What why I try suggest that rate is only ratio of lenght A and B. Then we need only touch to XY coordinate but F will be same as it was at traditional Z lift.  By my undesrstanding at this case if machine Z max feed and deaccel is big enough P2 point wont cause slow down at all because XY speed wont change at it. Only Z will do accel and deaccel ramp. Naturally if Z travel speed is too slow machine will cause slow down also for XY when rate is over 0.5. If you use rate as feed rate it will cause that every time when user change travel speed also ramp lenght will change (it will behave different way than other features). If you use it as lenght ratio then only climb/landing rate affect to path (and at some cases to speed) but travel speed affect only to speed. I am worried that if we start add features what can modify paths depending of what kind travel or print speed is used, that will cause situation where people have very hard time to get their printers tuned properly. -- Reply to this email directly or view it on GitHub: #927 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[burner-]

@nmw01223 well I have try look solution what does not solve only one issue but all releated issues. By my undestanding we are looking solution for following problems:

• oozing from traditional z lift
• blops from traditional z lift
• blops at perimeters without z lift
• high speed extruder collisions at travel moves
• print speed slow down from traditional zlift.

And by my understanding that resolution what we currently have in our hands will solve those all. As @jernejp21 say that XY offset (or wipe as I call it) is not forgotten. But we only try figure out implementation as steps.
Anyway sawtooth may have possible but it is much more complex and can cause slow down & vibrations. Most probably same result is possible to get with "wipe angle" what will force wipe move to anoter direction than travel move. Example 180 will result that it wipe to opposite direction than travel it self. It will cause huge speed penalty for speed at low accel machines but probably give best oozing preventation. 45-90degrees as wipe angle can give compromise at direct drive machines where oozing is not so bad problem and there is more mass at extrudes. 0 will just wipe to same direction than move it self.

[nmw01223]

Well, you must of course do what you think is best for the majority of circumstances. I don't have your level of knowledge on this  but I'm not sure I can quite map your five problems to what I have seen written, but from what I do know, I'm also not quite sure I see complete correlation between the issues and solutions. On the first two, I don't think I've ever seen oozing and blobs from a Z lift. Oozing and blobs, yes, but I don't feel the Z lift is the cause. A lift will tend to start a string because molten filament is sticky stuff, but oozing over time is just what nozzles seem to do, retraction or not. I'm not really clear why but feel it may be to do with filament expansion and thermal time constant. It's probably not as simple as gravity because I've seen a nozzle do it while lying on its side. May be wrong about that, of course. The third is the one I see, and to me the key point about that is the rate of Z lift has to be based on the ooze rate, ie, you wouldn't want to set a specific Z lift value. If the travel was 100mm and it oozed 0.25mm during the move and the travel was 100mm/s, you'd want the Z lift to be just over 0.25mm. But if the distance was 50mm, or the travel speed was 200mm/s, then the Z lift would only need to be half that amount, but conversely, if the move was slower, or the distance longer, it would need to be more. The point being, Z lift needs to be calculated from the distances and speeds, not set. The slope will always be very shallow indeed. On the fourth, maybe I've missed the point, but I see little option but to go straight up and down because you have no idea where a collision may occur on a given print. It depends what bit may curl up etc, and where it is. Might be near, might be far - might be anywhere. On the fifth, well, yes, it does slow a print, and a slope in the direction of travel might help, at the risk of banging into something along the way, see the one above. There is already a wipe, unless I've misunderstood what it does, and I use it. It seems to reduce strings a little bit, not that much. Not sure the direction of wipe would make much difference? Presumably it is the act of moving over a surface with no nozzle pressure that helps stopping pulling out a string, not the direction. In any case, one would have to move in the direction where there is some surface to wipe over. But again this is all just guesswork on my part. It seems to me there are mainly three groups: those who just want to go straight up by a set amount, and down - traditional Z hop. Those who would like to ramp up and down at each end for speed. And those, like me, who want the Z lift to cover the amount of ooze along a travel, then drop vertically. But at any point along the travel there is a Z lift amount which is the greatest of the three, so one way to look at it is to have parameters that allow for all three, and then in calculating the move profile, use the greatest of the three at any point along the travel. However  this is all opinion based on absolutely zero knowledge of the software  and I guess to know more fully about this, I'd need to roll my sleeves up and read the code - C++ I assume - but I'd also guess it's a huge bit of code with a lot of history and there'd be a big learning curve. So really, a large amount of thanks are offered for the work you do.

…

On 23 Jan 2023, 18:30, at 18:30, Tapio Haapala ***@***.***> wrote: @nmw01223 well I have try look solution what does not solve only one issue but all releated issues. By my undestanding we are looking solution for following problems: - oozing from traditional z lift - blops from traditional z lift - blops at perimeters without z lift - high speed extruder collisions at travel moves - print speed slow down from traditional zlift. And by my understanding that resolution what we currently have in our hands will solve those all. As @jernejp21 say that XY offset (or wipe as I call it) is not forgotten. But we only try figure out implementation as steps. Anyway sawtooth may have possible but it is much more complex and can cause slow down & vibrations. Most probably same result is possible to get with "wipe angle" what will force wipe move to anoter direction than travel move. Example 180 will result that it wipe to opposite direction than travel it self. It will cause huge speed penalty for speed at low accel machines but probably give best oozing preventation. 45-90degrees as wipe angle can give compromise at direct drive machines where oozing is not so bad problem and there is more mass at extrudes. 0 will just wipe to same direction than move it self. -- Reply to this email directly or view it on GitHub: #927 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[jernejp21]

@nmw01223

The third is the one I see, and to me the key point about that is the rate of Z lift has to be based on the ooze rate, ie, you wouldn't want to set a specific Z lift value. If the travel was 100mm and it oozed 0.25mm during the move and the travel was 100mm/s, you'd want the Z lift to be just over 0.25mm. But if the distance was 50mm, or the travel speed was 200mm/s, then the Z lift would only need to be half that amount, but conversely, if the move was slower, or the distance longer, it would need to be more. The point being, Z lift needs to be calculated from the distances and speeds, not set. The slope will always be very shallow indeed.

Do you have an equation how ooze rate, travel distance, Z lift and speed are related? I don't know about this relation. If you have any articles or videos, please share.

And before going into more theory, I would suggest that people test the new feature out. It might work out, it might be really bad. I cannot currently test this out (I'm in the process of moving and printers are already packed). It would be better to get some results, analyze them and afterwards see if speeds or retractions need changing.

[nmw01223]

No I don't, I just have some thoughts about it having watched it happening, but it is quite anecdotal. It seems to me that after an extrude is finished, the filament just keeps oozing out at a rate for some time, then it stops. Even if there is a really big retract, it still does it. Why? No idea. I don't think it's quite as simple as just gravity causing it to dribble out, because when I was making changes at one point and the nozzle was on its side, it still did it. So I assume it is pressure in the nozzle. I wonder if it is caused by filament gradually heating and expending as it moves from the extruder gears to the nozzle. So, extrusion is going on, filament is moving down across the temperature gradient from extruder gear to nozzle, and heating up. But not instantaneously, there's a thermal time constant. So when extrusion stops, the filament continues to heat and expand until it meets thermal equilibrium and during that period, filament keeps being pushed out of the nozzle by the expansion, but once in equilibrium, it stops. Now, that might all be total nonsense. I have never really looked into it properly, just watched what it is doing while I am using it normally. It's just an unproven theory. However, if approximately right, over the short period of a travel move one could probably assume it oozes at a constant speed. (Even if it was gravity, the same would apply). If so, say one observed it oozes at 40mm per minute, or 0.667mm per sec (I'm just making this up as an example), then that would be the Z lift rate one would want while travelling, so every XY travel move would also require a Z component to lift the nozzle at that rate. The slope would be so shallow that worrying about the overall move speed being slightly increased on the diagonal would not really be necessary.. Once the destination is reached, there would need to be an extra Z downwards move of the accumulated lift to bring it back to the right height again. So, the parameter to set in setup would be the ooze rate, not a lift value. However, as I said, this is all just a theory based on guesswork and some casual observation, so might be wrong, and in any case, I have no idea about the software structure and how easy that would be to implement, even if there was a desire to do so. As a test it might be possible to post process some gcode, but that would depend if the travel moves could easily be picked out. All just a theory.

…

On 24 Jan 2023, 00:26, at 00:26, Jernej Pangerc ***@***.***> wrote: @nmw01223 > The third is the one I see, and to me the key point about that is the rate of Z lift has to be based on the ooze rate, ie, you wouldn't want to set a specific Z lift value. If the travel was 100mm and it oozed 0.25mm during the move and the travel was 100mm/s, you'd want the Z lift to be just over 0.25mm. But if the distance was 50mm, or the travel speed was 200mm/s, then the Z lift would only need to be half that amount, but conversely, if the move was slower, or the distance longer, it would need to be more. The point being, Z lift needs to be calculated from the distances and speeds, not set. The slope will always be very shallow indeed. Do you have an equation how ooze rate, travel distance, Z lift and speed are related? I don't know about this relation. If you have any articles or videos, please share. And before going into more theory, I would suggest that people test the new feature out. It might work out, it might be really bad. I cannot currently test this out (I'm in the process of moving and printers are already packed). It would be better to get some results, analyze them and afterwards see if speeds or retractions need changing. -- Reply to this email directly or view it on GitHub: #927 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[burner]

@burner Your idea with climb rate sound good! I think it would be possible to implement it like this:

Wrong burner, but I would like that feature in my slicer as well

[nmw01223]

I have been looking into this some more (the bit that concerns me the most - blobs at the end of travel), and I wrote some code to post-process the output gcode. It is only a demonstration and what it does is in concept fairly simple:

• It looks for a horizontal move (G1 with X/Y movement but no Z or E)
• If it is bigger than a settable threshold (5mm for testing), works out the delta XY distance, and from the travel speed, the duration.
• Then from a settable 'filament ooze rate' in mm/min, figures out how much ooze there would be during the travel, and that is the desired Z lift to make sure any ooze clears the perimeter at the destination.
• If that Z lift is above some settable limit, it adds that amount of Z rise to the travel, so now, as it is travelling the nozzle is rising.
• If there is more than one travel segment, it repeats the process.
• When it gets to the final destination just before it is about to extrude and print something, it adds a G1 code to drop Z back to where it was.

There is a bit more subtlety to it than just that, but that is the basic principle.

It has some bugs to be ironed out, but the test results can be seen in the image below:

A section of a PETG print is shown, it is actually two 10mm pillars 75 mm apart, of which just one is shown (not very clearly). So the nozzle is shooting back and forth between the two of them.

In A, this is a normal print and the little structures growing out from the side are the characteristic blob deposits as the nozzle reaches its destination and crosses the perimeter (ooze hitting the perimeter). It has been made to look especially bad by slowing the travel speed, but I find they are usually noticeable to some degree on a long travel move.

In B, some normal Z hop was added. Lo and behold, the structures have gone. Why? the nozzle plus ooze was clear of the perimeter as it crossed so it didn't deposit anything. So far, so good, but some fine wispy strings can be seen. These are pulled out by the vertically rising Z hop before it starts moving off to the other pillar.

C is back to the original, with no Z hop, but post-processed by the test code so the nozzle is rising to match the ooze rate as it travels from source to destination. The result is no little structures, and no strings either.

It is a very simple test, but it does seem to do what is desired. It is certainly not a complete solution, as test code it only looks at very few G codes for a start, but it does seem to me to indicate that some print quality improvement can be made with (optionally) a linearly rising and vertically dropping Z movement on travels. The benefit of this over some form of predefined lift is that it automatically compensates for travel speed and the length of the travel.

[robthide37]

Added Climb rate and Land rate. New version for linux here. All movements use "travel speed".

Climbing goes from XY offset to the point of acceleration to travel. Landing goes from decel to extrusion to the point where extrusion starts again.

Climb rate 1; Land rate 1;

Climb rate 0.5; Land rate 1;

Climb rate 0.5; Land rate 0.5;

Climb rate 0; Land rate 0.2;

Would you be willing to work on my fork that Merril was doing for me ? He has been busy and not doing much with either so i am looking for someone to help and i would compensate you for your time .

[nmw01223]

Added Climb rate and Land rate

That is very interesting. The difference between what you have done and what my post processing has done is that in my case the Z rise is not a fixed amount but is set from an 'ooze rate' and calculated travel time base on speed and acceleration. The reason I did that is the ooze rate seems to depend a lot on the filament - PC being particularly bad for some reason, dribbles all over the place - and how much rise is needed depends on the time, and therefore distance, of the travel.