RRF 2.03 pressure advance causes 20% overextrusion

jschall

RRF 3.1.1, 200% speed, x8 microstepping, 1.0 PA
fwd_count 6073637
rev_count 5024835
net_count 1048802
mm 2655.194937

So this is not terribly huge overextrusion, I could try printing with this. There's still a bug.

dc42

@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:

Just a thought, for a next generation path following algorithm, what I would do is:

Segment the toolpath into linestrings in which the angles between the lines are less than some threshold (such as 30 degrees)

Smooth those segments, using maybe a series of cubic splines (long lines may need to be split up into shorter lines first).

Compute the speed curve along the segment such that tangential and radial acceleration is limited and such that the extruder can keep up with pressure advance. Each segment starts at zero speed and pressure and ends at zero speed and pressure.

"Jerk" (bad choice of term) becomes unnecessary. Corners below the angle threshold are rounded smoothly, without ringing or asymmetry. The printer will come to a brief stop at sharp corners above the angle threshold, thus making them as sharp as possible.

That's similar to what I have planned. A disadvantage is that the existing effect whereby the perimeters of holes are always under-sized would be made a little worse.

T3P3Tony

@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:

The printer will come to a brief stop at sharp corners above the angle threshold, thus making them as sharp as possible

it will be interesting to see if PA can compensate for the large blob seen when stopping briefly at corners. Currently sharp corners are slightly rounded because the printer does not come to a complete stop - but they are smooth, where as when the print hed has to be raised (e.g. to the next z level, there is a visible Z "seam".

Maybe this is better off combined with jerk for angles > than the smoothing process works on.

jschall

@dc42 said in RRF 2.03 pressure advance causes 20% overextrusion:

That's similar to what I have planned. A disadvantage is that the existing effect whereby the perimeters of holes are always under-sized would be made a little worse.

Holes are undersized because of the low resolution meshes. I generally export my STLs with higher resolution.

I did this real quick, based on wikipedia's python example of catmull-rom splines. The yellow line is the spline drawn through only the provided points, and the blue line is the spline when additional control points are added to limit the length of curved sections. It shouldn't cause holes to undersize - if anything it will make them better.

jschall

@T3P3Tony said in RRF 2.03 pressure advance causes 20% overextrusion:

Maybe this is better off combined with jerk for angles > than the smoothing process works on.

Here's the thing though - just increase acceleration. That's effectively what jerk is doing anyway.

jschall

Hard enough to get PrusaSlicer to generate gcode without 20% more extrusion than the volume of the STL in the first place

mendenmh

@jschall You have to be careful with just increasing the acceleration. Because of decreasing torque with increasing speed, high acceleration combined with high speed can cause lost steps. You can tolerate much more acceleration at low speed (where jerk comes into play) than at high speed.

I have a low-accel setting for my printer (1200 mm/s^2) that allows travel up to 150 mm/s. I had to make my high-accel (1800 mm/s^2) macro drop the travel speed to 120 mm/s to not lose steps.

I actually would like, someday, in RRF a variable-acceleration mode which drops the acceleration as the speed approaches a specified target, to keep the system inside the torque-speed envelope. It isn't a difficult calculation, and might allow somewhat faster overall printing.

jschall

@mendenmh yes, could just model that and limit acceleration to stay within torque limits.

jschall

Getting endless "connection reset by peer" upload failures when trying to upload gcode to RRF 3.1.1. Not sure if the issue is with my network or RRF 3.1.1.

Phaedrux

Is your DWC version also at 3.1.1?

Post the result of M122?

bot

@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:

Hard enough to get PrusaSlicer to generate gcode without 20% more extrusion than the volume of the STL in the first place

Ahem: https://github.com/n8bot/PrusaSlicer/tree/n8_precision_minus_infill_support

This fork of PS 2.3.0-alpha alleviates inconsistent extrusion rate, among a few other things. I think you'll like it. Build that n8_precision_minus_infill_support branch.

jschall

@Phaedrux said in RRF 2.03 pressure advance causes 20% overextrusion:

Is your DWC version also at 3.1.1?

Post the result of M122?

https://gist.github.com/jschall/49fc6d654a912f81ac897d64064325a4

Phaedrux

Check the General > Settings tab in DWC to see what version it's at.

M122 looks ok.

jschall

@Phaedrux said in RRF 2.03 pressure advance causes 20% overextrusion:

Check the General > Settings tab in DWC to see what version it's at.

Duet Web Control 3.1.1

jschall

@bot I tried to build PrusaSlicer before and gave up because of ridiculously huge numbers of dependencies on cutting edge versions of everything.

jschall

@bot do you think you could build the linux .appimage for that and send it to me?

bot

@jschall I do not have access to a linux machine, and have never built an app image... I've only built this on windows.

However, I found the SuperSlicer (fork of PS) build instructions fantastic.

https://github.com/supermerill/SuperSlicer/blob/master/doc/How to build - Linux et al.md

Give that a shot.

jschall

@bot said in RRF 2.03 pressure advance causes 20% overextrusion:

However, I found the SuperSlicer (fork of PS) build instructions fantastic.

That's just identical to the PrusaSlicer build instructions.

Hmm, even a windows build would be fine. Can run it under a VM.

bot

@jschall here's the windows build I run day-to-day:

https://github.com/n8bot/PrusaSlicer/releases/tag/v2.3.0-alpha0-n8pmis

It's almost the latest PS master branch, but the latest changes they made to the master branch aren't useful so those aren't included yet. (waiting for the seam painter to actually work, not just paint meaninglessly)

jschall

@bot What's the difference between that and the n8_precision_minus_infill_support branch?