solidworks, IGES help

Hi,

I'm trying to import a large IGES file. The problem is that it takes
SWX 30 minutes to read in the file. And when it does it consists of
thousands of separate surfaces and slows my machine to an unacceptable
level. I have used Pro/E for similar tasks in the past and it only
took a minute or so. In Pro the file comes in nice and clean as a
single solid. How can I do this in SWX 2006?

TIA
MT

Did you check the options on the IGES import? Make sure try forming
solid is checked.

KM

@g43g2000cwa.googlegroups.com:




Have you imported this particular file in Pro/E? Do you still have
access to Pro/E to try it out?

30 minutes really isn't that long. I've imported large IGES files that
I've had to leave it running overnight (several hours to import) and have
had different results depending on the complexity of the file and the
system that created it.

In theory, when you select File...Open... IGES, click the options button
in the dialog box. Check the Surface/Solid entities box, and "try
forming solids". You may experiment with other options to try to improve
your results. Being a large file, there is likely nothing you can do to
speed that up short of upgrading your PC.

I've already seen that SW2006 is better at importing large STEP files.
I'd assume that similar improvements were made to IGES importing. Good
luck.


MHill

On Wed, 25 Jan 2006 17:20:39 -0000, MHill



I wonder how much the order & the structure of the IGES file
impacts this.
--
Cliff

A lot depends on the source of the iges file. If the source system
exported surfaces with low tolerances, then SW spends a ton of time during
import trying to get stuff to match. This is especially true of pro-e, if
that is the source system. Have whomever sent you the file look through
their export options ( perhaps even calling their var for assistance as the
options are not always easy to find ) and see if there is anything that they
can do on their end to help. Things like joining surfaces together,
increasing their edge tolerances, ect.. can make importation much less
stressful. If they have ancillary surfaces that they needed for part
creation, but are not pertinant to the final part, ask them to not include
them in their export.
--
Brian Hokanson
Starting Line Products



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

> ... especially true of pro-e ...

No more so than any other system that allows user defined model accuracy (well,
their relative accuracy scheme, if used, might possibly contribute but they're
probably also contributing to geometry checks which are responsible for more
problems than accuracy, if I were to guess). The IGES lists the accuracy that
was used to generate the data set. Check it if in doubt.

Have them send you a STEP if at all possible, or a b-rep IGES; something so the
target system doesn't have to (guesswork) re-create manifold edges.

A note on Pro/E (probably applicable to others): More than a few "problem
files" are ShrinkWrap exports. They are not necessarily intended to be solids.
Get with the source and ask them if in doubt.

ProStep.org has some pretty good export / import checklists that might help in
getting you a good translation.

A previous post suggested that the "try forming solid" option is
checked for the IGES translation.

Keep in mind that having this option active will add to the time it
takes to import the data. Consequently, in many cases, it is better to
turn the option OFF to then view and analyze the resultant surfaces
more quickly.

Once the imported surfaces are displayed, the Import Diagnosis tool can
be used to selectively repair and eliminate gaps which may prevent
successful knitting into a solid. Aside from (or in addition to) the
Import Diagnosis routines, the user can choose to use various surface
deletion, replacement, trimming and construction tools to clean up the
translated data.

I have often found that a collection of imported surfaces will include
some which are untrimmed or representative of interior features. When
the interior surfaces (which have nothing to do with those representing
the outside, otherwise closed envelope of a potential solid) are
eliminated and others trimmed or replaced, knitting a solid object
becomes possible.

So again, especially for large files, my advice is to avoid using the
knitting option as the default for importation, since knitting will not
necessarily be possible without user (manual) intervention and there's
no advantage in waiting longer to learn of the failure...

Per O. Hoel

Check this document out I don't know where it came from but it gives
you a clear understanding of why PRO-E can output really good data and
sometimes it puts out really bad data

Pro/E IGES and STEP Settings
Pro/E uses very open tolerances to create its models. This is a real
big problem when trying to import data from Pro/E into other systems.
When working in solids it is very important to keep tight tolerances.
The default accuracy is only 0.0012 mm. Below are settings, and how to
implement them, to be able to export good models from Pro/E.
Here are the recommended translation settings for Pro/E models:
The most important requirement for either STEP or IGES is to increase
the part resolution. The Pro/E default is a relative accuracy of 0.0012
mm. The accuracy in Pro/E should be set to an absolute value of 0.0003
mm as a minimum, and preferably 0.00003 mm. It is possible in Pro/E to
change this value on existing parts and than regenerate them.
Page 10-52 of the Pro/E Release 17 Part Modeling User's Guide describes
this process.
IGES Interface settings for Pro-E:
IGES-out-all-srfs-as 128: YES
IGES-out-SPI-srfs-as-128: YES
IGES-out-SPI_crvs_as-126: YES
IGES-out-trim -Xyz: YES
IGES-out--nlil-d-28000: NO
IGES-out-trm-Srfs-as-143: NO
IGES-out-JAMAIS-Compliant: NO
IGES-out-trim-curve-deviation: DEFAULT
IGES-out-dwg-color: YES
You can influence the accuracy of intersection curves (of faces) during
IGES output in Pro/E by modifying the parameter "IGES out trim curve
deviation".
By default this value is set to the parts accuracy, i.e. the default
part accuracy is 0.0012 mm. You might want to recalculate the
intersection of faces during IGES file generation to 0.001. This can be
done by setting IGES-out-trim-curve-deviation to the new value of 0.001
The following settings apply for STEP:
intf3d-Out-surface-deviation: N/A requires export surfaces as
unsupported #114
intf3d-out-extend-surface: NO (You could try YES as well. Keep an eye
on self-intersecting surfaces)
intf-out-blanked-entities: NO
intf-out-max-bspl-degree: 16 or less
intf-out-as-bezier: NO

