Pressure advance and variable flow ratio

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.