Pressure advance useless for curves / circles?

[oderwat]

Am I right, that pressure advance will have no effect when you print a tube or cylinder?

[oderwat]

@KevinOConnor

For my open question:

Your graph shows extruder velocity for PA ... I don't see that this is coupled to the X/Y speed. The nozzle would "jump" at the start and slow down till and then move backwards in the end. So how can the extruder speed (including the PA) be a direct tie to X/Y speeds?

.. I am asking what defines the acceleration of the part in the red circle? What defines how long it accelerates and de-accelerate? I want to change the length of it (slightly). BTW: I expected it to be a "max accel" value for the extruder (for pa?). Maybe the simple answer I look for is: max_extrude_only_accel ... But shouldn't this parameter be different for a "retraction" and a normal "extrusion"? I can accelerate faster and to a higher speed for retracts than for extruding plastic. Anyway. Not knowing how it works is the reason for me to ask.

For the PA testing and my test procedure there is probably a major misunderstanding going on:

I don't want/need you to tell me what is a good PA value. I did in fact printed multiple rectangles in the past. Why should I print this model over an over and what will be the possible feedback? I already found that an overall 0.3 PA is good for my prints (full prints not tests). I use Klipper since many days for normal printing now. But over USB2Serial, with S3D which works still fine btw..

You say you have no comparison for the pictures. Why would a comparison be needed? What to compare against? The comparison to do is "inside" the picture. PA 0.0 at the bottom PA 0.6 at the top. Picture shows the effect. I don't understand what this should be compared too? Do you want me to print the 20 squares with the same PA values as they are used in the picture? From this wish I have a feeling that you don't really know what these pictures depict. Or I am really to dumb to understand what you are telling me.

Here are three hollow square prints from bottom to top: 0.0 / 0.35 / 0.6. Speed was 100 mm/s with 0,2 mm layer height and 0,4 mm nozzle and line width at 1.0 extrusion multiplier (I usually would use 0,95 with this filament). The filament is BDP (Greentec / from Extrudr in Swisserland. It is pretty good but a bit costly about $60 per 1kg). Thats the same I used for all the tests here and is usually used in most of my prints. I disabled outline/short layer speeds being changed. So it is really 100 mm/s and not 50% or whatever the slicer(setting) normally would use. I guess most people, which will try this test, will end up with slower speeds, because they don't know/compensate for the slicer doing "sane" things to the outlines/perimeters.

This now out of the way, back to what I wanted to demonstrate and (optionally) get feedback for:

What I tried to develop is an alternative method which uses less time and is more practical and better to reason about. My program does the testing and parameter changes automatic. The pictures show what happens when PA is gradually increased and proves that PA does act and lets one decide which value is best. This is directly coupled to the thickness of the seam and the under extrusion visible with higher PA values. What I wanted is to discuss this method and what may be flawed with it. @BlackStump actually did and I am happy to have at least this person evaluating my idea. He also mentioned that his printer, even being basically the same as mine, has different PA settings. I run my test multiple times and it has a perfectly repeatable result. I guess thats the same for him. This again proves that my method does reflect the minimal differences we may have with out printers. But it could also be filament and temperature related. Which again gives a lot of value to my test, because it is much faster than to run multiple manual tests with the squares for each filament and temperature change.

What I (maybe thought I could) expect is that you say: "Maybe you are onto something.. let me try it for one of my printers, where I know how PA reacts very well. Please generate me some GCode with a temperature of 190C / 50C and make it fit my 123x240 sized bed, such that I can run a test of what it does myself."

If that seems good I could setup a website where people can get their GCode much like the one for linear advance. I could contribute my code to your Klipper scripts, publish my GCWiz or whatever. I can do most of that without your. Maybe running a 25 minute print to test my routine is to much for you. Or you possibly know a reason why my test is bad designed in the first place.

[oderwat]

Oh... I forgot that my last printed squares where just two outlines for saving filament. This is not exactly following the guide. So I am doing a PA 0,4 mm with klippy.log and attach it when it is finished. This will then be the last print with this filament. So if thats not good enough I need to re print a whole bunch of squares again.

[oderwat]

For what I mean with "real 100 mm/s" see this preview: ... in comparison to this one: ... but I think you all know about that when testing the PA as described in the guide.

[oderwat]

There we go. Just for the record: Printing one of those squares with 100% infill at a "constant" 100 mm/s lasts 36 minutes on my printer (for a 4 mm height aka 20 layers at 0,2mm).

This is as said before with PA 0.4, which seems to be the best value from my own calibration tests above.

I think I could print one more ;-)

Here ist the klippy.log from firmware start / reset to finish this print and M112 shutting down:

klippy.log.zip

[KevinOConnor]

On Wed, Jun 06, 2018 at 03:52:44PM +0000, Hans Raaf wrote:

Your graph shows extruder velocity for PA ... I don't see that this is coupled to the X/Y speed. The nozzle would "jump" at the start and slow down till and then move backwards in the end. So how can the extruder speed (including the PA) be a direct tie to X/Y speeds?

