Cura generates geometry not present in the original file

[baltic 1]

58 minutes ago, gr5 said:

So either you included the wrong project file or something didn't get saved into the project file (I'm guessing something about the printer aka "machine").

It's just for some weird reason Cura started to include "disallowed area" into ender 3 profile. I had to remove them.

 

1 hour ago, gr5 said:

I changed the layer height from 0.2 to 0.11 and 0.003 and I don't get those triangular shelves.

That's really strange.

[baltic 1]

Ok. I have downloaded the fresh appimage, created a new profile, not derived from Ender 3, to be able to use full printing area.

Result is still the same. 

Is there some sort of log Cura writes which i can check?  

[gr5 2,184]

I don't think it's the model. I was so convinced it was the model.  I opened the original STL file in meshlab and looked at the normals and everything looks perfect.  It's possible that one point is different where two triangles come together at a point -- although it looks like they meet at the same point, one point could be off a bit.  But I doubt it.  Why would CAD do that?  Not likely the problem.

 

I think I know what the problem is.  It's a floating point rounding error.

 

When cura "slices" it works on one layer at a time.  A few layers are failing.  When it is working on a layer it has the STL file which is an unordered (this is important) list of triangles.  There is no relationship - the STL doesn't say which triangles are near each other or share a border.

 

So Cura intersects the current plane with ALL the triangles and gets a set of lines all in the same plane so they are 2D lines.

 