But their product is paper "drawings" so why bother getting 3D
models correct?
--
Cliff

> ... I don't know where it came from but it gives

It would seem to, but I've got my doubts. Not sure how much stock you can put
in what someone says when they don't know that relative accuracy values are
unitless ...

Stated in equation form:
A < F * s / d
Where
A = recommended relative accuracy
F = a factor based on part geometry (* analytic vs. spline, primarily)
s = smallest distance which the system will consider entities to be separate
d = diagonal of box whose sides are parallel to default coordinate system axes
and which just encloses the part

* = my comment

Another common misconception is that because relative accuracy or a loose
absolute accuracy value (my default is .001 inch, works great, corresponds to
the default ACIS variable ResFit) is set it means an overall loose model. Not
so, very much geometry dependant.

There's no doubt that accuracy ~can~ be a factor, but it most often will cause
problems in Pro/E before it will cause problems for modern (most of the "common
knowledge" on the subject comes from old Adsk / ACIS propoganda, no? If SW is
going to follow that track; question them critically) CAD system translations.
Most of the time there are other, more important factors in play, such as the
previously mentioned (GeometryChecks; if they are exporting their problems,
what can I say?) ability to complete a model despite ill defined geometry,
assuming an import is supposed to make a solid when that's not the intent, etc.
So, by all means question the accuracy but there are usually more important
questions to ask. If you have an open line of communication with the source ask
them to regen with an absolute value of 1e-3 to 1e-4 inch (for an "average"
part) without GeomChks and see if it helps. SW should have no problem with
it as STEP and there are a Lot of Other considerations if IGES. The 1e-8
meter and 1e-6 (unitless, mm assumed) values Parasolid and ACIS like to throw
out are ludicrous for anything besides boolean operations on cubes and have no
direct correlation to the accuracy values set in Pro/E. If they do you are
waiting way too long for your variable rad rounds, sweeps, blends, etc. to
solve. `;^)

(It's my guess that MT is just trying to tell you how much better Pro/E reads
IGES since not much else has been said about the data set, what it contains,
where it's from, etc. If that' true, I'd guess it's because PTC has invested
more in their IGES translators.)

Jeff,

Below the first paragraph is a document (Not mine).
The document I have forwarded to many a person having problems with
Direct imports or Iges imports originating with Pro/E. All I know is
that when these settings are used in Pro/E the imports come in to
SolidWorks 100 times cleaner with little to no gap errors.

Corey

/*******


Jeff,

Below the first paragraph is a document (Not mine).
The document I have forwarded to many a person having problems with
Direct imports or Iges imports originating with Pro/E. All I know is
that when these settings are used in Pro/E the imports come in to
SolidWorks 100 times cleaner with little to no gap errors.

Corey
******/

I don't really doubt that but did take exception to "it gives you a clear
understanding of why PRO-E can output really good data and sometimes it puts out
really bad data". The document doesn't give anyone much understanding of
anything accuracy related except that it can be user specified and I don't
believe accuracy is responsible for some / much / most (? I have no idea) of the
"really bad" (e.g. won't make a solid?) data people see coming from Pro/E. That
was my point and might add that not many, myself included, users of any CAD
system really understand much about accuracy as it pertains to geometry
representations. The 1e-8, 1e-6 values, for instance, are simply the lower end
of, usually, ten to twelve digits of accuracy available to the system for
describing position and are not an indicator of the accuracy of all calculations
and definitions. I cannot over emphasize how grossly over simplified the usual
explanations are. If there was anything simple about the subject all CAD
systems aspiring to do anything more complex than boolean operations on
primitives would allow user defined model accuracy (? guess that's arguable).

I don't doubt or question the significance of accuracy's role in translations.
Just trying to say it's not a one size fits all answer to all translation
problems and that it gets more attention than it deserves (? maybe, I don't
claim eggspurt status re the subject). One might question the operators'
qualifications if you had to send the document or even if its contents were more
significant than simply taking a good look at the model and cleaning it up.
Pro/E does allow users to create some pretty poor surfaces (dense, irregular
with little creases on the edges, etc., same stuff you might see come out of any
system) and it can / does struggle with a lot of those definitions as well as
some inherently complex geometry like fillet / round blends no matter how
coherent the definition. Some of it fails if accuracy is tightened. Some,
contrary to myth, fails if accuracy is loosened. Once you wander off into
export of surfaces (unfortunately Pro/E's default, the one "button pushers" will
use) vs. solid or shell reps via IGES the odds against a simple explanation go
off the chart.

(For those that have a copy of Rhino, there's an interesting bit in Help, I
think, re the subject that demonstrates some reasons why joining a set of
unordered surfaces can be problematic. Accuracy does play a part. It casts a
little light on the subject, gives some appreciation of the difficulty of
programming functions to do it and might explain some of the bad rap IGES gets.)

In summary I agree; question the accuracy. The rest is, I think, debatable or
at least makes for some interesting discussion. `;^)
.

Now just to clear things up I wasn't trying to say that Pro/E outputs
crap or that it is somehow inferior to SolidWorks. I was trying to
portray that Pro/E parts coming into SolidWorks either directly or
indirectly leaves many surface gaps due to the differnece between the
programs in gap tolerences among other things (as you stated such as
bad modeling in general and a blood red tree) At this time this can
only be corrected by Pro/E tolerances for exports and possibly healing
through SolidWorks or a 3rd party addin. I would guess that Pro/E uses
the lower tolerances for speed and I am sure it works just fine within
Pro/E SolidWorks just doesn't like it.

Got it, champ.
Have a good one.

A good resource.
http://www.prostep.org/en/services/bp/cadkombi/proengineersolidworks.htm
Not specific to IGES but the basics are the same.