Fwd: [reprap-dev] Using OpenSCAD for Mendel parts (long)
Bryan Bishop
From: Jonathan Marsden <jmar...@fastmail.fm>
Date: Thu, Sep 23, 2010 at 12:23 AM
Subject: Re: [reprap-dev] Using OpenSCAD for Mendel parts (long)
To: nop head <nop....@gmail.com>
Cc: repra...@lists.reprap.org
On 09/22/2010 03:58 PM, nop head wrote:
> I think Ed's holes are reasonable clearance holes on a Strat I think.
> M8 holes are 8.4mm. On my machine they come out about 7.99. ...
I have no problem with Adrian's principle of treating STLs as a source
file format that should represent the idea object as closely as
possible, resulting in a representation that is independent of the
quirks of the machine which will be doing the printing. How we get
there from here... is more interesting.
It is clear that the OpenSCAD work so far does not currently operate
according to this principle. Instead, it treats the OpenSCAD source
files as the idealized sources, and then introduces (parameterized)
fudge factors as it creates STLs from them. Vik's fudge factors,
apparently :) In this approach, I think STLs are being used more as an
intermediate file format, not intended to be edited and (at least
currently) not intended to be 100% machine independent. You wouldn't
expect the resulting STLs to be checked into a VCS, you'd check in the
.scad files from which they were generated.
So, the three current 'hole standards' in our STLs seem to be:
Adrian: Platonic ideal holes
Ed: Add 0.4mm, for "reasonable clearance on a Strat"
Vik: Pragmatically fudged to work right on his machine
Is this a fair summary?
If all the holes in eD's STLs for Mendel, which are in our svn tree and
have been for some time, do not conform to the Platonic ideal, but work
well for many people using standard Mendels, then... is it really
appropriate to idealize (platonify??) them now? Should we leave holes
in all Mendel STLs in SVN as they are, since Mendel is a released bot
already, and use the "Platonic ideal holes" approach for Huxley and
newer machines?
---------------
OK, now for a related, but different and more detailed, discussion...
svn log y-bearing-180-outer-left-1off.stl
gets me:
------------------------------------------------------------------------
r3803 | adrian-bowyer | 2010-09-22 13:09:58 -0700 (Wed, 22 Sep 2010) | 1
line
Fixed STLs.
------------------------------------------------------------------------
r3472 | adrian-bowyer | 2010-01-28 03:43:27 -0800 (Thu, 28 Jan 2010) | 1
line
Forrest's STL fixes.
------------------------------------------------------------------------
r3312 | EdSells | 2009-10-13 05:52:15 -0700 (Tue, 13 Oct 2009) | 1 line
Upload of Mendel's solid model files! Woowoo! Bring on the onslaught of
edits.
------------------------------------------------------------------------
So... these parts have already been "fixed" once, back in January 2010.
Why did they need fixing again now? QA people would be unhappy with
this need for repeated fixups :)
In passing, svn log entries with a little more detail on what was fixed
and why, rather than "fixed" or "fixes" could really help; I think more
thoughtful/detailed commit comments would be welcomed.
Grabbing each of the three variations of each STL, I get:
-rw-r--r-- 1 jonathan 27184 2010-09-22 20:48
y-bearing-180-outer-left_1off-r3312.stl
-rw-r--r-- 1 jonathan 27484 2010-09-22 20:45
y-bearing-180-outer-left_1off-r3472.stl
-rw-r--r-- 1 jonathan 120597 2010-09-22 20:09
y-bearing-180-outer-left_1off-r3803.stl
-rw-r--r-- 1 jonathan 27434 2010-09-22 20:48
y-bearing-180-outer-right_1off-r3312.stl
-rw-r--r-- 1 jonathan 27584 2010-09-22 20:45
y-bearing-180-outer-right_1off-r3472.stl
-rw-r--r-- 1 jonathan 27284 2010-09-22 20:09
y-bearing-180-outer-right_1off-r3803.stl
Cue Sesame Street "one of these things is not like the others..."! Why
is the most recent "left" file more than 4x the size of the others?
Because it's an ASCII STL, the others are binary STLs. But if the
current ones were both generated by OpenSCAD, that doesn't make too much
sense, does it?
Looking at the first 80 chars of each file is revealing, I did
for i in *.stl ; do echo $i ; hexdump -c -n80 $i ; done
and the resulting output shows that:
(a) The two r3312 originals were created in Art of Illusion.
(b) The two r3472 fixed files were created in netfabb.
(c) The left r3803 (current) file was created in Art of Illusion.
(d) The right r3803 (current) file was created in Blender in Windows,
by someone whose Windows login is probably Gary T.
This... is odd! Supposedly non-manifold STLs were ones that have
already been run through netfabb. And STL files purportedly from
OpenSCAD were not in fact generated by (or at least, were not last
edited by) OpenSCAD. The left and right STLs were created/edited using
two different tools.
The STL files in the
git://github.com/timschmidt/parameterized-mendel.git repository for the
y-bearing-180-* parts are NOT in fact OpenSCAD generated at all, they
are one of the remaining-to-be-parameterized parts, as far as I can see
(which makes me wonder why they are in that repo at all, since by
definition STLs cannot be parameterized... but that's the repo owners
prerrogative).
So, I conclude: (1) nop head's fear of Vik's OpenSCAD fudge factors is
unfounded, at least for these particular parts; (2) why the r3472
"fixed" files were reported to be non-manifold is a mystery; (3) I'm not
touching *any* of this in svn, at least until I am a lot more sure of
what is going on!
Questions Arising:
I Heart (are pseudonyms really necessary in this community?): Would you
please confirm that your copy of the mendel svn was up to date when you
tested these STLs for manifold-ness recently and found them to be
non-manifold, and please let us know specifically how you tested that?
Tim: Can you shed any further light on the provenance of these STL files
in your git repository?
Thanks,
Jonathan
_______________________________________________
reprap-dev mailing list
repra...@lists.reprap.org
http://reprap.org/mailman/listinfo/reprap-dev
--
- Bryan
http://heybryan.org/
1 512 203 0507
Bryan Bishop
> So STL files are not really open source...
STL files are like a compiled binary (yes, I know you can have an
ASCII STL file). The source code (like an OpenSCAD file, or a STEP
file) is what you really want. STL just happens to be popular, even if
it doesn't solve the needs of developers.
Bryan Bishop
> I totally agree on this one..
>
> STL is just stupid, hard to adjust etc (or with special 3d scan software..)
> And once a CAD file is triangulated it cant be converted back.. (or you have
> to use reverse engineering software).
Yeah, let's reiterate that- it's basically impossible to go back from
a mesh (like STL) to a CAD file. The only options are to use
proprietary software for that. There's lots of research in the
literature, but honestly none of us want to spend our time writing
that software (for surface reconstruction). Not only that, but once
you reconstruct the surface it's not going to be parametric anyway.
> I also prefer STEP (as nr.1 ) or IGES (as nr.2) and if triangulation is
You can have a STEP/IGES file that just has triangles too, but that's pointless.
> I worked many years as mechanical engineer and if we sended files out for 3d
> printing or molding or whatever, we always sended:
> - original parametric file (pro/engineer in our case)
> - STEP as universal CAD file
> - IGES as universal CAD file
> - STL (so we could control tesselation and print direction (with coordinate
> system) with 3d printing etc.. instead of manufacturer.
> advantage of STEP and IGES over STL is most CAD programs can easily change
> those, add offsets/shell them etc.
yep
> (however i dont work with openSCAD.. so not sure what that program can
> process for file types.
OpenSCAD is basically like povray, except it spits out STL. It doesn't
export to STEP or IGES. On this note, I have been writing a python
library that exports to STEP (ISO 10303-21). Right now it's a little
buggy and a little ridiculous, so I've dubbed it lolcad until it gets
to a friendly state. The code is awful at the moment but if anyone
wants to check it out..
git clone git://diyhpl.us/lolcad.git
So in the end you'll just write conventional python scripts to
generate geometry, then save it as a STEP file, and can import it into
whatever CAD program you want, or tessellate it using whatever
algorithm you wish, etc.
rectangular_plate = Rectangle("5 cm", "10 cm")
plate = rectangular_plate.extrude("10 cm")
sphere = Sphere(radius="5 mm")
thingy = plate.fuse(sphere)
.. etc. Anyway, this is slightly off-topic from the original
discussion. At this point, OpenSCAD models are still a better deal
than just committing STL files into a repository. However, since you
can only export to STL, some of the CAD benefits aren't available, and
I would strongly encourage everyone to think of OpenSCAD as a
transitionary tool until something better happens.
(Also, I've been meaning to write a configure-make-install cycle for
generating STL from scripts.)