Quest for High-Detail Prints

Summary:

Skeinforge is 'greeking' text, eliminating most detail before the Makerbot even gets a crack at it.

Quest for High-Detail Prints

Joel Craig Ewy 29 Aug 2012 14:52

I'm trying to print an object that I composited in OpenSCAD from DXF files generated in Inkscape. The machine is a late-model Thing-O-Matic (#7030) with a Mk7 and MBI 3.1 firmware. The object includes some text raised off the surface, as well as clock-face details sunken into the surface (cut out with difference() ). Maybe I'm pushing the limits of the machine with these sub-milimeter details, but I can't really tell because Skeinforge munges the text detail in the gcode. If I load the generated gcode into a gcode viewer, I can see that the text has been 'greeked', so the Makerbot never gets a chance to show what it can do with it. This effect is the same using both SF50 and SF35 in replicatorg 0037. A different part of the build is a wing insignia with feather detail that is certainly within the ballpark of the same scale as the text, but it comes through fine. Is there any way to change this behavior in Skeinforge? Or is there something funny about the detail in the .STL file? It looks great in the preview window in RepG, and in OpenSCAD.

As an experiment I tried Slic3r 0.7.1, using a profile that I mashed-up from two different ones others had posted as working to some degree with their TOMs. I mainly just wanted to see if Slic3r would handle the text differently. But it is pushing through way, way too much plastic, even with the "Extrusion Multiplier" set to .15, so whatever detail may be there is obscured in huge, ugly blobs of excess.

On the non-text portions of the build, Skeinforge 50 is producing the best results, though it's also pushing through a little too much plastic, so that the engraved clock-face detail gets filled in.

Suggestions?

JCE

Re: Quest for High-Detail Prints

Jetguy 29 Aug 2012 17:00

m trying to print an object that I composited in OpenSCAD from DXF files generated in Inkscape

Sorry, but right there is your primary problem. It's known that you could end up with a model (STL) that is not suitable for printing but looks just fine in your CAD programs.

It's not the machine or the slicing program's fault, the 3D model likely has surface issues not obvious. I strongly suggest you try running the STL through Netfab, either local or through the cloud and "fix" the stl. Also, if you post it or PM it, I cna attempt to better address the issue and settings.

Also, I don't know what gcode viewer you are using and or you know that the makerbot firmware and rep-g uses a binary compiled version in the USB and S3G versions of the code, thus the munge, it's not human readable.

Last edited on 29 Aug 2012 17:10 by Jetguy Show more

Re: Quest for High-Detail Prints

Joel Craig Ewy 29 Aug 2012 19:42

Thanks for the reply. I downloaded the free version of Netfabb and loaded up the STL. It appears that Netfabb doesn't see that there are any problems with this model.

I assume we're looking for different problems here than the problems one can have importing DXF files into OpenSCAD. When OpenSCAD chokes on DXF import it appears that it simply won't render the file until it is modified to make it happy. But I suppose there could still be subtle problems that don't prevent OpenSCAD from rendering but still bug Skeinforge, but they're also apparently slipping by Netfabb.

As for the munge, I was referring to what Skeinforge was apparently doing to the detail, not the way the gcode itself looked. I've been generating ASCII gcode, not the binary kind. The gcode viewer I've been using is Tatlin, and it does load up and display the gcode files.

The forum won't let me post any links, but if you go to docs dot google dot com slash open?id=0B9rrh6eD7eHkZWlrbFRyVjVRYWs I think you should find a screenshot of what the STL file looks like loaded up in Netfabb. It doesn't have any warning symbol. If you go to the same place and look up open?id=0B9rrh6eD7eHkajJkQlA4NXA4T0U you should see what happens when I do a part analysys.

Do you want to check out the STL?

JCE

Re: Quest for High-Detail Prints

Yanisin 30 Aug 2012 07:02

Hm.. I'm not sure about the "minute" marks but the "five minutes" marks might be visible.
I also tend to say the model is not really suitable for ToM.
Generally If you want to print such narrow grooves. You should project them much more wider than you expect the result. (It's best to experiment on some simple example before, also take in mind that the combination of speed and temperature may have visible effects)

What you can try is to exactly calibrate the wall widht. (print the 2x2x1cm cube with the fill module disabled and measure if the wall thickness is exact).

Maybe you can try to extrude a little bit less plastic then really needed. But you will most likely get some holes in the solid surfaces as well.

I'd also try to extrude as cold as possible, and as thick layers as possible. If you "really need" that badge, it should be possible but expect hours of experiments (with tuning model and settings) untill you get it right.

Re: Quest for High-Detail Prints

Joel Craig Ewy 30 Aug 2012 16:11

Thanks for the reply, Yanisin.

I recognize that I'm probably pushing it with this design, but my test prints have led me to believe that I can get pretty close to the desired results. If necessary, I can scale the build up just a bit. But I've got to figure out how to get gcode that retains all the necessary detail.

If you'd like to see my test prints, enter the same URL as above, and add:
open?id=0B9rrh6eD7eHkeVpHM0xWajlJV28 <- SF35 & SF50
open?id=0B9rrh6eD7eHkbDl2aklrRVJfd2M <- Slic3r

In the SF35 and SF50 prints you can see that the minute mark details do show up, though if I wanted to make them distinct from the circular groove, I would need to separate them a little farther. The Roman numerals are almost visible in the SF35 print, but are filled in with too much plastic in SF50. On the other hand, the surface finish in SF50 is much smoother, and for some reason the scroll isn't properly filled in with SF35.

FWIW, I stopped the first Slic3r test print before it was finished because it was already clear that it was extruding too much plastic and wasn't going to build correctly. I reduced the "extrusion multiplier" parameter for the other two, and on the second one (at E.M. =.5) it built the shield part fairly nicely, but still used way too much plastic for the upper layers. There didn't seem to be too much difference between E.M. =.5 and E.M. =.15. I've seen similar problems with SF50 on the TOM, related to M108 codes being commented out by replace.csv, and I suspect Slic3r is doing the same thing. (See t-543430 in this forum.)

Finally, if you would like to see a visualization of the gcode that Skeinforge produces, look at:

open?id=0B9rrh6eD7eHkdlFTSThxYUdSLWM

You can see that the text detail is already gone from the gcode that Skeinforge produces. The text portions look pretty much the same between SF35 and SF50. The Makerbot actually does a pretty fair rendition of the text as it appears in the gcode.

JCE

Re: Quest for High-Detail Prints

Yanisin 31 Aug 2012 09:33

First.. To be honest I don't have much trust in slic3r. It's fast.. no doubt about it, but that's all.
I was never able to to get it produce a nice print. I'd say go the "slow skeinforge way".

Hmm. Maybe one more idea (sorry, but just idea, no success granted).
Basically it's good to have all "walls", fonts etc.. in every place the width of multiple of the "layer width" (how the hack is it called?, i mean the width of one line of the plastic you feed from the extruder after it smashes a bit after extruding on the print).
You should design your model with respect of that.
Maybe you should try to "tune" your model (or skeinforge config, but you can't go with the width below the nozzle dia) a bit.