All slicers do that... really. This is because a an STL files have no information's about arcs, circles, lines etc. STL files are just a bunch of triangles.pixelpop wrote: ↑Sun Jan 06, 2019 2:48 amI've always wondered why S3D never uses any of the Marlin gcodes for geometric moves like arcs, circles and lines. Instead, S3D produces a gazillion discrete point-to-point gcode lines. If S3D would use the available geometric commands, it would greatly reduce the size of the gcode and thus probably eliminate pausing issues when printing via USB.
Paul, would you care to expound on your workaround?Paul wrote: ↑Sat Sep 07, 2019 6:09 pmUPDATE:
After 40+ hours the problem has been solved with a work around.
I am surprised that no one has run into this, or they are just not expressing this problem.
It is duplicatable and a very specific event.
This should have been fixed a long time ago, and it will continue until it is addressed.
Good luck out there.
Paul wrote: ↑Mon Sep 09, 2019 12:47 pmWe originally thought the issue had something to do with the infill overlap but my tech said it wasn’t in that module.
We tested over 100 different combinations of settings pertaining to all things ooze control and retraction.
We ruled out the machines, the model itself and the program that created the .stl.
We zeroed out all ooze control settings and unchecked all boxes under advanced.
Nothing changed as far as the blobs, and we had some minor stringing from crossing open spaces, which wasn’t the cause.
As the picture shows the uncorrected model has a thick seam that we programmed in to control where the seam would be least noticeable.
None of this has anything to do with temp or ooze control.