IGES help

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

snipped-for-privacy@hotmail.com wrote in news:1138206672.636137.319040 @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

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.

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

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.)