From: Blasch, Larry (LBlasch@OPW-FC.com)
Date: Tue Feb 25 2003 - 18:20:28 EET
Charles and list,
I am on record saying that we no longer need to use STL data when building
parts created with a solid modeling program. It is at best a crude
approximation of the "surface" of the 3D model. I would prefer to build
parts from the CAD file.
Using STL for part data transfers is like sending MSWord files in fax data
format. Sure, any fax machine can print it... so what! The data format is
not representative of the original and the resolution sucks. Ok, you can
increase the resolution and make the files get larger and larger. RAM is
cheap and the processors get faster all the time, but it's a never ending
spiral.
I can export virtually any CAD solid model file from any competent CAD
modeling program into a neutral file (STEP, ASICS, PARASOLID...) and can
import that data into any other competent CAD solid modeling program. The
data is substantially more accurate and the file size is tremendously
smaller than the best STL representation. (Yes, I get translation errors too
but they are a lot easier to deal with.)
I gave up on using STL files for RP data import and insist that I be the one
to create the RP output file myself. I was able to do this by demonstrating
the inaccuracy of the customer generated STL files graphically. Just use any
of the STL viewers available to output a rendered image of the faceted file,
send it to the customer and ask for the data to be exported in CAD file
format. I even indicated on quotes that I cannot control the accuracy of the
RP part if they don't provide data that I can work with.
Before I get flamed, Yes, I know that not everyone works with competent
solid modeling software. If your CAD program sucks get a better one and
don't complain to me.
MRI, CAT Scan, laser... and all the other 3D data acquisition formats can
use STL to their hearts content if they want to. The resolution of the files
created by all of these systems is determined by the scanner setup. You get
what you pay for. There are all sorts of programs that are written to refine
crude data, but we shouldn't need to use it for solid model generated
output.
By the way, maybe we don't need an RP certification process... It was just a
suggestion!
My humble opinion,
The above correspondence contains, my opinions, and such. If you disagree
with me, send $100 to the address below and I'll consider your point of
view.
< System Administrator Alert:
>
< From: System Administrator
>
< Subject: The recipient(s) mailbox is full due to excessive donations
>
Larry Blasch
Design Engineer
CAE Systems Administrator
OPW Fueling Components
P.O. Box 405003
Cincinnati, OH 45240-5003 USA
Voice: (513) 870-3356
Fax: (513) 870-3338
-----Original Message-----
From: Charles Overy [mailto:cwho@lgmmodel.com]
Sent: Monday, February 24, 2003 5:15 PM
To: rp-ml@rapid.lpt.fi
Subject: RE: Complete RP certification
I'm for making RP technology EASIER to use, not supporting unnecessarily
complex systems with certification.
(And of course protecting those obtuse systems with a monopoly. I have
never hired a MCSE as they tend to be more expensive and not very good at
creative, low cost, adaptable solutions that might include success stories
like Linux, PHP, POSTGRES, HTML, JAVA, 802.11b etc).
Ease of use is driven by an open, competitive, customer drive marketplace
with lots of user to vendor feedback, worldwide innovation and a broad and
diverse customer base.
That being said, I do think that, right now, with current technologies,
process education is a very good idea. I worry that particularly RP Service
bureaus, as well as vendors need to be careful not to over promise the
technologies particularly in niche markets. Different markets have
different input demands, jargon, and knowledge bases. We do architecture
and do it well, we don't do castings, jewelry, 5 axis machining, or product
development. Some end users are skilled enough to develop files that can be
run on any machine by most technicians. However, right now that is
unfortunately not the norm.
My RP "user friendly" to do list includes:
More technologies, (not certification for a few vendors products or
processes).
Further diversification into other marketplaces
Industry validation of product/ process niches
More open source standards including things like slicing algorithms
Burry STL below the user interface level.
Interface with parametric CAD modelers to create seamless "print drivers"
for RP.
The most important things that I think could be accomplished as a group or
industry are things like marketing, and communication to CAD vendors and CAD
standards groups.
IMHO, RP needs to become a pervasive output paradigm NOT an arcane craft.
Charles Overy
LGM
-----Original Message-----
From: owner-rp-ml@rapid.lpt.fi [mailto:owner-rp-ml@rapid.lpt.fi]On
Behalf Of Bathsheba Grossman
Sent: Monday, February 24, 2003 1:12 PM
To: rp-ml@rapid.lpt.fi
Subject: RE: Complete RP certification
On Mon, 24 Feb 2003, Blasch, Larry wrote:
> I therefore amend my classifications to:
>
> Novice... I made a part once...
> Journeyman... I have the keys/password to the machine/lab... (Sorry, I
can't
> think of politically correct term so flame away)
> Master... Not only do I know how to use the $#@! machines, but I
can
> get them to sing and dance...
> Consultant... I read an article on the subject, so now I can charge
> someone loads of money...
What about
RP Certified Whiner - I have not less than 100 complaints about why
your technology and business model are wrong, but I don't want to do
any work or invest any money.
But maybe this is the same as "User".
> I repeat my original suggestion which was:
> "If we as a group could create a certification process similar to the MCSE
> test, It might benefit us all."
Is there a large enough body of generic knowledge for this to make
sense? This industry seems very brand-linked at present, and I'm not
sure to what extent knowledge and expertise transfer between systems.
-Sheba
-- Bathsheba Grossman phone (831)429-8224, fax (831)460-1242 Sculpting geometry bathsheba.com Solidscape prototyping protoshape.com
This archive was generated by hypermail 2.1.7 : Sat Jan 17 2004 - 15:17:10 EET