Hi list
I did send a rather short summary.
My main points:
*Show the engineers/designers the problems real time so they can be
more knowledgable about the process. (We have set up a training area
for our shop people & will be expanding it to include all of
engineering next year).
*If you just reject a data base no one is helped. Again you have to
get the problems back to the beginning.
We are a prot-type model shop so we do work closely with the concept
people. We give ideas, design proto-types & feed info back & forth. It
is a very interactive process. It allows a lot of idea & process
sharing, that didn't occur prior to down sizing.
Some poeple take to this sharing a lot easier than others. Where we
can accomplish this we do meet the ideal. These others tend to keep
things close to the chest. They do good work, but slow the process.
We changed to Pro-E/Mfg 4 or 5 yrs ago. Since then we have brought in
Solidworks. This has cleaned up the internal data bases, but no
program is perfect. Iges, STL, Etc cause problems. We are working hard
to develop user interfaces that simplify all this.
I guess sharing & training are major issues to be faced by all. By working
as project teams these processes can be part of the program.
I was trying to be pro-active rather than point a finger.
Doug White
______________________________ Reply Separator _________________________________
Subject: ATTN: Doug White, RE: Future of RP
Author: Monica & Glenn Whiteside
<SiderWhite%worldnet.att.NET@prdnet.polaroid.com> at INET
Date: 12/7/98 8:53 PM
Doug:
You wrote:
> Hi List
>
> I enjoy reading most of the mail.
>
>I don't respond very often, but this could use a little refinement in light
of
>the "NEW CORP THINK"; "DOWNSIZING". The engineers have to do more hands on
&
>learn very quickly how to handle models. They now know it costs big $$$$ to
make
>a model.
>
>Rather than teach engineers/designers to be better "house keepers" we need
to
>teach them to input the data right the first time.
>
>When they transfer a poor data base it shouldn't be rejected; they need to
be
>shown their errors & the cost to the program so they will do better next
time.
>
>Sounds pie-in-the-sky; but that is how it will have to be. There is little
room
>for error in Global competition.
>
>Doug White
****************************************************************************
**************
Doug:
I don't think we should always point the finger and blame the engineers for
"bad databases" (manufacturing and production love to blame engineering for
all the problems). Engineers are typically given vague references to what
is needed and must come up with a "perfect" solution that has to meet many
criteria. This is not an easy or trivial job and most of the conscientious
engineers I know, me included, spend plenty of "hands-on" time on the
production line and in the labs testing to ensure our designs will work in
the real world the first time. It is compounded threefold or more when
management, in their ever-present bottom line cost reduction wisdom, gives
us CAD tools that just aren't capable of handling today's complex,
ergonomic, aesthetically-pleasing, and customer requested designs. Even
Catia, which is one of the more expensive design packages, has a hard time
handling some designs. We just don't live in a perfect world so several
different types of software are needed to successfully complete the job
(Nastran for stress analysis FEM, crash analysis programs, dynamic movement
analysis programs, etc.) and in converting between all of these different
packages sometimes a database gets corrupted. This is not the designer's
fault - he's just trying to do the best he can with the tools he is given.
One problem is the constant upgrades and new software that comes out - the
designer is busy enough with day-to-day tasks, it is extremely hard to keep
up with all of the changes and become proficent with them in a short amount
of time. This is a big problem with management - they think we should be
100% proficent in a couple of days - no way - it takes many different
designs and situations to find out the optimal way (or there could be many
optimal ways) to design a part in a particular software package - they're
all different in some way and all of them have "quirks" that you don't know
about until you find problems in particular parts. There is no "magic
button" or fairy dust to sprinkle on the keyboard to solve these problems -
it just takes alot of scope time and experience to figure these out. We're
fully aware (most of us anyways) of the costs involved but you can pay a
little more in the beginning or you can rush the designer and pay alot for
it later.
Yes, there is little room for error in global competition but unfortunately
when pushing the design envelope, things can go wrong, and this is the price
of progress and also the sign of a successful company that is willing to
take carefully weighed, calculated risks and try something new.
Regards,
Glenn Whiteside
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:47:33 EEST