Enhancing pressure advance
-
100k segments/sec would mean 1200 CPU clocks per segment to read it from SD, check it, parse it, put it in the queue, plan the trajectory, do the kinematics and generate the steps for three or more motors. My gut feeling says 'no way!'. But I might be wrong.
-
@DaBit 100k steps/sec. including microsteps.
-
IIRC it's around 200k steps/sec, with some round 100steps/mm number your minimal "make sense" segment of 0.1mm would be 10 steps, so just for stepping we're talking 20k segments/sec/ Everything else needs to be done too (parsing, pathfinding, buffering..).
I have not run a test with DUET but Smoothieware on comparable cortex M3 32bit LPC1769 (compared to duet2 cortex M4 SAM4E8E that's a bit better but for this purpose more/less same, or duet3 cortex m7 ATSAME70 that's a lot faster) and it can process 2610 "simple" gcodes/second, and that's trough USB (from sd card should be faster, here you have overhead of calculating CRC, ACK-ing every message...). With full calculation, trough USB, controlling laser drawing raster (so very small segments) the team tested successfully 1000 pixels / second if 1 gcode per pixel (it can go 5-10x faster if you compress more pixels into single G-code using non-standard G-code extension available in one of the forks)
-
It occurred to me that the effects of PA were simply seeming to not take effect at extremely high resolution (0.2 mm line width, 0.04 mm layer height). I cranked it up to M572 S0.2 from S0.06 (which is what I use at low reslution).
Surprinsgly... it didn't start going crazy. Granted, I have my extruder limits set correctly (at the actual limits) so I didn't expect things to be too crazy... but at 0.3 mm layer heights with 0.4 mm line widths, 0.2 PA would make thinigs crazy.
I'll report back as to whether a dramatic increase in PA for high resolution is all that is needed to remedy my specific issue.
-
@bot IIRC, a couple of years back, not long after PA was introduced, I had problems with pa when using highish values combined with multiple extruders. It worked well for longish segments but some curves would seemingly at random cause the print head to run in a slow and jerky fashion. The problem eventually went away but I'm not sure if it was due to a firmware change or some other reason. All that is in itself irrelevant but IIRC, PA was not, and could not, be applied to the individual segmented moves that make up a curve, but rather, it was applied at the end of a series of these small segments. That may be the reason why you don't see the crazy behaviour that you expected.
There has been a lot of speculation in this thread and until someone actually measures the pressure inside a melt chamber, speculation is all we can do. I'll add another speculative observation which is that maybe, with very small segments, the incremental increase in pressure between moves is too small to measure or compensate for, but that there is a cumulative effect after a number of these small moves which can be measured and compensated for. Maybe that's how pa in RRF works? -
@bot said in Enhancing pressure advance:
What led you to the settings you have in the config.g at the beginning of the thread you linked? I find them completely implausible for the machine you describe.
EG: your X/Y jerk is set to 66 mm/s
And your accel is 10k mm/s/s
It's not that simple, I advise you to read everything instead of just the config.g. Every print has its own parameters regarding jerk and accel.
This seems crazy. And also, you don't seem to have very high resolution, so what is the need for such tiny segments (as described by you -- I haven't measured them myself)?
Yes, it's indeed crazy to expect someone else to waste their time implementing some sort of GCode cache on 256K RAM. I don't need tiny segments, I need reasonable prints. That my reasonable prints may contain tiny segments and this machine breaks the Duet is not really my fault. Here goes the rant.
We need more detail.
There's just a few threads I've created over the few years and nearly all are about this topic. The quick conclusions and sometimes not reading carefully slow the information down, but it's alright, I can wait. I should've bought a Prusa and converted it to Duet instead, would've been so much easier doing tiny prints.
-
@Edgars-Batna I don't see any altered settings in your gcode files.
Explain to me what settings you have the problems at and I'll explain to you why your settings don't make sense.
*not actually a robot
-
In regards to the topic of this thread: I'm sad to report that dramatically increased values of PA don't cure the (what seems to be) over extrusion I'm experiencing when the print speed goes from 100 mm/s to 6 mm/s.
Dramatically increased values of PA DO, however, seem required/beneficial for high resolution prints in general. This seems like it could make sense since the extruder acceleration values will be so low at high resolution that the constant needs to be higher to get similar results.
I'll continue pushing the PA value up to see if I can see any difference in this behaviour. Imagine big ugly overextruded lines where nice ones should be. On tiny top details.
-
@bot For info, with my machine I've always needed about 0.4 - 0.5 PA. I know it's a completely different beast because I run multiple extruders and mixing hot end, and I don't do the highly detailed prints that you do. But I mention it purely because I think that the low values mentioned in the wiki can be misleading because they imply that much lower values are needed.
-
@bot said in Enhancing pressure advance:
@Edgars-Batna I don't see any altered settings in your gcode files.
Explain to me what settings you have the problems at and I'll explain to you why your settings don't make sense.
The problem reproduces itself sporadically on any settings. The Duet just needs to be at enough speed and suddenly encounter enough tiny segments to slow down, except it doesn't and the printer sounds like a percussion drill. Certain settings provoke the error more than others, but they are not the root cause.
Right now I'm printing at
M566 X1200 Y1200 E400:400
M201 X1000 Y1000 E900:900
M572 D0:1 S0.75If I go over E400 then Duet destroys the print. The issue still sporadically occurs, but it's not causing major step loss at E400. Now, please, flood me with new information, I mean it honestly.
-
@Edgars-Batna Just a random(ish) thought but that combination of lowish extruder acceleration and especially that low "jerk" might be limiting the pressure advance which is why you need such a high value. What happens if you double the extruder jerk and acceleration but halve the PA? But then IRC, don't have your extruders in push-pull configuration? In which case, I'm wondering if they might get a bit out of sync when PA is applied so end up fighting each other? Can you run with just one extruder to test? Just another random thought.....
-
@deckingman said in Enhancing pressure advance:
I think that the low values mentioned in the wiki can be misleading because they imply that much lower values are needed.
The wiki no longer has just the low values. It gives a much wider range now and encourages testing up to 2.0 to find the right value.
-
@Edgars-Batna It's always bothered me that we've never been able to solve your issues to satisfaction. If you want to take another crack at it start another thread and we can get some fresh eyes on it.
-
@Phaedrux said in Enhancing pressure advance:
@deckingman said in Enhancing pressure advance:
I think that the low values mentioned in the wiki can be misleading because they imply that much lower values are needed.
The wiki no longer has just the low values. It gives a much wider range now and encourages testing up to 2.0 to find the right value.
-
@deckingman I think the E acceleration values don't have a direct impact on PA at all. It is only the E jerk value that affects PA. Typically, even with extremely low values of E acceleration, the X/Y acceleration limits the motion of the coordinated movement, and hence limits the acceleration of the extruder. However, when PA asks the extruder to jump to a position, it needs to use jerk to do this (and only jerk -- it has to be instant). So, if you need X amount of adjustment of the E axis per a given value of E acceleration (which is actually usually dependent on XY acceleration), the firmware will simply lower the XY (E) acceleration so that the move only requires an amount of adjustment equal to the E jerk value.
For this reason, I think it's only necessary to adjust the E jerk value when playing with PA.
For @Edgars-Batna, I would suggest trying a much lower E jerk value.
-
I think pressure advance needs an additional parameter to control advance/adjustment based on differences in requested extrusion speed between print moves, and not just instantaneous extruder acceleration during a move.
See this photo:
The skirt is printed at 50 mm/s, and the perimeter is printed at 6 mm/s. Notice the excess extrusion at the beginning of the perimeter when coming directly from the 50 mm/s skirt.
If supremely excessive amounts of pressure advance are used, the problem is not quite as pronounced, but still there. However, then every other place where PA is applied, there is under or overextrusion (not seen in this pic).
I would like to keep the current behaviour of pressure advance for in-move adjustment, and also add an additional function, that can be set with a different constant, to adjust the extruder position in between print moves. I think a simple one-time retraction (without the unretract move) will be enough to relieve this pressure.
I'm not able to notice any of this behaviour in the opposite sense: when moving from 6 mm/s to 50 mm/s moves, there is no major loss of extrusion at the beginning of the fast move. I have some theories as to why that is, but they're probably wrong so I will keep them to myself.[Edit: Ignore that statement. I do think there may be some mild underextrusion when moving from 6 to 50 mm/s, but it's perhaps just not as noticeable because it's buried in the solid infill or somewhere where I'm not focusing my attention. It's possible my proposed addition to PA could also be useful when going from 6 to 50 mm/s.]
Any thoughts on this matter? I find to get the best perimeters, slowing them down dramatically is the best option right now (when we have segmented curves and trapezoidal acceleration). But, to get decent print times, I want to print everything else at maximum speed.
Help!
[Edit: basically, the proposed new added function of PA would be:
adjusted_extruder_position = current_extruder_position + new_constant * (second_move_speed - first_move_speed)
This could be applied immediately before starting the second move. ]
[Another edit: also, to clarify, I don't mean that this should be applied to two moves that just happen to have different X/Y speeds, I mean to apply this only to separate G1 commands that have a change in feedrate.]
-
@bot I don't do the highly detailed prints that you do so I never use such low speeds but a semi-random thought. Might it be that the amount of PA that you are using is not quite sufficient? What I mean by that is that if PA was on the low side, you might not notice too much difference between high speed moves because of the carriage speed. But if there was still some residual pressure at the end of a high speed move this would carry over to the next move which might show up if that move was at slow speed. If you've already tried higher values of PA, then just ignore this post.
-
@deckingman I did try very high values, which were obviously too much. The corners of my print were essentially gone, while the straight acceleration sections were over extruded. At that point, yes, I think most of the pressure was relieved, but the PA was so detrimental to the rest of the print it was not useful.
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.
If PA can't be adjusted to act like I suggested, It's possible I could inject some kind of purge move before certain types of moves, but that will waste time and capture more moves than necessary.
*not actually a robot
-
@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.
