Pressure advance and variable flow ratio

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.