Enhancing pressure advance
-
@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.
*not actually a robot
-
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.
*not actually a robot
-
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...
-
@deckingman said in Enhancing pressure advance:
@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.
BTW, sorry for not acknowledging your findings. I remember reading them as soon as you released them years ago -- maybe the same day. I didn't read the entirety, but I accept your results as valid. Sorry for not responding directly to it earlier. PA does seem to me to apply linearly to different speeds, even down to 6 mm/s.
At the same time, because I'm never sure I understand things totally, I also accepted @dc42's suggestion of non-linearity. I'm not an expert in maths or logic, as he is, so I just assume that he knows something I don't.
Linear, non-linear, whatever... I like how PA works right now. I don't want to change that behaviour at all. I just, now, want to have a "dynamic unretract" based on differing nominal target extruder speeds (or actual top speed, or average speed, or whichever makes the calculations easiest, most efficient, and provides acceptable results).
-
I wonder what @burtoogle is up to. This seems like maybe something that could fit in his Cura release. https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0&lst=
-
@bot I like that approach better than tweaking PA. The reason is that PA is applied to every move so if the extruder advance and retard become asymmetric, we run the risk of having over or under extrusion for the entire print. In theory, asymmetric retract and un-retract could also give the same problem but because there are a lot less of those cycles, then any change in the overall amount of material extruded for any given print will be much less and probably have no significant impact on the overall print quality.
It would be interesting to know if you could use a fixed asymmetric retract/unretract at all speeds in conjunction with a different PA value if necessary. Just because we can already do that using firmware retraction.
For info, one idea that I have on my list of things to try, is build a hot end which will run at near constant pressure. I don't know if you know what an expansion chamber is but essentially it's a chamber separated from the rest of the system via a spring loaded diaphragm. As pressure increases, the diaphragm gets pushed back against the spring and so varies the volume into which the fluid can expand, thus reducing the pressure. Now if I could make one small enough to fit in a hot end.....
-
@deckingman I thought about doing a blanket unretract value that is lower than retract... but, I just don't see how that won't affect the print negatively. Look how much affect it had on this area where it was needed. Now every retraction, even retractions on the perimeters which are supposed to be super nice will have underextrusion (the only feature I care about looking nice are perimeters).
I suppose I will try it, for a larger scale test, but I',m not hopeful that it will work. It will just reverse the problem: now the areas which were previously over-extruded will be fine (which were only a handful of places to begin with) while all other places will be under-extruded.
However, it's worth a shot.
I definitely like your idea of the hot end. Keep us up to date!
-
After waking up today and thinking more about this, I want to change my declaration from "this is definitely slicer territory" to "we should be doing this in firmware."
G-Code from a slicer should represent the least information possible. Both to reduce file size, but also to allow each machine to adjust parameters of Wet Noodle Syndrome (WNS) itself.
So, I think this feature should be added to firmware retraction.
I have seen recently people question the use of firmware retraction over slicer retraction (outside of testing different retraction settings). I think this feature would make firmware retraction a feature very much worth using over slicer retraction, and it would allow the sliced G-code to be more portable (as compared to making this a slicer feature).
@dc42 do you have any thoughts as to why this should or should not be in the hands of the firmware? Not asking you to code this into 2.05.1 or anything. You could implement into 3.0 going forward, though, I suppose.
-
Have you looked into how kisslicer handles nozzle pressure?
-
@Phaedrux I'm embarassed to say no, not yet. I had that on a list to do. In fact, I tried to install it a few weeks back but I could not get past the setup process.
User interface is a very important feature for me. I'm not just trying to achieve really good prints at high-resolution, I'm trying to develop a workflow that I can easily teach other people to replicate with ease. User Interface is important, and Kiss provided me a small enough stumbling block to allow me to fall back to what I know.
I'm not happy with my current slicer. They shall remain unnamed, but they were supposed to have released 5.0 by now!
I will definitely check out Kiss. Do they have this feature, or something like it?
The problem for me with this is the time investment into learning a new slicer and developing new profiles. Extensive testing has already gone into my not 5.0 unnamed slicer profiles, which are now giving me good speed:performance outcomes.
I'll check it out. But adding this to firmware retraction would make the use of any slicer possible while retaining this feature (so long as the slicer can be made to work with FW retraction).
*not actually a robot
-
Kiss uses a calibrated preload setup. It seems to work well, but I, like you, found it very difficult to get past the ocular migraine they're trying to pass as a GUI, and was never able to get it all dialed in.
I've been using the Smartavionics/burtoogle Cura build for quite some time now. It fixes most of my gripes with Cura and has enough knobs to twiddle to get me what I need. It doesn't have the clever tuning procedure wizards that kiss has, but I do like the ability to fine tune speed/accel/jerk/flow for all move types. When you add in the post processing features, change parameters at Z height, modifier meshes, and fine grained control over things like overhangs, supports, bridging settings, and it's quite powerful.
But I digress.
-
@bot I'm testing something on my side. Would you share a test gcode that demonstrates your use case, preferably with many layers. I sorta implemented what you suggested, but it's not that simple in the grand scheme of the firmware, so I would like to make sure I got it right before sharing code and firmware file.
Basically, I took your formula and added some averaging to the computations, since the whole thing has to be time-based to accommodate both long and short moves. Maybe I'm thinking too far, anyways, here are my test results:
Before:
After:
And I'm using a constant value of 0.5 - 0.4 (plus some other time constants because I think I had to).
On the side note: 2.05.1 is so much smoother when running near max step rate and high PA. Good work!
-
@Edgars-Batna Nice work. Are you modifying only the unretract move or are you injecting movement somewhere else? The results look promising!
I can definitely share a gcode file that I am using to troubleshoot this. It's the top part of a real-world print I'm attempting. The problem occurs at the very first move after the skirt (which made it convenient for testing), but it also happens at other spots in the file where a slow perimeter is preceded by a fast print move like support or infill, namely on layers form about 94 and up, where the tops of the letters are being formed as individual islands.
*not actually a robot