The lines are in random order.  Cura then tries to link them up into loops that connect back together (but don't cross - no figure 8 allowed).  This is the part where Cura gets confused.  There are VERY Large triangles in the area that fails.  Somehow when it intersects a line with 2 neighboring triangles it is getting line segments that don't quite end at the same point.

 

Anyway cura has a margin of error where it says "well these 2 points are the same within this tolerance so I think they are the same point and these 2 lines link up.

 

I'm going to guess that the problem has something to do with the floating point processor on @baltic 's computer.

 

I bet if he tries a different computer with different CPU it will work fine.

 

These programs that "fix" the STL may (or may not) add more smaller triangles and that may help reduce floating point errors.

[baltic 1]

44 minutes ago, gr5 said:

Somehow when it intersects a line with 2 neighboring triangles

Did you mean plane? Plane intersects triangles and gets 2 segments, which don't have a common point?

If you already take tolerances into account, when comparing floats, i don't believe the rounding errors alone are going to be huge enough to cause problems.

 

I did it differently, when i wrote a foam cutter software very long ago. As far as i remember, I had a soup of tri edges, and a way to map an edge to a tri. So a slice in my case was list of edges. And I went from a first one, through the triangles it belongs to, to the next. 

It was working fine, though I didn't have a huge  .stl test base, and those stls i had were seemingly well formed.

 

Also, you can implement a simple check, if an edge belongs only to one triangle, then something is wrong in the model.

 

 

[gr5 2,184]

On 4/11/2021 at 4:43 PM, baltic said:

Did you mean plane? Plane intersects triangles and gets 2 segments, which don't have a common point?

Yes that's what I mean but the common point is not in the STL directly - there should be one line that the common point is on at the height of the current slice.  Those "common lines" have a point at each end to define them.  Those points are in two different triangles that should have a common edge (the common edge is the 3d line).  It's hard to explain in words.

 

Anyway I don't think that's the problem.  I think the calculation of all the line segments has some kind of floating point error.  Like if you had the old pentium from years ago where sometimes the floating point processor returned the wrong answer?  I'm not sure.

 

[GregValiant 1,279]

"Like if you had the old pentium from years ago where sometimes the floating point processor returned the wrong answer?"

 

It goes back a bit further.  Intel was having trouble getting the floating point side of the 486's to work consistently.  Their fix was simple.  If the floating point side of a chip didn't work when tested, they totally disabled the floating point side and renamed that particular chip a 486SX and were able to sell their scrap (slightly discounted of course).  It was a brilliant solution.  If the floating point side worked it was a 486DX.

[baltic 1]

51 minutes ago, gr5 said:

I think the calculation of all the line segments has some kind of floating point error.

And how to check this theory? The fact that it slices well on another machine doesn't mean that the problem is exactly in this.

[gr5 2,184]

I was hoping you had another computer @baltic.  Yeah I don't know how to help you other than that.  I looked at the STL very carefully where it's making your "shelves" and I can see which line it's connecting to - why the triangle is that shape - but Cura shouldn't do that and it doesn't do it on my computer nor on Greg's.  I've never seen this issue before (where the STL is perfectly fine yet it intermittently slices wrong like this).

 

You could submit it as a Cura issue on github and include your project file but if the developers can't duplicate it, I'm not sure they will pay much attention.

 

Maybe if you can get it to duplicate after scaling the part down - that way I can see if I can duplicate your issue consistently?  Maybe I can't duplicate because I scaled the part down.  maybe if you choose a larger printer (like and Ultimaker S5) the problem will happen?

 

 

[GregValiant 1,279]

@gr5 and @baltic - I tried all kinds of things to reproduce the problem.  No luck.

 

@baltic, could you post a gcode file created from that slice with the errors in it?  I can read it into AutoCad and bypass Cura.

[baltic 1]

Yeah but if it works on the other machine, how does it prove the point that this is exactly the rounding issue, rather then something else?

 

Btw i don't believe its the rounding. It's waay too off

 

 

Edited April 14, 2021 by baltic

[baltic 1]

5 minutes ago, GregValiant said:

could you post a gcode file created from that slice with the errors in it?

Sure dear.

[GregValiant 1,279]

Thank you sweetheart.

[gr5 2,184]

22 hours ago, baltic said:

Btw i don't believe its the rounding. It's waay too off

It only has to be off by about 0.1mm (or less) before the routine that takes the line segments and tries to form them into loops grabs the wrong line segment and makes the wrong loop.

 

The locations of the sides of the triangle (the triangle shelf) are all on lines in your STL if you look at the actual triangles that make up the STL.

 

[GregValiant 1,279]

And here we are @gr5.  The light gray lines are the triangles.  Triangle abc is the surface that is in error in the gcode file and it is at Z=28.3 and nowhere else.  Travel is Clockwise and should be ptA to ptB to the btm rt corner.  There shouldn't be a stop at ptC.  These are the relevant lines from the gcode file and are the first evidence of the error:

G1 X57.698 Y218.13 E3174.98208  ;  ptA
G1 X155.509 Y129.584 E3177.1762  ;  ptC
G1 X155.51 Y17.1 E3179.04682  ;  btm rt corner

 

This is from the next layer up:

G1 X57.463 Y218.1 E3387.91512  ;  ptA
G1 X155.527 Y218.1 E3389.54593  ;  ptB
G1 X155.528 Y17.1 E3392.88857  ;  btm rt corner

 

 

 

 

Here is that area of the outer and inner walls represented in AutoCad as derived from the Gcode file.  There are actually additional stops at ptC on some other layers, but ptB is not ignored on the other layers.  

 

 

So all the evidence points to @baltic running Cura on a Gateway 2000 486SX computer in DOS mode and from a floppy drive.  In other words, I don't know why this happened and it only happens on one computer (as far as we know).

[baltic 1]

58 minutes ago, gr5 said:

It only has to be off by about 0.1mm

Only? Dude the dimensions in the STL are in mm. So the 0.1mm is waay too huge to be a rounding error.

[baltic 1]

Note how the BC line isn't even derived from the original stl, as it is obvious from the wireframe.

QED. It has nothing to do with rounding.

[GregValiant 1,279]

Pt C is in the middle of nowhere.  When I slice the file and generate a gcode I can't reproduce the error.  Everything is as I would expect.  FYI there are 796 triangles in the part.

[baltic 1]

FYI Epstein didn't kill himself.

[GregValiant 1,279]

Sure he did.  They made a snuff film of it.

[gr5 2,184]

I disagree on the point "C" in your diagram @GregValiant.  But it's really hard because our computers aren't doing it.

 

The "0.1" was just explaining that it's visually small to a human eye.  Of course the error could be significantly smaller than that.

 

If you look at the very first photo in this topic, Greg, you can see that this 3rd point is most likely on this line circled in red.  And the "c" you are referring to @GregValiant may be on a triangle on the rear of the right wall that we can't see from this angle because it's hidden behind the existing wall.  Without actually seeing it happen and being able to orbit in 3d, it's hard to tell where point "c" is. 

[GregValiant 1,279]

What we have here is a moving target.

I agree that's what the first preview looks like.  I was working with the gcode file that Baltic posted.  Here is "1.gcode" open in Cura.  The surface is at 28.3 and is below that first break line of the right wall.

 

 

 

The mid point of the vertical walls is Y=118.  But point C is at Y=129.58.  You can see in this orthogonal view of layer Z=28.3 that C is not at the midpoint.  I think the key here is why ptB was ignored on this layer (or other points on other layers since dependent on the settings, error surfaces came and went and moved around).

EDIT:  Looking at Baltic's "Multi-Error" image, all the missed ptB's are in the right square corners.  No errors relate to the left side radiused corners.

 

 

Edited April 16, 2021 by GregValiant

[gr5 2,184]

I think it's connecting to this line here on the back (but I think it's a different model).  I marked the line in red.

 

[GregValiant 1,279]

I understand what you mean.  I don't know if it's a different model or what was going on.  The preview shot with the three extraneous surfaces was really weird.  In that last ISO image I put up the error is definitely below that line you have highlighted.  In other images there is an error up there.  It's also odd that IdeaMaker came up with "14 non-manifold edges" in the STL but Cura didn't find any.  And it sliced fine for me as well.

I haven't had any luck finding a piece of software that will actually tell me where an error is.

[baltic 1]

6 hours ago, GregValiant said:

the error is definitely below that line you have highlighted.

Yes

[baltic 1]

I found that 4.7.1 doesn't have it. 4.8 and 4.9 do. Maybe i should file a bug, but without an easy way to reproduce it, it's gonna be futile.