Pressure advance and variable flow ratio

trchen

Here's a benchmark I made to demonstrate the issue. The test prints 4 lines:

#4 A line with 0.41mm --> 0.72mm --> 0.41mm transition, same target speed, with pause in between
#3 A line with 0.41mm --> 0.72mm --> 0.41mm transition, variable target speed, constant target flow rate
#2 A line with 0.41mm --> 0.72mm --> 0.41mm transition, constant target speed
#1 A constant width line with variable speed. To demonstrate the pressure advance value being appropriate.
(Printed from bottom to top.)

In theory if pressure advance is working properly line 2, 3, 4 should be printed identically. But in the actual result the top line #4 has the sharpest transition. Line #3 and #2 has transition delayed towards the right and averaged out.

My apologies that I only have a coarse textured build plate. It should be more obvious when printed on a flat plate. Here's the gcode for you to reproduce the issue.
E_jerk_test.gcode

G21 ; Millimeter units
G90 ; Absolute XYZ
M83 ; Relative E
T0 ; Switch to tool 0
M190 S105 ; Set bed temperature (wait)
M109 S250 ; Set nozzle temperature (no wait)
M204 S1000 P1000 ; Acceleration
M572 D0 S0.05 ; Pressure advance

; Purge line
G1 X50 Y50 Z0.2 F18000 ; move to start
G1 X50 Y100 E2.754 F3600
G1 X50.72 Y100 E0.040
G1 X50.72 Y50 E2.754
G1 E-0.2 F2400 ; Retract

; Line 1: Same line width, different speed
G1 X75 Y50 F18000
G1 E0.2 F2400 ; Unretract
G1 X125 E1.568 F1200
G1 X175 E1.568 F3600
G1 X225 E1.568 F1200
G1 E-0.2 F2400 ; Retract

; Line 2: Different line width, same speed
G1 X75 Y60 F18000
G1 E0.2 F2400 ; Unretract
G1 X125 E1.568 F3600
G1 X175 E2.753 F3600
G1 X225 E1.568 F3600
G1 E-0.2 F2400 ; Retract

; Line 3: Different line width, maintain volumetric rate
G1 X75 Y65 F18000
G1 E0.2 F2400 ; Unretract
G1 X125 E1.568 F3600
G1 X175 E2.753 F2050
G1 X225 E1.568 F3600
G1 E-0.2 F2400 ; Retract

; Line 4: Different line width, same speed, with pause
G1 X75 Y70 F18000
G1 E0.2 F2400 ; Unretract
G1 X125 E1.568 F3600
G4 P1
G1 X175 E2.753 F3600
G4 P1
G1 X225 E1.568 F3600
G1 E-0.2 F2400 ; Retract

; Indicator lines
G1 X125 Y75 F18000
G1 E0.2 F2400 ; Unretract
G1 Y95 E0.627 F3600
G1 E-0.2 F2400 ; Retract
G1 X175 Y75 F18000
G1 E0.2 F2400 ; Unretract
G1 Y95 E0.627 F3600
G1 E-0.2 F2400 ; Retract

; Lift Z
G1 Z10 F300

Argo

I don't know if "Firmware Wishlist" is the right place for this as this looks to me like a unwanted behaviour of pressure advance.

Printer: Voron 2.4
Extruder: LGX (not lite)
Board: Duet 3 Mini 5+
FW: 3.4.1

Pressure Advance PLA test pattern with high speeds (60mm/s to 160 mm/s at 4.000mm/S acceleration):

Result are looking good at PA 0.06.

But the print then looks like this with bulging corners (external perimeter speed at 80 mm/s, 1.200 mm/s acceleration):

To get rid of the bulging corners I further increased PA (0.1) to the extend that infill lines don't connect anymore with perimeter:

Heavily increase infill overlap to 200% or so would "solve“ this but that causes other artefacts / issues. So that is not really a solution imo.
I saw this behaviour since the RRF 3.4 beta6(?). With RRF 3.3 corners were sharp(er). I'm using input shapers and I know that PA has to be retuned, hence the test pattern above.

@dc42 Maybe you could please take a look at this? Normally I would not ping you but I recon RRF isn't the community were people always directly update to the newest version (RRF 3.4) when the printer is running fine. Thanks!

mikeabuilder

@Argo - quick question (followed by no additional insight, I'm just trying to understand more on this topic since I'm trying to tune PA and IS on my machine). My question is the units on you acceleration on pictures 1 and 2 - your units are mm/S, and the value is 1.2 or 4. The value seems extremely low if the acceleration units are actually mm/sec^2. Or is this acceleration really a jerk value (mm/s per Step?)

trchen

