Enhancing pressure advance

bot

I love pressure advance, however I see an area where it could be improved further.

Right now it looks at the extruder acceleration to apply advancement, etc.

Would it be possible for pressure advance to look at large changes in extrusion speed between different print moves, even if separated by a travel move? I'm finding that when going from 100 mm/s infill, to printing a tiny perimeter at 6 mm/s, no amount of pressure advance corrects for this huge change in ~~pressure~~ extrusion speed.

dc42

Pressure advance is controlled by extrusion speed. The filament is advanced by the pressure advance constant multiplied by the extrusion speed. This relies on two assumptions:

That the back pressure for the nozzle is proportional to extrusion speed.
That the filament compresses linearly in the Bowden tube.

Both of these are unlikely to be true. What I think is needed is a nonlinear relationship between the amount of advance and the extrusion speed. But we don't know what that relationship should be. Ideally we would measure the pressure within the melt chamber, but that's hard to do.

One way investigating the relationship needed would be to conduct a series of tests where linear extrusion at speed v1 is changed suddenly to v2, with varying amounts of pressure advance, and varying v1 and v2. The idea would be to find out the optimum pressure advance for each (v1, v2) pair. From that we could work out the optimum pressure advance curve.

Edgars Batna

Another useful feature could be automatic movement parameter adjustment to achieve a smoother pressure curve. It's like dynamic acceleration adjustment to reduce ringing, but here we try not to jiggle the filament needlessly to avoid rolling the filament flat. It's something like the autospeed feature in Slic3r, except that the one in Slic3r doesn't work as expected. I can't imagine that doing 20 adjustments per second (one per tiny segment) has any effect on the actual print with say PA value of 0.5 (thats the takeaway from one of my amazingly long but unclear clicking sound threads).

dc42

@Edgars-Batna said in Enhancing pressure advance:

Another useful feature could be automatic movement parameter adjustment to achieve a smoother pressure curve. It's like dynamic acceleration adjustment to reduce ringing, but here we try not to jiggle the filament needlessly to avoid rolling the filament flat. It's something like the autospeed feature in Slic3r, except that the one in Slic3r doesn't work as expected. I can't imagine that doing 20 adjustments per second (one per tiny segment) has any effect on the actual print (thats the takeaway from one of my amazingly long but unclear clicking sound threads).

If it's adjusting for each tiny segment, either the slicer is generating uneven extrusion rates (and you should use a different slicer), or you have the XY jerk set too low for the print speed you are using.

Edgars Batna

@dc42 said in Enhancing pressure advance:

@Edgars-Batna said in Enhancing pressure advance:

Another useful feature could be automatic movement parameter adjustment to achieve a smoother pressure curve. It's like dynamic acceleration adjustment to reduce ringing, but here we try not to jiggle the filament needlessly to avoid rolling the filament flat. It's something like the autospeed feature in Slic3r, except that the one in Slic3r doesn't work as expected. I can't imagine that doing 20 adjustments per second (one per tiny segment) has any effect on the actual print (thats the takeaway from one of my amazingly long but unclear clicking sound threads).

If it's adjusting for each tiny segment, either the slicer is generating uneven extrusion rates (and you should use a different slicer), or you have the XY jerk set too low for the print speed you are using.

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. Anyway, it's just an idea.

bot

@dc42 on the documentation for PA, it says that the value multiplied by the constant is acceleration:

From here:

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.

Edgars Batna

@bot said in Enhancing pressure advance:

@dc42 on the documentation for PA, it says that the value multiplied by the constant is acceleration:

From here:

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.

dc42

@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.

Edgars Batna

@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.

bot

@Edgars-Batna

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.

DaBit

@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?

bot

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.

DaBit

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.

bot

@DaBit 100k steps/sec. including microsteps.

arhi

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)

bot

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.

deckingman

@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?

Edgars Batna

@bot said in Enhancing pressure advance:

@Edgars-Batna

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.

bot

@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.

bot

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.