.. I am asking what defines the acceleration of the part in the red circle? What defines how long it accelerates and de-accelerate? I want to change the length of it (slightly). BTW: I expected it to be a "max accel" value for the extruder (for pa?). Maybe the simple answer I look for is: max_extrude_only_accel ... But shouldn't this parameter be different for a "retraction" and a normal "extrusion"? I can accelerate faster and to a higher speed for retracts than for extruding plastic. Anyway. Not knowing how it works is the reason for me to ask.

Lets take an example with a printing move at 100mm/s that results in an extruder velocity of 5mm/s. In this example, if pa=0.05 and the move started from 0mm/s then Klipper would push in .25mm of filament during acceleration to account for pressure. If max_accel=500 then the move at 100mm/s would take .2 seconds to accelerate from 0 to 100mm/s. So, with pa=0.05 the extruder would push in an extra .25mm in .2 seconds, which is an additional constant extruder velocity of 1.25mm/s.

In the graph you point out, there are two areas with acceleration - the velocity slope on the left and the instantaneous velocity change that you have circled. The velocity slope on the left uses constant acceleration and it is unchanged with any PA setting - it's directly tied to the move acceleration. The instantaneous velocity change is infinite acceleration and it is not configurable. The magnitude of the instantaneous velocity change is determined by the pressure_advance config setting and the ultimate cruising velocity of the move.

[...]

What I tried to develop is an alternative method which uses less time and is more practical and better to reason about. My program does the testing and parameter changes automatic. The pictures show what happens when PA is gradually increased and proves that PA does act and lets one decide which value is best. This is directly coupled to the thickness of the seam and the under extrusion visible with higher PA values. What I wanted is to discuss this method and what may be flawed with it. @BlackStump actually did and I am happy to have at least this person evaluating my idea. He also mentioned that his printer, even being basically the same as mine, has different PA settings. I run my test multiple times and it has a perfectly repeatable result. I guess thats the same for him. This again proves that my method does reflect the minimal differences we may have with out printers. But it could also be filament and temperature related. Which again gives a lot of value to my test, because it is much faster than to run multiple manual tests with the squares for each filament and temperature change.

There are some advantages to the square test:

• It can be generated with any number of slicers. A g-code generater needs, at a minimum, the filament diameter, the extrusion width, and the layer height. These parameters are different on different printers so there is no universal default for them. People tend to have a slicer of choice which they've already configured (and set other useful features like bed size, temperatures, homing/nozzle wipe sequences, etc). A good number of people will be reluctant to configure another g-code generator. Using the square avoids this issue.

• It tends to work well even if the bed is not fully level. If there's extraneous signals in the test then it's easy for new users to misinterpret the results which could lead to significant lost time.

• Using a print object with multiple outer walls tends to magnify the pressure issues (inner walls blob causing outer walls to blob further). This makes it easier to identify a good PA value.

• The square is structurally sturdy, so it can be kept for comparisons with future/past runs.

I'm sure it is possible to improve the PA test. It certainly has some flaws:

• It does take longer to print and it uses more filament.

• The corners are susceptible to warping which can complicate/invalidate the test.

I did try a variety of tests when coming up with the PA guide. I settled on the square test because I felt it was the most robust test I tried - to wit, it's better to spend an extra 15 minutes on a test then to risk spending 10 hours debugging the test.

In particular, in my past single wall tests, I found that I got a different (worse) PA value. I'm not fully sure why - I think it may have been the single wall corner being too fragile. In your tests, the square seems to clearly indicate 0.40 is your optimal PA value - that is also very close to your single wall test - but I can't really tell from the pictures if it is exact.

Be aware, it seems you were using a max_accel=500 - that isn't a very common setting on most printers. A low max_accel value like that does make it easier to reach higher PA settings in general.

So - my feedback is to "have at it". If you want to work on new methods to identify pressure_advance then great!

What I (maybe thought I could) expect is that you say: "Maybe you are onto something.. let me try it for one of my printers, where I know how PA reacts very well. Please generate me some GCode with a temperature of 190C / 50C and make it fit my 123x240 sized bed, such that I can run a test of what it does myself."

No, alas, I'm backlogged, and likely will be for the next several months.

-Kevin

[oderwat]

@KevinOConnor Thank you for your response and time! I think it will help me a lot.

About the graphic: OK. I think I now understand how it works and that the graphic is correctly depicting what happens. The instant speed change is the "back to the normal extrusion value" vertical line at the end. The slope is directly bound to the acceleration which is bound to the acceleration of the printhead. So to make it slower I would need to set an even lower acceleration. This kinda leaves open what happens at the de-acceleration and why it crosses the time line and goes into the negative. But I think it helped me already to understand it. I have a feeling that it could be better do "decouple" the E speed from the printer head speed and use another curve instead the linear correlation. But I am not here to change that :)

I think for the most of the "pro square" reasons there is a very easy solution.

