Enhancing pressure advance

[Phaedrux]

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=

[deckingman]

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

[bot]

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

[bot]

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.

[Phaedrux]

Have you looked into how kisslicer handles nozzle pressure?

[bot]

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

[Phaedrux]

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.

[Edgars Batna]

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

[bot]

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

Gcode here.

[dc42]

@deckingman said in Enhancing pressure advance:

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.

Only if extrusion stops completely between moves.

Essentially, pressure advance is a filament extrusion distance advance, such that the extra extrusion distance is a function of the current extrusion speed. That distance is currently proportional to extrusion speed; but I think it needs to be a nonlinear function.

Does anyone have the time to do the pressure advance vs speed tests that I outlined in my earlier post? https://forum.duet3d.com/post/138461

[bot]

@dc42 I'll perform those tests today. I think people have performed similar tests in the past. @deckingman has previously determined that linearity is acceptable, but I'll see what I can set up to test again to see if we can reproduce similar findings.

[Phaedrux]

I can't help but notice the words non-newtonian haven't come up yet.

[Edgars Batna]

@bot said in Enhancing pressure advance:

@Edgars-Batna Nice work. Are you modifying only the unretract move or are you injecting movement somewhere else? The results look promising!

The unretract move acts as you described it, but the extrusion rate of last move and the created underextrusion were also a factor that required some more implementation or it ended up ugly. I think I implemented it this way:

1. The average extrusion rate of last 5 seconds is stored.
2. Unretraction move applies your formula.
3. The remainder of extrusion is stored for later.
4. The next moves are adjusted by the remainder, factored by move time. 5 second moves get the most of the extrusion remainder. Remainder is passed on from move to move.

Result is a small fixed amount of total underextrusion. There you see the time constants that could also be adjustable.

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.

Gcode here.

I'll try it as soon as my other test is finished.

@Phaedrux said in Enhancing pressure advance:

I can't help but notice the words non-newtonian haven't come up yet.

You mean we'll need a GUI to plot a graph when tuning filament by hand? Jokes aside, you mean that there might be no PA required up to a certain pressure or from a certain pressure depending on material and such? Honestly, I'm as good as Google on this topic, because I have to Google it all.

[bot]

@dc42 Print 1 of 20 is underway of the test. I will be printing a single wall cube with sudden speed changes in the middle of the faces, with no speed changes at the corners, and the speed change going from V1 to V2 then V2 to V1.

XY Accel: 300 mm/s/s
XY Jerk: 1.5 mm/s

4 mm/s to 40 mm/s and vice versa
8 mm/s to 40 mm/s and vice versa
16 mm/s to 40 mm/s and vice versa
32 mm/s to 40 mm/s and vice versa

The 4 different prints will each have the following PA variations:

S0.0
S0.1
S0.2
S0.3
S0.4

Total 20 prints.

Results tonight or tomorrow (Pacific Time).

[Edgars Batna]

@bot My printer chirps like a bird when I print this file. Is it supposed to go super fast?

[bot]

@Edgars-Batna Hmm the 100 mm/s parts go fast and the 6 mm/s parts go slow! There are only those two feedrates. Also, I think I have the retraction speed and the travel speed ten times higher than normal so I can scale down the speed of the print without slowing those moves down.

Check the gcode and adjust the speeds as needed or whatever! Its a 0.2 mm line width and a 0.04 layer height (after the first layer) so I'm not sure if you'll be able to print it anyway.

[bot]

I'm changing the test prints to be one layer only. This makes observations easier. I will simply photograph the result from the top and then move on to the next. This will be faster.

[deckingman]

@dc42 said in Enhancing pressure advance:

@deckingman said in Enhancing pressure advance:

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.

Only if extrusion stops completely between moves.

I know. That's why, I went on to say (quote)...... "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."

[Edgars Batna]

@bot said in Enhancing pressure advance:

@Edgars-Batna Hmm the 100 mm/s parts go fast and the 6 mm/s parts go slow! There are only those two feedrates. Also, I think I have the retraction speed and the travel speed ten times higher than normal so I can scale down the speed of the print without slowing those moves down.

Check the gcode and adjust the speeds as needed or whatever! Its a 0.2 mm line width and a 0.04 layer height (after the first layer) so I'm not sure if you'll be able to print it anyway.

Unable to print with 2.05.1 official at all. Getting just loud extruder motor chirps. My other, normal, test print went fine, tho.

If you feel adventurous, here's modified firmware (rename to .zip): Duet2CombinedFirmware.txt

Usage: M207 C[your constant]. For multiple extruders specify a list: A:B:C...
M207 reports the values as "compensation".
Only tried on 2 extruder mixing CoreXY setup.
Only works with firmware retraction (G10/G11).

Looking at your GCode, steps with E0.0000x just plain won't work and steps with E0.000x will have tons of error because the computations in the firmware are not this precise. Maybe you are chasing a completely different beast... Could you create a test with reasonable extrusion rate?

I'd post source code but git is getting on my nerves regarding newlines, so this will need to wait until tomorrow.

[bot]

@Edgars-Batna Unfortunately, this is a reasonable extrusion rate and the areas I need to tune. Low resolution prints don't really need the extra attention, at least for my uses.

But, I suggest you generate a g-code yourself that just uses the top print speed you can achieve with a move that comes after that is the slowest speed you can achieve.

Also, what do you mean by the firmware doesn't compute that precise? AFAIK, the firmware uses 6 digits of precision. No?