Blobs and Underextrusions in GCode

[AbeFM 35]

I imported a part from SW testing the updates made to the plug-in, and found weird artifacts. I thought it was the problem of the importer, but I find the issues even when I bring in a clean STL. 

 

The first thing I noticed (which I get from time to time in CURA slicing) is additional little blobs that I have trouble figuring out why they are there.

 

That is supposed to be a smooth part but there are two 2-layer excursions out into space.

 

I don't think it's "rounding errors" as you can see the shadowed envelope.

 

This happened in the same spot on the model (a particular fin in particular spots) on two different models (one imported via .3mf from SW, one from STL).

 

I rotated the model 45 degrees and while the should be unchanged, the globs certainly changed.

 

These defects seem to be only on the (with the machine's +y as 12, looking down towards bed) 7:30 and 4:30 positions, even as I spin the object relative to the bed.

 

 

Similarly, here's what I would take apart an extruder over from the print, but it's in the g-code:

See the missing line?

 

When I try to print something "as it appears on the screen" these issues lead to problems. I'd love to help solve them if someone has meaningful tests for me to run.

 

P.S. I rotated the objects each 15 degrees in different directions and got (what appears at first glance) satisfactory slicing.

MarbleRunSpinPaddle.STL

[gr5 2,167]

This is - well - unprecedented I think.  Could you try running the model through this free service first just to see what happens??

https://service.netfabb.com/login.php
 

Also could you post your STL somewhere on the internet (actually ultimaker might let you upload it - not sure on this new forum).  What cad software are you using?

[burtoogle 513]

I tried slicing that model and didn't see those weird blobs on the sides but did see some extraneous lines on the flat top of the hub which were influenced by the slicing tolerance setting. FreeCAD thinks that model has some problems so maybe they are the root cause of the weirdness?

[AbeFM 35]

23 hours ago, gr5 said:

This is - well - unprecedented I think.  Could you try running the model through this free service first just to see what happens??

https://service.netfabb.com/login.php
 

Also could you post your STL somewhere on the internet (actually ultimaker might let you upload it - not sure on this new forum).  What cad software are you using?

It's not very obvious, but the model is available, it's the last line in my previous post - "marblerunspinpaddle.stl' :-)

 

Odd, Netfab said it was invalid and wouldn't open it. CURA didn't complain, and neither did MS 3d Builder (which I generally use to repair poor models, make simple edits. Fast).

Simplify loaded and sliced it (once, not definitively) ok.

 

The model was generate in Solidworks (2016 I believe).

 

Oh, and running S3D just now to check that reset my printer mid print. URG! Just had to vent. :-)

[kmanstudios 1,120]

This is definitely weird. I took the file into 3DS MAX and used their STL Check. It said it was fine.

 

Then I sliced it in Cura and noticed that if I started off at Fast (0.2mm) there were no artifacts.

The more fine I sliced (progressively to 0.6mm) the artifact appeared more and more pronounced. Here it is at 0.6mm slice:

But if I took the snap off rotation and just rotated the slightest bit, it was artifact free.

Rotation value:

Sliced after Rotation:

So, this was very odd. I though at first there may be a slight rats nest in that area, but I could not find anything.

So then I ran it through 3DCoat and voxelized it. That worked.....jut take my word for it. But it got me to thinking. Here is the original mesh as it is imported.

Really, really tight triangulation. But that did not explain the slight rotation causing it to go away. So I put a 'quadify mesh' modifier on it.

This seemed to have reconfigured the mesh enough that it did not cause that 'knotting'.

It reminded me of when I first started doing 3D in 1990 with what became POVRay. If there was just something odd enough about an object, it could return a null pixel in its raytrace. But just the slightest alteration made it become refactored and it would render just fine. The quadify reset the original mesh vertex points enough to make the artifacts go away. Even though it still had some very tight edges, it was altered slightly enough to not cause artifacting. And, maybe rotating the model just slightly enough to cause it to be resampled in the slicing algorithm and remove the error.

 

The original file was not an issue at all as far as I can tell. But, here is the modified mesh I got to work ok.

MarbleRunSpinPaddleQuadified.STL

 

I wish I could have given you a more definitive reason behind this.

[gr5 2,167]

Now that I see the above post by kman, I'm pretty sure meshlab will fix this.  You want to remesh it.  This is a pretty rare problem fortunately.

 

STL files contain lots of triangles and nothing else.  No data to indicate which triangles go with which - like a big puzzle.  All 3 points of each triangle are in XYZ space but sometimes...

 

Anyway after intersecting a plane with all these triangles now cura is left with a bunch of "random" lines which are now in a plane in XY space.  Each line segment as two points - two ends - but which line goes with which?  Looking at the above photos - where some of these lines come together they are less than 0.01mm apart.  

 

The next step in cura is to take these "random" lines and connect them into loops.  For example you have 8 paddles so a slice might have 8 loops.  Ideally.  But there is some error allowed so sometimes cura connects them up in the wrong order and the lines go backwards/forwards and you get twists in the loops.  Cura got confused in a few places in this model and cura got some loops twisted up a bit.

 

Not sure if polygon reduction is quite exactly what you want but here is a guide to that feature anyway:

http://www.shapeways.com/tutorials/polygon_reduction_with_meshlab

@Daid  @nallath

@ahoeben @ghostkeeper     - any comments/suggestions/corrections?  

[AbeFM 35]

That's really interesting.

 

It's not the first time I've found printed defects like this... But I use the same workflow often.

 

Perhaps I should turn down spacial accuracy while leaving angular on better-than-fine (10 degree) when I export.

 

I will play with simplifying model, likely with 3D builder to start, it's fast. :-)

 

Thanks for posting the Maya shots, I didn't look at triangles and that makes it obvious why 45* rotation had such an effect.

[kmanstudios 1,120]

Yer welcome And, I liked @gr5's explanation. Makes sense. Bugged me though until I read that LOL

[ghostkeeper 105]

I think you're right there, Gr5. Though I don't know how it would arrive at this result then.

 

The slicing algorithm in Cura (that creates the actual model outlines for each layer) stitches lines together if they're closer than 0.01mm, so that small horizontal gaps are closed. I'd expect it to take the closest available line to stitch towards if there are multiple within this range, but I didn't find that code immediately so I'm unsure about that. Also, due to rounding errors when interpolating vertex coordinates between layer heights, the endpoints of a line could be 1 or 2 micrometres off. This all could result in a bit of a mess when connecting these lines.

 

Normally the rest of the code then expects simple polygons: No crossing polygon borders allowed. Maybe this case results in a mess at the micron level in this corner and that violates those assumptions.

 

I don't expect it to go outside of the normal polygon border though. And apparently it's far enough outside to even be printable (more than one line width thick). So that seems weird to me.

[AbeFM 35]

This guy had a similar problem - I'm sure you could come up with rounding error arguments and other such for why it's not printing what's given to it... But the fact is that the g-code is, pretty obviously, not representative of the STL's given to it.

 

Even just throwing an error when the sliced surface is more than 0.8 line widths from the STL's surface would be a big help.

 

I currently feel I *HAVE* to check the line-view before hitting print, I cannot trust CURA not to make things I didn't ask for.

 

Perhaps the two are unrelated....

[AbeFM 35]

Just so it's not all vinegar on this thread:

 

One of my favorite models sliced just great in Cura today. I tried it in desperation because all I get out of Slic3r Prusa Edition is:

 

I'd think of this as a "rounding error" but either way, it kinda sucks.

 

Which leads me to: Does anyone have a profile for the Prusa i3 Mk3 for Cura, or know where I might look?