2
$\begingroup$

I'm trying to print a cylinder with Flashprint. Problem is, that the .stl file i created (with OpenSCAD) is totally ruined once loaded into Flashprint. With ruined I mean the round outline is now with spikes and steps everywhere. And by loaded I mean directly after loading, not even creating the .gx files. The output of OpenSCAD looks fine, also in other stl viewers I tried.

I figured out the problem occurs more when using certain number of fragments ($fn). If its very small, loading works better. But for numbers that make it acutally look like a round circle (eg 50), Flashprint is unable to load them correctly it seems.

It's obvious that its no slicing or printing problem, but simply a loading one, since the shown object (which does not look any round) also prints the way it is shown in flashprint before slicing.

Does someone know a way to load a cylinder with flashprint correctly, or do I have to switch to different software? I already installed some but am unfamiliar with the printer settings which I do not know in detail. I really though a cylinder should'nt be too complex for any 3D software.

Here is the OpenSCAD Code for Cylinder, just create .stl and load into Flashprint to reproduce the Error:

rotate_extrude($fn=70)
    translate([0, 0])
        square([20,2]);

See also this image (tried native cylinder code, problem remains the same however):

Improve this question
$\endgroup$
2
  • $\begingroup$ Have you tried the code $fn = 70; cylinder(h = 2, r = 20); to see what happens to a native cylinder generated by OpenSCAD? $\endgroup$
    – fred_dot_u
    Commented Dec 28, 2017 at 9:39
  • $\begingroup$ Just tried it, although looking slightly different, the problem remains the same. I've uploaded a picture with your example code. $\endgroup$
    – borartr
    Commented Dec 28, 2017 at 9:58

2 Answers 2

Reset to default
0
$\begingroup$

Your image is very helpful. I think you might find that the rendering in your slicer is intentionally degraded to minimize use of system resources. The image you see may not be an accurate representation of that which would be printed.

If you wish further confirmation, consider to create the g-code from the slicer and view it in a text editor. An even better option would be to use an online g-code viewer and observe the results of the created g-code.

gcode viewer screen cap

The image above is the first line of print for a Marvin, showing that the base curves are smooth and clean. Your cylinder should appear in a similar manner, confirming that your slicer is degrading the image.

Improve this answer
$\endgroup$
5
  • $\begingroup$ I have actually printed it, every edge and spike that is shown after loading the stl gets printed. Also tried the online viewer, which shows the same 'features' (after converting it to .gx with flashprint). Note however, that viewing the same .stl with other viewers displays it correctly (I tried Meshlab). The problem has to be in the .stl loading of flashprint, which by my guess uses some interpolation that goes wrong especially at high resolution. $\endgroup$
    – borartr
    Commented Dec 28, 2017 at 10:55
  • $\begingroup$ Also note that, since I have mostly printed things from thingiverse, most of them, even containing circles at similar resolutions (but probably created with other programs) work just fine. So its maybe somehow the specific .stl output of OpenSCAD the Flashprint software has problems with. $\endgroup$
    – borartr
    Commented Dec 28, 2017 at 10:57
  • $\begingroup$ That's fairly peculiar. I usually create curved items in OpenSCAD at $fn = 90; ahhhh... Try a number that's an even factor of 360. Using 70 results in non-integer math that may be throwing things off. Even 72 is a good number that's close to your current figure. $\endgroup$
    – fred_dot_u
    Commented Dec 28, 2017 at 11:17
  • $\begingroup$ That was a good guess, I tried around some numbers but sadly the same problem. I guess I have to move to different software, the reason for this remains interesting though. $\endgroup$
    – borartr
    Commented Dec 28, 2017 at 14:13
  • $\begingroup$ I think you may be correct. The slicer is taking "normal" files and distorting them in a peculiar manner. $\endgroup$
    – fred_dot_u
    Commented Dec 28, 2017 at 15:17
0
$\begingroup$

While my first try with slic3r was really bad, due the required manual setup and my lacking experience (which was the reason I really wanted to stick with Flashprint), I actually found a solution to my problem. Its more a workarround but im perfectly happy with it for now.

I just load the OpenScad .stl with slic3r, use it's "Export STL..." feature, and load the resulting stl with Flashprint. Looks like a charm.

So the problem is really the OpenSCAD specific .stl files being misinterpreted by Flashprint.

Hopefully this helps some of you as well and save you some trouble.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .