Enhancing pressure advance
-
@bot Yes, I wasn't suggesting anything extreme - just a slightly higher PA than you are using. Thinking about it some more, at the low speed of 6mm/sec there may not be any pressure build up so no compensation required (which is what you are suggesting happens anyway). Therefore, the pressure effect that you are seeing can only be residual pressure from the previous 50mm/sec move, which isn't quite being compensated for. I can't think of any reason why the pressure effect of the previous high speed move would be any different if the next move is a slow speed one or a high speed one. Just that with a high speed move, the carriage accelerates faster so the over extrusion at the start of the next move isn't as noticeable as it is when the next move is a slow speed one.
But we don't really know what happens with pressure inside a hot end so any theories can only be speculative. Do you notice any difference in temperature at the transition between the high speed infill and the slow speed perimeter? Just wondering if the heater is using a higher value PWM to maintain the temperature for the flow rate require for 50mm/sec which is then too high for the flow rate at 6mm/sec, so there is a "heat soak" effect which changes the pressure before the PID algorithm re-adjusts the PWM value and brings the temperature back down. In which case, that would explain why there is a difference in pressure if a high speed move is followed by a slow speed move as opposed to another high speed move. On the other hand, this could just be the ramblings or a deranged old man.....
-
@bot said in Enhancing pressure advance:
The perimeter is below the jerk speed, so PA doesn't do anything while printing the perimeter except for during the first tiny spec of acceleration from 0 to perimeter speed. I can use jerk policy 1 to control that but for now I'm aiming to relieve pressure between G1 commands of differing feedrates.
It could well be ooze. I can imagine filament going slightly up the melt chamber with enough pressure, since it's slightly wider than filament.
Also, maybe the problem solves itself with what dc42 suggested...
Higher feedrate, higher PA. It would be interesting to conduct the test he suggested in a controlled manner which we can validate on multiple printers. My gut feeling is that he's right and that the PA tuning as we know it is just half the story. -
@Edgars-Batna said in Enhancing pressure advance:
Also, maybe the problem solves itself with what dc42 suggested... Higher feedrate, higher PA
Actually, I think it's more likely to need reducing PA as the speed increases.
-
@dc42 said in Enhancing pressure advance:
@Edgars-Batna said in Enhancing pressure advance:
Also, maybe the problem solves itself with what dc42 suggested... Higher feedrate, higher PA
Actually, I think it's more likely to need reducing PA as the speed increases.
Fixed. We shouldn't assume before testing tho.
-
Back in January 2018 I attempted to evaluate extruder pressure. At that time, there was an issue with pressure advance and multiple extruders causing (seeming random) jerky carriage movement when printing curves which meant that I couldn't use PA for actual printing. But I did manage to evaluate it by doing long (300mm), straight moves. I found that the same pressure advance setting worked well for all speeds between 40 and 300 mm/sec. It also seemed that there was a linear relationship between speed and pressure but I only tested within that range of 40 to 300 mm/sec print speed. The tests were all done using a Diamond hot end with multiple extruders feeding a single nozzle via multiple melt chambers so it might/or might not be relevant to a single extruder feeding through a single melt chamber.
Most people ignored that piece of work at the time and have continued to ignore it every since, but here is a link describing the methodology and results if anyone is interested. https://somei3deas.wordpress.com/2018/01/15/an-attempt-to-investigate-pressure-in-the-extrusion-system-with-a-diamond-hot-end/
-
@deckingman I think that the pressure required to extrude at 50 mm/s is higher than the pressure required to extrude at 6 mm/s. Even though PA is adjusting pressure at the end of the 50 mm/s move, it's not adjusting it down to the pressure required to print 6 mm/s, it's adjusting it to the pressure required to print at 50 mm/s.
So like, we need pressure advance advance! Something to correct when going in between two pressures.
Now, I know you don't like speculation about pressure, but for a given orifice, the only way to increase volumetric flow is to increase pressure (riight?) so we KNOW that the ideal pressure of the 6 mm/s move is lower than the ideal pressure of the 50 mm/s move, whatever that pressure may be.
@Edgars-Batna I agree that part of the pressure fluctuation that we're trying to eradicate is caused by the filament "back-flowing" up out of the melt chamber towards the extruder gear. This is obvious, because when you pull out the filament it has the characteristic plug shape (yes, I'm using an e3d v6). All the CAD data from e3d verifies what you said: the channel is wider than the filament. This was what I was referring to when I said:
I have some theories as to why that is, but they're probably wrong so I will keep them to myself.
It seems like the fact that the melt can flow back UP, the wrong way, could lead to an asymmetric pressure adjustment requirement. I'm not positive if this is true, and for the moment I want to assume that we are dealing with a symmetric problem.
@dc42 I think you could be right that less PA is needed at higher speeds. But, even with PA disabled completely, I get this over-extrusion when switching to a low feed rate. I mean this to say that the problem isn't entirely caused by PA being too high for the print speed.
In fact, with the print settings I'm using, there are only two speeds: 50 mm/s and 6 mm/s. Since the jerk speed (in these test cases) is higher than the commanded perimeter feedrate, PA is only being applied to the high speed moves and so a single value does capture the needed cases for this. If someone is using many different feedrates in the print, all being applicable to PA, then maybe a slower rate could be needed. I'm not sure.
But do you think the suggestion I made is possible? Do you think it is likely to help this situation? Could it hurt this situation, or others which I'm not thinking of?
One edge case which may need attention for my proposal would be moves that have no other print move after it. Does this new PA adjustment get applied? I guess not. I guess the new adjustment could be applied immediately BEFORE a new print line, if the print line before it had a different feedrate associated with it (inherited or commanded).
adjusted_extruder_position = current_extruder_position + new_constant * (second_move_speed - first_move_speed)
Also, of note, that this proposed addition to PA wouldn't need the adjustment to be made instantly, like with the current form of PA. We could choose a moment between moves to briefly pause, or do it during the travel move (even if it's microscopic).
I guess this would cause problems in the case that a single printed feature is chopped up into different feedrates, but is that a real use case? Usually, we would always have a chance to take a moment to apply adjustment between gcode lines of differing feedrates, no?
-
@bot said in Enhancing pressure advance:
@deckingman I think that the pressure required to extrude at 50 mm/s is higher than the pressure required to extrude at 6 mm/s. Even though PA is adjusting pressure at the end of the 50 mm/s move, it's not adjusting it down to the pressure required to print 6 mm/s, it's adjusting it to the pressure required to print at 50 mm/s.
I don't believe PA works like that. I believe that the amount of extruder advance and retard varies with print speed, so you will get a difference in compensation between 50 and 6 mm/sec.
Which is why I bought the test work that I did previously, to your attention. If you care to take a gander at it, you'll see that there appears to be a linear relationship between speed and pressure. Also, the same pressure advance setting worked equally well between those print speeds of 40 and 300 mm/sec. I believe that DC said that pressure advance assumes just such a linear relationship which explains why the same setting will work across a range of speeds.
What isn't known is whether that linear relationship of pressure vs speed which I saw between speeds of 40 and 300 mm/sec can be extrapolated down to speeds as low as 6mm/sec. Without testing, we can only speculate. I could test it but my printer is currently in bits. Besides, it seems that I'm wasting my time in any case as nobody takes much notice of my findings.
-
@deckingman said in Enhancing pressure advance:
What isn't known is whether that linear relationship of pressure vs speed which I saw between speeds of 40 and 300 mm/sec can be extrapolated down to speeds as low as 6mm/sec. Without testing, we can only speculate. I could test it but my printer is currently in bits. Besides, it seems that I'm wasting my time in any case as nobody takes much notice of my findings.
Unless I replace moving parts every day, the slack in push fittings destroys the linear relationship after a few high speed prints. I could obviously just keep replacing parts, but that's expensive. If I keep the worn parts then I can print for hundreds more hours, but there's tons of asymmetric slack so that PA is around 1.25 ish, plus at high speeds PA needs to get higher. We shouldn't go too narrow on this; it's not just one or the other thing at work, especially when mechanics of every printer are different.
-
@deckingman the only thing that PA depends on is extruder ACCELERATION. So, a faster move will have more PA only because it accelerates and decelerates more. Of course there is a differnece in compensation, but it doesn't compensate for that difference... get it?
50 mm/s requires pressure X
6 mm/s requires pressure Y
The delta between X and Y is never compensated for. A generalized retraction attempts to do so, but all retractions are the same so you either retract for the less-common case of X to Y or you retract for X to X or Y to Y.
-
@bot said in Enhancing pressure advance:
@deckingman the only thing that PA depends on is extruder ACCELERATION. So, a faster move will have more PA only because it accelerates and decelerates more. Of course there is a differnece in compensation, but it doesn't compensate for that difference... get it?
50 mm/s requires pressure X
6 mm/s requires pressure Y
The delta between X and Y is never compensated for. A generalized retraction attempts to do so, but all retractions are the same so you either retract for the less-common case of X to Y or you retract for X to X or Y to Y.
I think the only thing missing is that the Duet gradually slows down to the start speed of the next move to equalize pressure BEFORE travel. Having an extra stop during travel or retracting at start of the move would either create ooze or wouldn't work with the unpredictable "plug" in the hot end in my view. Could this be easy to implement? Just set the end speed of last print move to the start speed of the next print move. Almost one-liner...
-
@Edgars-Batna I see what you're saying, but I think it's kinda different.
Every retraction doesn't eliminate the pressure, because every retraction gives back the same amount of filament as it retracted (in most cases...).
Bringing the print head to a stand still brings the extruder to a stand still, yes. But there is still residual pressure.
Pressure advance adjusts the pressure only based on the acceleration. So, yes, the pressure doesn't BUILD to the end of the move, but if it were artificially lowered beyond "ideal" it would underextrude.
What we want to do is bring the mythical pressure to BELOW the ideal threshold for 50 mm/s, but only AFTER we have printed the 50 mm/s, not WHILE we are...
-
@bot said in Enhancing pressure advance:
@Edgars-Batna I see what you're saying, but I think it's kinda different.
Pressure advance adjusts the pressure only based on the acceleration. So, yes, the pressure doesn't BUILD to the end of the move, but if it were artificially lowered beyond "ideal" it would underextrude.What we want to do is bring the mythical pressure to BELOW the ideal threshold for 50 mm/s, but only AFTER we have printed the 50 mm/s, not WHILE we are...
I'm not sure if we're talking about the same thing. Can you explain to me why reducing 50mm/s move speed with PA would be a problem? PA would take care of it and equalize the extrusion for it to have no effect. Isn't it what you're suggesting - reduce pressure to accommodate 6mm/s after a 50mm/s move? PA already takes extrusion amount into consideration, since with more extrusion there is more acceleration naturally.
-
In theory, PA should mean that one move finishes with zero residual pressure and the next one starts at that same residual pressure of zero. In which case, the speed of each individual move should be irrelevant. PA applies a different amount of extruder advance or retard depending on print speed so in theory, there is no "delta" pressure at the boundary between print moves. But what might balls that up is "jerk", because the print head doesn't come to a standstill between print moves, and so neither does the extruder.
But there is just too much speculation and not enough actual data for any of us to make any sort of informed judgement. So before we move too far away from scientific or engineering practice and into the realms of unsubstantiated belief, I'll politely duck out and leave you gents to it.
-
Perhaps the relationship isn't linear, like dc42 suggested earlier, and that accounts for the apparent residual pressure.
Though, we are doing so many approximations and "dead reckoning" in the way we apply PA right now, what harm would it do to allow an extra parameter that also accounts for an apparent observed residual pressure?
Because, the way pressure advance works now is really good -- if all moves are the the same or similar print speeds. So I want to keep that behaviour. The approximation is good enough. I just think we could go further with the approximation, mimicking non-linearity.
Let's call it dynamic retraction. The retraction amount (or unretraction amount) can be adjusted to advance or adjust (I don't like using the R word, so I use adjust -- call me a SJW) based on the difference in move speed. Ignore pressure. Let's pretend we're not trying to account for pressure and just adding on another "fix" on top of jerk, segments, PA, etc.
@Edgars-Batna I'm not saying to reduce the PRINT speed... PA reduces the extruder speed, not the XY feedrate, unless applying the amount of PA requested exceeds the extruder jerk, then the x/y acceleration is adjusted. I'm saying to adjust the extruder position during retraction when moving from two vastly different feedrates.
-
I might as well mention, I also tried jerk policy 1, which in this case would have the effect of completely removing all acceleration and deceleration from the 6 mm/s move, and thus removing all PA during that move, and this overextrusion at the beginning did still occur.
I think the residual pressure comes down to the fact that PA doesn't ever actually have to reduce the pressure to zero. It reduces (or increases) the pressure back to nominal for the current speed, and only at times that it is actually extruding. Then, immediately, a retraction occurs. This ends the flow, not the pressure advance. At least, I've never had so much PA applied that it caused additional retraction (at least not that I'm aware of -- I'm limited by my extruder jerk to how much I can actually apply).
-
@bot said in Enhancing pressure advance:
@Edgars-Batna I'm not saying to reduce the PRINT speed... PA reduces the extruder speed, not the XY feedrate, unless applying the amount of PA requested exceeds the extruder jerk, then the x/y acceleration is adjusted. I'm saying to adjust the extruder position during retraction when moving from two vastly different feedrates.
The speeds can be matched up to equalize the feedrate. It's a computation detail.
Approximations are fine. Tinkering around to get it right is also fine. It might be a time waste in the grand universal equation scheme of things, but whatever. After all, 3D printing is itself based on approximations, so add or remove one or a thousand - doesn't change the soup overall.
I got 2.05.1 to compile today, might see what I can do for fun.
-
@Edgars-Batna Right. Actually, maybe the solution is completely different and includes dyanmically adjusting speed like you say. However, since this phenomenon occurs between two discontinuous moves, I feel like a more rapid adjustment of extruder position would solve the problem.
I feel like the rapid adjustment between print moves compliments the current behaviour of PA, and doesn't "violate" any of the principles we are currently using -- it simply enhances them.
It combines retraction and Pressure Advance. A match made in heaven.
-
Dun duda DUN ( the sound of me tooting my own horn)
I performed some tests, and I think dynamic retraction adjustment is something I want very very much. Though, it should/could be a slicer setting, there's no reason we can't use firmware retraction to do the same thing (or even adjust slicer retraction values on the fly).
Basically, here are the results first:
First, I chose a PA value which gave basically exactly the results I wanted for the skirt. It's close enough, if not perfect. But, the residual pressure was still very much there.
So, I adjusted the single unretraction move that preceded the perimeter. I made the unretraction different based on this formula:
Adjusted_Unretract_Distance = Nominal_unretract_distance + (Target_Extruder_Speed_of_Second_Move - Target_Extruder_Speed_of_First_Move) * New_Constant
In these tests, I found 0.48 to be about right for the constant, and worked well enough with both varying cases to seem generalized enough for our uses.
This changed my unretract move from 1.0 mm to about 0.75 mm for the 100-24 example.
Any thoughts?
The target extruder speed can be calculated roughly just from a G1 line. We don't need to be perfect, just close enough.
-
This seems like something that could have been implemented pretty easily with the Pathio slicer and it's scripting engine.
-
@Phaedrux Nice! I never tried Pathio, but I hear it has stalled.
I wish I had the ability to code. I would be making changes to slicers, to firmware, everything!
I'm trying to learn how slowly. I've loaded the rrf 2.05.1 source into VScode because I'm stubborn and don't want to listen to instructions on setting it up in eclipse... but I'm missing literally every dependancy, a compiler, and a clue about what to do now...
I digress. This is definitely slicer territory...