@mikeabuilder I think he mean 1200mm^2/s and 4000mm^2/s. The dot is the digit delimiter, not decimal point.

mikeabuilder

@trchen - well, that makes a lot of sense.

trchen

I think Firmware wishlist is probably not the right place for this post. It is not really a new feature, but more of tweaking.

My apologies for tagging you directly, @dc42, just want to make sure you are aware of it. We have a few users at Voron Discord who suffered from PA-related issues that is specific to RRF.

I did some more experiment afterwards. I wrote a SuperSlicer postprocessing script to insert a short pause G4 P1 (basically forcing RRF to decelerate to 0) when flow ratio changed by more than 5%. It mitigated my bridging problems even if printing at normal bridging speed (75mm/s). It is only circumstantial evidence but I think it's worth some investigation.

Here's my SS script if anyone's curious:

#!/usr/bin/python3

import sys
from io import StringIO
from math import hypot

THRESHOLD = 1.05

x = y = None
e_rate = 0.0
buffer = StringIO()
for line in open(sys.argv[1], "r"):
	if not line.startswith("G1 "):
		buffer.write(line)
		continue

	dx = dy = de = 0.0
	for clause in line.split():
		if clause[0] == "X":
			if x is None:
				dx = None
			else:
				dx = float(clause[1:]) - x
			x = float(clause[1:])
		elif clause[0] == "Y":
			if y is None:
				dy = None
			else:
				dy = float(clause[1:]) - y
			y = float(clause[1:])
		elif clause[0] == "E":
			de = float(clause[1:])

	if dx is None or dy is None:
		buffer.write(line)
		continue

	dxy = hypot(dx, dy)
	if dxy < 0.00001:
		new_e_rate = 0.0
	else:
		new_e_rate = de / dxy

	if e_rate == 0.0 or new_e_rate == 0.0:
		pass
	else:
		ratio = new_e_rate / e_rate
		if ratio >= THRESHOLD:
			buffer.write("G4 P1\n")

	buffer.write(line)
	e_rate = new_e_rate

with open(sys.argv[1], "w") as f:
	f.write(buffer.getvalue())

Argo

@droftarts could you please move this thread to a more suitable category? Hopefully someone will then take a look at this. Thanks!

droftarts

@argo it needs @dc42 to look at it. I’ll highlight the thread to him on our internal comms. We don’t really have a ‘firmware issues’ category, so here is fine.

Ian

dc42

@trchen thanks for sharing your thoughts. Have you tried building a version of the firmware with permitted extruder jerk set to zero in DDA::MatchSpeeds? If you haven't, would you like me to build one for you?

oliof

@argo just a side note that I am not surprised RRF3.4 with IS does cause rounded corners because that's what IS effectively is for -- smoothing out the movement so it's not a sharp direction change that induces ringing. If you disable IS in 3.4, do you regain the sharp corners?

Argo

@oliof

Input Shaping only has marginal effect on how the corners do look like. I did tests with and without IS.
I did also play around with different jerk settings (5 mm/s up to 15 mm/s) and the result is also pretty much the same.

For testing purposes I would like to revert back to RRF 3.3 ~~but it seems the 1LC rev 1.1 is not supported by RRF 3.3 because I can't activate the heater.~~ As far as I remember I did not have this issue with RRF 3.3 but that can still be a coincidence.

Edit: I'm not sure the issue I'm having is related to the findings of trchen and I don't want to hijack his thread, so I'm creating a new one with my findings.

trchen

@dc42 I haven't, but I'm happy to try! I predict it will have similar effect as my slicer postprocessing script. I'll do an experiment to see if it reinforces or disproves our theory.

trchen

I just got my build environment set up. I will be busy at work this week, probably will start my experiments over the weekend.

The first experiment would be hardcoding the E jerk during MatchSpeeds to some small value and see how bridges behaves.
(The jerk value can't be zero due to FP errors. Something like 0.01 is probably more reasonable. I feel MinimumJerk==0.1 may still be high for extruders.)

I still haven't think through what a better jerk policy should be. Allowing the total speed to mismatch between two moves doesn't feel right either because multiple rapid small moves could rack up a lot of speed change in small amount of time.

On the other hand, what's so different with the policy we have today? With the current jerk policy you can make a lot of small moves to form very small turn radius, effectively bypassing the acceleration limit. For example, Gyroid infills are notoriously demanding for acceleration. I suspect we are actually able to cheat by breaking down curves to multiple small moves, by setting "Slicing --> Filtering --> Internal resolution" smaller in the slicer.

An idea I have in mind is to maintain a "jerk potential" which is recharged at the rate of acceleration while capped at the jerk maximum. Once the jerk potential is depleted no more instantaneous speed change is allowed.