Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with uneven segment sizes for arcs and circles #1000

Open
irp53 opened this issue Jun 23, 2018 · 8 comments
Open

Problem with uneven segment sizes for arcs and circles #1000

irp53 opened this issue Jun 23, 2018 · 8 comments

Comments

@irp53
Copy link

irp53 commented Jun 23, 2018

Version

Slic3r PE version 1.40 but this issue affects all versions of slic3r back to 1.29 and possibly before that

Operating system type + version

Win10 64 bit

Behavior

Please excuse me if I don't do this correctly. I'm a 65 year old carpenter and this is the first time that I've attempted to report anything on GitHub.

When slicing circles, segment sizes can vary. Usually for any given circle, the segment sizes will be roughly the same but seemingly at random, odd segments up to 100% larger or smaller may occur. For normal printing, this is not usually an issue and the object will print reasonably well, despite these odd segment sizes. However, I'm having problems when using pressure advance as implemented in Duet RepRap firmware. I'm told by the author of the firmware that the reason for my problems is that the random odd segment sizes generated by Slic3r are causing firmware retraction to trigger when it should not do so.

My test file is simply a number of hollow cylinders.

Here is an extract from the gcode file when behaviour is normal
G1 X64.865 Y178.676 E0.06019
G1 X65.241 Y177.783 E0.06019
G1 X65.704 Y176.932 E0.06019
G1 X66.250 Y176.132 E0.06019
G1 X66.873 Y175.390 E0.06019
G1 X67.566 Y174.713 E0.06019
G1 X68.324 Y174.109 E0.06020
G1 X69.138 Y173.584 E0.06019
G1 X70.000 Y173.142 E0.06019

.... and here is an extract a few lines later in that file when all is not well

G1 X275.818 Y176.861 E0.06117
G1 X276.042 Y175.900 E0.06127
G1 X276.305 Y174.950 E0.06125
G1 X276.605 Y174.012 E0.06119
G1 X277.125 Y172.625 E0.09205
G1 X277.516 Y171.723 E0.06110
G1 X278.172 Y170.394 E0.09205
G1 X278.651 Y169.535 E0.06109
G1 X279.436 Y168.280 E0.09199
G1 X280.294 Y167.074 E0.09197
G1 X280.904 Y166.301 E0.06118
G1 X281.544 Y165.553 E0.06115

The easiest way to spot the odd segment sizes is to look at the "E" values. Well "all is well" they are about 0.061 but randomly in this case, there are values of around 0.092. The XY moves are proportional to the E move, so it's the segment size that varies, not just the extrusion amount.

I've tried changing every setting that I can think of and tried it on nearly all versions of Slic3R from1.29 onwards, with the same result.

Here is my test stl file. I created it with OpenScad. I've tried changing the number of facets in OpenScad and re-rendering but it doesn't seem to make any difference. I've experienced this problem on many different objects before I realised that the problem only occurred during segmented arc moves, which is what prompted m,e to create the test file in order to make the problem reproducible.

STL/Config (.ZIP) where problem occurs

hollowCylinders.zip

@tracernz
Copy link

Please excuse me if I don't do this correctly. I'm a 65 year old carpenter and this is the first time that I've attempted to report anything on GitHub.

This is a good bug report. 👍

The XY moves are proportional to the E move, so it's the segment size that varies, not just the extrusion amount.

Yes, for the curious:

X Y Extruder Distance
275.818 176.861 0.06117  
276.042 175.900 0.06127 0.9867
276.305 174.950 0.06125 0.9857
276.605 174.012 0.06119 0.9848
277.125 172.625 0.09205 1.4812
277.516 171.723 0.06110 0.9830
278.172 170.394 0.09205 1.4820
278.651 169.535 0.06109 0.9835
279.436 168.280 0.09199 1.4802
280.294 167.074 0.09197 1.4800
280.904 166.301 0.06118 0.9846
281.544 165.553 0.06115 0.9844

Hopefully someone smarter than me can figure out why.

@irp53
Copy link
Author

irp53 commented Jun 24, 2018

This is a good bug report. 👍

Thank you.

For info, I've just been informed by the author of the Duet RepRap firmware, that it would be changes to extrusion rate, not changes to segment size that would trigger firmware pressure advance. If I divide the extrusion amount by the move distance, the extrusion rate is in fact consistent. So this variability in segment size may not be the cause of my problems after all. Having said that, it is still odd behaviour which could affect print quality I would have thought.

@Sebastianv650
Copy link

I know that problem with erroneous extrusion ratios from linear advance, but I can also confirm that Slic3r isn't generating such bad segments. Cura had it for a while, but it's fine since some time also.

Slic3r generates segments as they are defined in the stl, as long as you don't use the resolution option. I think there is nothing which could be done more on slicers side, as it doesn't know what feature (arc, circle, short line) was intended at a specific area. So each try to "smooth" out the mesh can easily result in wrong results. The gcode arc feature has shown that in the past for example.
That said, I never had experienced visible printing errors due to such segment variations. Usualy we only get problems if the stl has a too high resolution, so the slicer will generate segments of 0.0001mm lentgh.

@irp53
Copy link
Author

irp53 commented Jun 24, 2018

OK but it is rather strange that the segment size varies seemingly at random. That is to say, the same cylinder may have all equal size segments on one layer, but differing segment lengths on another layer.

Anyway, it seems that this isn't the cause of my problems as I had mistakenly thought, so I'll try and raise the issue yet again on the Duet forums. Essentially, it is a firmware pressure advance issue that I've been trying to get resolved since July 2017.

@bubnikv
Copy link
Collaborator

bubnikv commented Jun 28, 2018

@irp53 So are you saying that you believe there is no issue on Slic3r side, so we may close this issue?

@irp53
Copy link
Author

irp53 commented Jun 28, 2018

Well I'm not sure. The uneven segment sizes seem odd and other slicers that I have tried generate even segment sizes from the same stl file, so in that respect it seems to be a problem. Having said that, objects do seem to print OK despite the uneven segment sizes. However, it may yet still be the reason why Duet RepRap firmware pressure advance is misbehaving - the author has no answer at this time but is going to look at the firmware code again. It seems too much of a coincidence to me, that firmware pressure advance misbehaves seemingly at random and also that Slic3R makes uneven segment sizes also seemingly at random. If the cause of my problems turn out to be these uneven segment sizes which make firmware pressure advance misbehave, then either the slicer needs fixing or the firmware needs changing to make it less sensitive to those anomalies.

@mdealer
Copy link

mdealer commented Jan 25, 2019

I've got a gcode where slic3r PE simplifies too much, and, to make it worse, segments have alternating phase every 5-10 layers or so, which causes artifacts. The resolution seems to be 0.5mm, regardless of what I configure. This is way too little.

EccentricGearTest.zip

@mdealer
Copy link

mdealer commented Mar 1, 2019

I've analyzed this in regard to Duet RepRapFirmware in combination with my CoreXY printer and there is definitely a bug in Slic3r PE which is not present in original Slic3r.

Regardless of what I do in the settings I get a garbled object:
grafik
https://www.thingiverse.com/thing:1478258/files

And the seam plus the print direction is randomly switched from clockwise to counter-clockwise.
grafik

Here's a test print of EccentricGearTest:
grafik

Same pattern is visible in Slic3r PE:
grafik

All this should be enough for a response.

The Duet firmware cannot account for this as we're talking varying corners which are subject to jerk and acceleration control. Even if the firmware does some sort of smoothing, the paths are varying from layer to layer, thus layers do not 100% overlap eachother, making ugly prints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants