Help needed - Uneven segment lengths on circles

I have a problem which seems to be present in all versions of Slic3r including the latest dev release and all PE versions. Maybe it's me but I can't find any setting that will change the behaviour.

The problem is that when slicing circles or arcs, I get (at what seem random times) uneven segment lengths. This in itself is no big deal as the objects print OK but I'm having problems with pressure advance in Duet firmware and I'm being told that it is these uneven segment lengths which cause the firmware to instigate pressure advance when it shouldn't. To re-iterate, the files print OK without firmware pressure advance (as opposed to Slic3r pressure advance), but when high levels of firmware pressure advance are enabled, it causes the print head to pause and do jerky movements.

I have a test file which is simply a number of hollow cylinders of different diameters.

Here is a cut and paste of a section of gcode of that file where all is well

G1 X258.252 Y202.177 E0.06755
G1 X257.308 Y202.538 E0.06752
G1 X256.347 Y202.854 E0.06755
G1 X255.374 Y203.126 E0.06752
G1 X254.389 Y203.353 E0.06749
G1 X253.395 Y203.534 E0.06754
G1 X252.393 Y203.668 E0.06752
G1 X251.386 Y203.756 E0.06752
G1 X250.376 Y203.797 E0.06752

.....and here is a section of the same gcode file a few lines further on where all is not well.

G1 X246.350 Y203.493 E0.06750
G1 X245.357 Y203.301 E0.06755
G1 X244.373 Y203.062 E0.06765
G1 X242.926 Y202.622 E0.10103
G1 X241.976 Y202.271 E0.06763
G1 X241.044 Y201.877 E0.06763
G1 X239.687 Y201.208 E0.10104
G1 X238.807 Y200.709 E0.06763
G1 X237.951 Y200.170 E0.06756
G1 X237.122 Y199.592 E0.06754

You can tell the odd size segments by looking at the extruder moves which are "normally" around 0.067 but at times jump to 0.101.

So the question is, why do I get these random segment length changes? i.e why aren't they all the same size for a given circle? Is there anything I can do to change this behaviour? If not, how I can report it to whoever it is that can fix it?

I've tried to attach the stl file for that part but I get an error saying it's too large even though its only about 2mb. I could put it on my Google drive and share it that way if anyone wants to try it. If it's an inherent problem with the stl file, then I'd love to know what to do to fix it. I use OpenScad and have changed the $fn value from 20 to all sorts of values up to 300 but the resultant sliced gcode always has these random segment length variations regardless of the number of facets in the original stl file.

Any help would be much appreciated.

Edit. I used Slicr3r to fix the stl file and turn it into an .obj file which I've managed to attach.

---

[somei3deas.wordpress.com]
[www.youtube.com]

Uneven segment lengths within arcs don't cause issues with pressure advance, but uneven extrusion rates do. Try putting the XYE values into rows on a spreadsheet, calculate the XY distance moved in another column, then divide the extrusion amount by that to get the extrusion rate. Then you can see whether it is consistent or not.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Uneven segment lengths within arcs don't cause issues with pressure advance, but uneven extrusion rates do. Try putting the XYE values into rows on a spreadsheet, calculate the XY distance moved in another column, then divide the extrusion amount by that to get the extrusion rate. Then you can see whether it is consistent or not.

What??? Well I must have misunderstood what you said when I last raised the issue I've been having with pressure advance all this time.

Anyway, putting that aside, I've done what you suggested. Here is what I've done on that "problem" part of gcode shown above. Given that X and Y are two sides of a right angle triangle, the combined XY move will be the hypotenuse. So I've taken one X value from another to calculate the absolute move length and squared it. Then I've done the same for Y. Then added X^2 plus Y^2 and taken the square root of that to get the move length (hypotenuse).

These are the true segment sizes

1.0113916155476
1.01260900647782
1.5124182622542
1.01276897661806
1.01185967406551
1.51294745447422
1.01163283853384
1.0115616639632
1.01060625369129



Dividing the E amount by that I get the E rate which is as follows

0.066789163526362
0.066807622258179
0.066800304202502
0.066777321937563
0.066837331038475
0.066783548695757
0.066852317781633
0.066787821649257
0.06683117163911

So it seems then that the E rate is consistent and it's not the slicer's fault after all. I've just raised it as an issue on github - guess I'd better tell them it's not an issue at all.

TBH I'm getting really fed up with this. I first raised the issue of problems I was having with pressure advance on the Duet forums in July 2017 and re-raised it multiple times since then. It seems every time I raise it, it either gets ignored, or I get told to increase this, decrease that, redo the file with more segments\less segments, update the firmware, generate this report\that report, and lately try another slicer. Now we find that it's not a slicer issue so where does that leave me? Pressure advance still causes problems when I print arcs or curves, seemingly at random. If I raise the issue again on the Duet forums will it get "swept under the carpet again"?

---

[somei3deas.wordpress.com]
[www.youtube.com]

If possible, I'd suppress pressure advance below a certain track-length in Firmware. Is that a possibility? Would it help you, Mike?

Quote
o_lampe
If possible, I'd suppress pressure advance below a certain track-length in Firmware. Is that a possibility? Would it help you, Mike?

This has been raised numerous times. If it fixes my problems I'd love to see it. I could always print circles and arcs at slower speeds so that pressure increase is less of a problem. In theory, I think that what should happen is that there is a cumulative effect after a number of short moves such as a segmented arc, so pressure advance is needed (and would be applied) at the end of that arc. In practice, what appears to happen (and I've posted videos showing it) is that pressure advance can be triggered multiple times during those segmented arcs. This slows everything down and causes the print head to move in a jerky and unpredictable manner which ruins the print.

BTW, who's Mike?

---

[somei3deas.wordpress.com]
[www.youtube.com]

Quote

BTW, who's Mike?

If it's not you, it must be 'leadinglights', because I often confuse you... Sorry

There must be a way to determine the angle between two segments and we set a threshold where the planner can ignore jerk and pressure advance settings.
That's probably better than checking track length.