I found the interesting similarity while working on different CAD
Each package has a command window,screen menu (ideas,proe and
One may find it obvious But why I am posting the related question is
today there is a "windows gui used as an standard" for CAD package
interface but when the CAD industry was in its infancy stage , how
came all the above packages used the almost-same terminology and
was also there a standard then for such things?
(I omit solidworks from this because it has been developed
recently.Does anyone know a dos or unix version of solidworks?)
somehow I feel PTC used the autocad interface(screen-menu) for their
Proe package as IDeas was graphical-menu based right from the start?
awaiting for your opinions on this...
You have a lot of questions on how CADs are build, Yogesh... Want to make a
new one ?
CADs are similar for the same reason that a car is similar to another car :
innovation is (usually) an incremental process in which competitors improve
an existing product by taking good ideas from the competition or from the
same research work...
Besides, learning time is an important factor in user cost, so any user
interface (UI) should be as intuitive as possible to reduce it where
"intuitive" generally means "as close as possible to other software's UI..
Remember that a "standard" UI might be significantly different from an
"optimal" UI . The best story I have is the QWERTY keyboard, which was
designed to SLOW DOWN the pace you could type on mechanical typewriters, to
prevent the hammers to collide while typing. There would be much more
efficient keyboard layouts today, but training time makes them commercialy
So if you intend to write a new CAD, you should probably stick as much as
possible to the UI of existing ones.
No, but it's coming. "Do you hear that sound, Mr. Anderson? It is the
sound of inevitabtility".
The last release of I-DEAS, I-DEAS NX 12, will be released in the
latter half of 2005. After that, I-DEAS users are expected to migrate
to UG NX 3 (or later) before 2008, when I-DEAS support is scheduled to
I-DEAS and UG will be basically interoperable as far as data goes by
I-DEAS 12. Interface and functionality-wise, the I-DEAS philosophy is
basically being scrapped in favor of the UG model. At least that's
what the users are seeing so far.
SolidEdge and SW were being develped roughly at the same time. I was
under the impression that SE started first. Integraph botched the first
release of SE (missed release dates etc) and SW came out with a working
piece of software almost a year earlier. Note I said "working."
Go back and look at the UG Museum.
Some of the CAD packages were started from Hanratty code, Computervison,
Unigraphics, Anvil, AD2000, AutoTrol, etc. A few were started from scratch,
Intergraph EMS, Applicon, Ideas, CATIA, CADAM, and late to the game Pro/E.
After these were established, then came the Windows interface systems:
SolidWorks, SolidEdge, and the CAM programs. A lot has changed in the past
23 years since the PC appeared on the market and even more has changed since
One reason the new Windows systems look the same is that they all use the MS
API for the GUI. It has significantly reduced the cost of developing a
system if you can use canned routines for the GUI. The other thing that has
helped these systems is that they bought the solid modeling kernel instead
of developing their own.
Most of the systems I mentioned have been merged with other systems. UGS
owns the Parasolid modeling kernel used in SolidEdge, SolidWorks and
Unigraphics. They also have purchased over the years Applicon, which had
earlier merged with Applicon, Ideas and Intergraph's CAD business, SolidEdge
and EMS. Pro/E bought a good share of their market when they bought
Computervision. Most of the company I work for was Computervision, so we are
now using Pro/E. We still have a large share of UG seats.
"yogesh" < email@example.com> wrote in message
One of the ways to express a straight line.
After you've established the context "Hey, look, they're showing us pi,"
decided on a base... Then you need to start constructing sentences to
The reason behind constantly asking you about CAD,parametric design
and other related questions is...
The person under whom I am completing my project is very much against
using drafting packages as he thinks now a days all the *CA-Design*
package produce drafting as a biproduct so there is no need to learn
the drafting packages as such.
and I also followed his views till some days back.But it's very hard
to understand the parametric and feature desing concepts without not
knowing the principles of *CADrafting* as in *CADesign* literature
also the limitations of drafting package are referred while
explaining the above terms..So I was under lot of confusion whenever
he was refering to the terms like constraint based and other terms.So
I started learning autocad by my own and now I have almost a mature
view of the terms used in Design and Drafting.It is a sort of
revealation to me now as I studied the CAdesign packages first , then
learned drafting packages and now studying both with historical
perspective in mind.
while working on solidworks,catia,UG,Ideas and Proe I observed
all the packages except I-DEAS used the sketcher and datum plane
and also IDEAS seems to be more easy than any other packages.?
eg. How to draw a through or blind hole starting from one vertex of a
cube and diagonally cutting the cube or how to draw a hole on the
cylindrical surface of a cylinder.?
In Ideas you can rotate or move the reference planes but I have not
seen this facility in SW or CATIA?
How to do the above things in other packages?
firstname.lastname@example.org (yogesh) wrote in message
Your mentor is correct in the vision, however the reality today falls
quite short of the mark.
The key problem area lies in communicating the design intent outside
the modeling system. Very few MCAD systems today support the elements
needed to properly represent design intent outside of the 2D drawing
context. Notably, I-deas has this in the form of PMI data that exists
as fully 3D model annotations that can include most common design
intent representations directly on the model. (ie: tolerance, GD&T,
Manufacturing notes & such..)
Those systems with this capability still only address half of the
problem. Viewing this data outside the system is problematic in that
either a license of the system is needed to directly use the data, or
the data must be exported to either a neutral format (VRML, for
example), or a semi-neutral format for use with view/markup software
of some sort.
Other issues involve access to the data in many different settings.
3D representations can be viewed and printed, but still require heavy
resources to actually move about as easily as 2D representations do.
This can sharply limit what data people have access to, particularly
when they are working off-site away from the master data repository.
Having said that, many 2D techniques such as layouts can continue to
be useful in the 3D context when used as the basis for associative
These basic problems, combined with the lack of appropriate features
and problematic translation of even basic features between systems are
the primary drivers behind ongoing 2D work today.
For some problems, creative feature based tolerancing can go a long
way toward addressing the communications issues, however geometry
translation can still be an issue in many cases.
I agree with the core idea that drafting packages should see less use,
but we have another basic problem to solve (assuming the above can be
reasonably addressed. That problem is compute power. The CPU's of
today cannot easily manupulate full parametric, feature-based model
representations easily. The bottlenecks of both computer power and
RAM to hold the result limit what can be done on a PC, while more
expensive UNIX systems can hold the datasets, their CPU power is
lacking and they are expensive.
The mostly sequential design of most MCAD packages today also prevent
multi-threading, and or clustering from addressing the compute side of
things, at least where MCAD is concerned. (Analysis tends to benefit
greatly from at least the clustering technologies today.)
On the PC, the win32 OS places a constraint on RAM as well. Linux
holds some promise in this area, but few systems have ports at this
time able to really take advantage of the additional addressing
capability. (Also PC hardware vendors largely target the win32 OS,
for good reason, making this even more of a niche approach for MCAD at
Personally, I am not sure the parametric systems will ever get there.
Variational systems exhibit strong potential in this area, but they
are not the majority at this time. (I-deas being the most variational
one out there, but with strong parametric leanings at this time.)
Both of these will eventually get addressed one way or another, but
until that time we will continue to be limited on model size. Most
systems today employ clever (and some not so clever) schemes to enable
the user to easily address parts of the model as needed for authoring
While these limits are in place, 2D methods may continue to provide
enough benefit to justify their ongoing use for some time yet.
I-deas does use the sketcher concept, though it does have both 2D and
3D representations, making things difficult to nail down. A datum
plane is pretty much equal to an I-deas reference plane and or
An I-deas sketch plane can be a reference plane, solid model face, or
just a set of points in space the user can directly manupulate in a
No disagreement here :)
The difference lies in the constraint model used. Strictly parametric
systems basically require that everything be associated, or built off
of, a few primary data points, such as a base coordinate system, or
set of planes.
If you want to rotate a reference plane (datum) in these systems, you
must build that capability into the model in advance. (Violates
Doug's rule of CAD.) Another option would be to redefine the
references used to construct the plane at a later time. (Pro/e, for
Both options demand, from the user, either advance knowledge of the
model and its potential changes, or in depth knowledge of both the
system and the particular model representation of the model at hand,
in order for the user to make the appropriate changes.
I-deas will allow both the parametric model, or a hybrid approach to
be used. This is hard to explain, without writing a short book...
It works like this:
Anything you build associative to something else that is a part of the
model definition, and is itself associative to the primary coordinate
systems will act as parametric things do. The system will make the
appropriate changes when requested. The definition itself captures
design intent along the way.
Anything you define in a non-associative way, such as via cursor pick,
or via the transform commands, will be associative in every way except
for the actual transform data. (You can think of this as keyed in
data generally not allowed in strictly parametric systems. Generally,
these methods fail to capture design intent in the expected way.
So, if you were to build a loft, for example, using the strictly
parametric model, you would have to first define a bunch of planes to
sketch on, then the sketches, then the loft. Each part of the loft
could be changed according to the flexibility for change built into
You could also just build a bunch of sketches in space, or import them
--it makes no difference, then build the loft. When changes are made,
you would be in charge of the spatial location of the loft sketches,
while I-deas would take care of the rest. Assuming the sketches were
built in an associative way, that is...
If they were imported, for example, the entire loft would require
manual modification not too different from the older non-parametric
systems, yet parametric features could be built onto that same loft
that would respond as expected to reasonable manual changes.
So, I-deas is a hybrid modeler in that it can be used in a highly
parametric way, but that requirement is not enforced on the user.
While this does make some things easier (like assembly, and use of
outside model data as the basis for in-system parametric models), it
can cause a lot of problems for the user, unless the underlying
concepts are well understood.
email@example.com (yogesh) wrote in message
You are welcome. I had a bit of free time and some interest in the
subject. Personally, I wish the MCAD industry today would give these
basic issues greater consideration beyond the simple product
differentiation we see today...
We might actually get more done.
UG was owned by McAuto.
Unigraphics ownership over the years has been:
United Computing (John Wright, founder)
McDonell-Douglas and its various divisions including McAuto, M&E, etc
UGSolutions (Public Trading with EDS still owning 86%)
Private Venture Capital.
IGDS was Intergraph which was not Hanratty code.
"Bruce Treffinger" <bruce.k.treffinger firstname.lastname@example.org> wrote in message
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.