Enhancing pressure advance
-
@bot said in Enhancing pressure advance:
@dc42 on the documentation for PA, it says that the value multiplied by the constant is acceleration:
actual_extrusion_speed = requested_extrusion_speed + (K * current_extruder_acceleration)
Is this not true? I sadly cannot understand code, so I can only go by what documents and you say.
You may be correct with the nonlinear relationship.
When I find some time, I may try and perform some tests as you said, swapping velocities and PA values. My problem at the moment is directly related to extrusion pressures, but the prints used to test take sooooooo long to finish it's very arduous to test many things. (Because I'm only encountering problems at very high resolutions. Low resolution prints look fine. I assume this is because small variations in extrusion amount aren't as noticeable in thick, chunky traces of filament.)
@Edgars-Batna it's not the tiny segments that are the problem, it's any variation in the calculated (by the slicer) extrusion amounts for each segment leading to inconsistent extrusion speeds. Or, too low of jerk causing every segment to accelerate and decelerate.
It's getting way off topic, but I've analyzed the code enough. The CPU runs out of juice and PA shoots the last nail at it and that no amount of fixed movement parameters will fix it because slicers are also a problem of their own with weird assumptions etc, etc, bla bla. I really do not want to go over this again. Besides, the Duet 3 has enough juice for it all. Just an idea. Please do not answer me or I will keep ranting.
-
@Edgars-Batna said in Enhancing pressure advance:
But tiny segments are unavoidable in some prints and really it doesn't matter which slicer I use with Gyroid infill or when printing curvy stuff, the printer runs out CPU and doesn't slow itself down.
Are you certain the printer is running out of CPU? Please provide an example file, provide your config.g file, and tell us which Duet you were running it on when you saw it slow down.
-
@dc42 said in Enhancing pressure advance:
@Edgars-Batna said in Enhancing pressure advance:
But tiny segments are unavoidable in some prints and really it doesn't matter which slicer I use with Gyroid infill or when printing curvy stuff, the printer runs out CPU and doesn't slow itself down.
Are you certain the printer is running out of CPU? Please provide an example file, provide your config.g file, and tell us which Duet you were running it on when you saw it slow down.
There are config.g and gcodes I already posted in old topics, but, while people did genuinely try to help me, my examples were treated more or less like a joke. I can accept it. Life is tough. But I'm dead serious about tiny segments, although I learned to work around the issue partly inside and mostly outside the firmware and been living with it.
https://forum.duet3d.com/topic/11386/duet2-cpu-struggling-to-keep-up-with-this-gcode/19
My printer sounds like a percussion drill printing the gyroid infill behind me right now.
-
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
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)?
We need more detail.
-
@dc42 said in Enhancing pressure advance:
Ideally we would measure the pressure within the melt chamber, but that's hard to do.
In what ballpark is the nozzle pressure anyway? I might have access to temperature resistant pressure sensors with an extremely small sensing head soon, and milling a hole in the nozzle to accept one would be easy. But these are for a fullscale range of 400 bar and absolute accuracy is not that high. Resolution is higher, which is probably what is needed most.
Would the curve change much between extruder brands? Would an E3D hotend with Bondtech display a different shaped curve than, for example, a DyzeXtruder?
Regarding small segments; how many segments can a Duet2+RRF3 process per second as long as no acceleration/speed limits are hit? And Duet3?
-
I have no idea of the ballpark, but I had it in my mind to learn about fluid flow (aka bugging my engineer friend) enough to calculate a rudimentary estimate of extrusion pressure through a given nozzle size at a given speed, etc.
I think the limitation is not the number of segments themselves, but the number of steps those segments need to produce the correct movement. AFAIK it's in the range of at least 100k/sec or more for both Duet 2 and 3.
-
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.
-
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.