From: Charles Overy (cwho@lgmmodel.com)
Date: Sat Dec 14 2002 - 02:53:19 EET
Paul,
>>Wow Charles - Who rained on your parade today?
Lack of snow up here can sometimes be as perceived here as rain would be in
other parts of the world.
>>Are you the new champion of STL?
Hardly, but based on the conversations on the list on the subject of STL it
seems like it is here to stay, at least for a while. I think it is a very
weak link in the RP process flow. However, it is a standard and A standard
is usually better than no standard.
>>What technology(ies) do you utilize to create physical models?
Form Z and Rhino to ZCorp 406 and 3 axis milling. Also sanding sanding and
sanding with a side of paint and prayer.
>>I always considered it to be part of my (designer) job to be aware of what
process or technology was capable of producing what I needed in the given
time-frame. It is not necessary to be an expert in the particular process,
but
you need to know enough to make sure you can get what you want, when you
want
and be aware any precautions that may need to be taken to ensure your vendor
can
deliver.
I agree that when RP is part of the process flow, as it can be in some
projects and for some parts, there is value added in making sure that the
prototype flows easily from the digital data. This is particularly true if
you, as it sounds from the above, are sometimes designing under a time
crunch, specifically to get an RP model in someone's hands. This is really
what we end up doing most of the time as well. Although we are not really
designing, we are usually just redrawing someone's data in order to make it
RP'able. This process works however it is an artifical construct of the RP
process. Clearly the RP technology is capable of building close
approximations of what the model should look like. However, the data
conversion often prevents us from getting a model of what we see on the
screen.
The point however that I was trying to make, but clearly failed, was that
having to design for RP, or consider the "RPability" of a particular design,
has negative impacts on the overall value equation given that the final
product is rarely an RP model. Simply put having to design for RP adds
complexity, increases the total product cost and thereby reduces the overall
value of RP. The greater the need to design to the RP process, the greater
the "fork" that the RP data takes from the primary path of concept to final
product, the greater the reduction in value.
A broader augment would be that all processes along the manufacturing flow
are an important part of "design for manufacturing" or "design for build
ability". In the purest sense I would agree. However, right now RP,
particularly conversion to STL adds artificial constraints to the
visualization process.
Best
C
-----Original Message-----
From: owner-rp-ml@rapid.lpt.fi [mailto:owner-rp-ml@rapid.lpt.fi]On
Behalf Of Paul Suomala
Sent: Friday, December 13, 2002 2:28 PM
To: cwho@lgmmodel.com
Cc: rp-ml@rapid.lpt.fi
Subject: Re: Multiple Parts saved as One STL file
Wow Charles - Who rained on your parade today? Are you the new champion of
STL?
Yet you cast aspersions at RP processes?
What technology(ies) do you utilize to create physical models?
Actually, I must take exception to this statement - "None of those items
are
things that the designer should be concerned about. They are all RP
issues."
I always considered it to be part of my (designer) job to be aware of what
process or technology was capable of producing what I needed in the given
time-frame. It is not necessary to be an expert in the particular process,
but
you need to know enough to make sure you can get what you want, when you
want
and be aware any precautions that may need to be taken to ensure your vendor
can
deliver.
When the design is in the "fluid" state, isn't it usually the designer who
ends
up carrying the load? After all, the design is in their mind and they are
really
the only ones who can relate what is in their mind (so far).
Best regards,
Paul S
Charles Overy wrote:
> 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:45 EET