1. I could just read printer.cfg or there could be a way to query Klipper for the needed values. Actually my gcwiz code can easily be started on the RasPi. It could even be a OctoPrint plugin. Still, the Filament size and the build plate area is very common knowledge for any 3D printer user. The layer height can be bound to the nozzle width as can the line width. I don't think that this will overwhelm a 3D printer user. Especially when he goes lengths to use Klipper :)
2. I can easily extend my test with a section of dual and tripple walls to add thickness for seam and corner.
3. My test prints where sturdy enough to keep. It also can be reproduce very fast.
4. It is not spending 15 minutes more to print say 5-10 squares. It is 3-5 Hours vs. 25 mins for my broad test and maybe another 25 mins for a coarse version. The squares are also prone to make errors by forgetting to RESTART and because one need to edit the config file multiple times and keep track of what square was which print. All of that is not needed for my test.
5. In the cons you forgot that different slicer settings will have a big impact: Retraction, Coasting at the line end, different speeds for outline than basic speed. Different line widths for outlines and normal lines. I am sure I forgot stuff. With my test those are all under control and "standardised".

My max_accel setting is what is the original firmware value, as is 25 mm/s for max z velocity. I am sure both could be doubled but I kinda forgot about it. Thanks for the heads up on that.

To check the "best" PA of the picture one can just measure the length of the full print, the length of the "best" value and "0,6 / full_mm * best_mm". I am sure that you know that though :)

About the single wall test. You may have noticed that I don't test the corners but the speed change at a straight part of the wall. something a slicer can't 100% replicate (I tried with different processes in S3D, the GCode is always polluted with extra commands at the seam). The seam seems (lol) to be a very good indicator. It also makes a lot of sense that the optimal PA creates the smallest seam. What I wrote in my last comment is, that I suspect that the delta of the speed change has some influence to. Maybe this can be made better.. maybe it is good enough as it is.

[hg42]

@oderwat

This kinda leaves open what happens at the de-acceleration and why it crosses the time line and goes into the negative

my reasoning would be like that:

extra_filament = pressure_advance_coefficient * extruder_velocity

so, for linear acceleration, the extra_filament (a length!) will also increase linearly, which means the additional extra_extruder_speed (= extra_filament / time) is constant.

This is the constant speed offset in the curve.

At the start of the movement the offset is positive (to build up the pressure) and at the end the offset is applied negative (to release the pressure). Which leads to a retracting filament at the end.

[hg42]

btw. I also had some hard time to see, where the time constant for the third curve can found in the simple formula:

I think it's kind of inverted logic: because the form of the curve is always similar and the speed offset and the raising time are dependent, the PA coefficient is only value to be calibrated to compensate the given time constant.

[oderwat]

I actually have to confess that talking about math / physics in english seems to be very hard to me :(

What I currently think is that the curve for the extra pressure should look like an exponential function. And this would be the mirror to the logarithmic behaviour that is depicted in "actual filament".

Part of the topic of S-cuves which I only skimmed over, seems to address that in a way, because the movement of the head will not be linear anymore. Hence the extruder acceleration won't either.

In the end there is still the assumption that the PA algorithm works good enough wile being parallel to the head acceleration. In the graph the "actual filament" is changing over the whole move. So the PA "more Filament" is pushed in at the beginning and supposed to give it a head start to make the curve look more like "desired filament". But in reality that seems to be a much more complicated function. I would also think that instead of assuming it to go to zero (and retract) it should have some threshold as long as it was not the last move. I think this is why there is the lookahead. Which I not really understood yet.

This also goes a bit above my head and intend. I wanted to find a way to make PA better to grasp and to demonstrate with some reproducible and easy to follow procedure. I actually think that I found it and I got responses outside of this issue, which are very encouraging to follow this route further.

[hg42]

you have to clearly distinguish which value you are looking at in the curves.

Constant acceleration means linear speed ramp and quadratic position ramp.

S-curves

don't help here because jerk, vibration etc. is not a problem here

assumption that the PA algorithm works good enough wile being parallel to the head acceleration

it always has to be in parallel, because for each part of the movement you need to lay down an exact amount of filament (basically length height_of_line width_of_line). If you move faster, you also have to extrude faster by the same factor.

Unfortunately, if you move the extruder some mm consuming a volume of filament, the nozzle doesn't extrude the same volume, because of the springy behavior of some parts in the system (bowden, filament, melted filament). You need a specific pressure to achieve this. And the pressure is dependent on the speed. For every speed change you need to adjust the pressure, which is done by pushing more or less extra_filament into the tube. I think PA is mainly designed to compensate for the melted filament behavior (pressure, compression, flow, etc.). But because the behavior of the other parts is also kind of springy, they are automatically included in the compensation with a proper calibration.

[hg42]

a calibration "tower" is definitely a good way, but with the mentioned problems.

But if you restrict it to Klipper this can work, you already mentioned some of the possible solutions (e.g. reading parameters from the config).

[oderwat]

I think I just continue my gcwiz coding in my own repository. Thanks for all the input and clarifications.