RE: Multiple Parts saved as One STL file

From: Scott Tilton (stilton@protoprod.com)
Date: Fri Dec 13 2002 - 21:45:38 EET


Whoa . you scared me . . with that RANT warning.
I thought you were going to flame me.

Whew.

I've got another comment about scaled down models of CAD files for RP.

It was important for me to point out to the design engineer (who has, but
the way, designed MANY parts made at full scale in RP) to keep in mind what
all happened when things are scaled down. He assured me he understood
everything and I didn't need to instruct him as if he were in elementary
school.

He spent some time and went through the model and tried to get rid of any
detail that was under the threshold of what could be made by RP in the scale
model.

After doing all that, he went ahead and saved the STL file with the same
high accuracy that he does for the small widgets and gizmos that he has made
in the past.

If you save an object the size of a truck at .0005" maximum chordal
deviation . . you are going to get one extremely large STL file.

Which is exactly what happened.

I went back to the design engineer and explained this and suggested an
accuracy value of 0.010" for the 1:20 scale part.

He understood . . .but then cut his eyes at me and asked if loosening up the
accuracy that much might have negated the need for all the simplification he
did on his design to make it RP'able.

I answered "no. . . not all of it. But probably some of it."

I guess sometimes you just have to learn the hard way.

A better process would have been to save it at the low resolution . .
Evaluate the resulting STL file . . then go back and see what needs to be
addressed.

Or I suppose you could scale the model file down before exporting to STL.

And yes I know . . you could also take one of those gee-whiz software
packages (MAGICS, etc) and start booleaning in all sorts of simple objects
to fill tiny gaps and add necessary support if needed.

Thanks for all the support and offers for help on my question.

Have a good weekend (all you folks who get to go home that is)

Scott Tilton

 -----Original Message-----
From: Charles Overy [mailto:cwho@lgmmodel.com]
Sent: Friday, December 13, 2002 2:02 PM
To: Jeffrey Everett; Scott Tilton; rp-ml@rapid.lpt.fi
Subject: RE: Multiple Parts saved as One STL file

Jeffery,

Warning - RANT-

I have to take you to task on this one. As Scott point out, the data is not
WRONG! It correctly describes the part in a manner that is necessary and
sufficient to communicate the design. I read Scott's problem as one that we
frequently have; the translation to .stl and the scale down, combined with
the current nature of RP technology make the part unbuildable. None of
those items are things that the designer should be concerned about. They
are all RP issues.

 So many times on this list and at trade shows and speaking to others in
model shops, the attitude to degenerate .stl files is to send it back to the
designer because they must have done something wrong. Or to blame the CAD
software for "allowing" a bad .stl to be written etc. In my humble opinion,
CAD is correct when it correctly describes the part, object, structure, to
the primary downstream process, be that casting, machining, movie
compositing, or a framing crew. Rapid Prototyping is only sometimes directly
part of those subsequent operations. If we, as a community, throw up our
hands every time we run into data that are not specifically oriented
towards RP, we will continue to ignore or at least underserver a large
potential market.

At conceptual design in architecture, we are often asked to make a 3D model
when the CAD is very incomplete and the design is very fluid. Most of my
customers could not care less how the model is made as long as it is fast
and is percieved as a good value. We, therefore, are in the business of
providing visualization tools, primarily physical models. We are not in the
business of operating RP machines. In fact, I doubt very much that there is
a viable actual business of "operating RP machines" although more than a few
people both inside large companies and outside have tried it.

Just my two cents.

Happy weekend to all. Don't spend it shopping...

Charles

-----Original Message-----
From: owner-rp-ml@rapid.lpt.fi [mailto:owner-rp-ml@rapid.lpt.fi]On
Behalf Of Jeffrey Everett
Sent: Friday, December 13, 2002 10:24 AM
To: Scott Tilton; rp-ml@rapid.lpt.fi
Subject: Re: Multiple Parts saved as One STL file

I may be way off, but here's an idea no one presented. Ask the designer to
fix the part so there are no overlapping edges...

Jeffrey Everett

----- Original Message -----
From: "Scott Tilton" <stilton@protoprod.com>
To: <rp-ml@rapid.lpt.fi>
Sent: Friday, December 13, 2002 7:40 AM
Subject: Multiple Parts saved as One STL file

> Hi guys,
>
> I have a STL file of an assembly that was created in SDRC I-DEAS.
>
> The person who did all the design work on it, while still in I-DEAS,
merged
> all the individual parts into one supposedly solid piece. Then he
exported
> that merged piece out as an STL file and is asking me to make a model of
it
> for him.
>
>
> The problem is that when I go and look at the preview of the laser scans
for
> each layer, I can clearly see that it is still taking each individual
part
> of the original assembly and treating it as if it were a separate element.
>
> Anywhere two of the elements overlap . .. the Sinterstation is actually
> going to scan those areas twice (or three times if there are three objects
> occupying the same space)
>
>
> I had the same problem with some architectural models that were sent to me
> one time . .and the architect was able unify or merge all the parts in a
> different way so they became one completely solid piece.
>
> He was working in some AutoDesk product or another though, so he couldn't
> help with IDEAS.
>
> Anyone have any sort of clue how to handle this?
>
> I'd hate to have to resort to exporting everything out in IGES (or some
> other format) and then importing it again and finally saving it as an STL.
>
> Any help would be greatly appreciated.
>
> Thanks
>
>
> Scott Tilton
>
>
>



This archive was generated by hypermail 2.1.4 : Tue Jan 21 2003 - 20:14:44 EET