I encountered an issue with this today that I thought I'd pass along.
We're running Wildfire 5.0 M080 (I know, Creo, but it's still just Pro/E to me). Almost five years ago,someone had some files that were exported from SolidWorks, saved as "Pro/E" files. He opened them in Pro/E, saved them, and they've sat inWindchill since then.
Today, an engineer tried working with these old files. The parts open fine in WF5 M080 with no warnings of any kind. They just look like any other importedpart, with a coordinate system and an imported (neutral) feature.
The problems start when that import feature is regenerated. Reordering, suppressing/resuming, etc.... anything that causes the feature to regenerate will instantly crash Pro/E.
I didn't know these parts came from SolidWorks (and wouldn't have thought anything of it). I opened a call with PTC and got the scoop on thelegal way to open SolidWorks files in Pro/E, as noted in this thread that Darrin started a while back. I'll remember that for the future, but it doesn't help with these old files.
This is the part that chaps my hide: I was told by PTC tech support that Pro/E crashing is (more or less) intended functionality. "That's just the way it works", he said. Unbelievable. In all my years working with Pro/E, I don't think I've ever been told that an outright crash, especially a reproducible one,is not a bug.
So, be careful with those files. I found that I can clean up the files by opening them, exporting an IGES or STEP, then deleting the import feature and importing the exported file. At least that doesn't crash Pro/E and it behaves itself afterward.
Dan
In Reply to Darrin Hiebert:
After posting this, I received an email from corporate PTC about this issue . The email was very forthright about how this situation came to be, and also that they had this same thing occur in a prior revision of WF 4 M160. The issue was subsequently fixed in WF 4 M180. (We bypassed WF4, so I never knew this happened). I conveyed some of my frustrations with the current situation to the PTC contact, and the contact responded to me letting me know that they have indeed added an additional check to their QC process that will now check for this occurrence in subsequent releases of Creo. Also, the contact informed me that this has been again corrected in M080 of Creo, for anyone moving forward.
I would personally like to thank PTC for taking the time to help me with this situation, and to add some steps into their QC process that will hopefully eliminate this in the future. While nothing is a 100%, just the fact that they are willing to change the process speaks volumes, to me, about their willingness to try and make things as right as possible. I know that sometimes we all feel like little fish in a big pond, and that corporate is not paying attention to us little fish. I've gained a new appreciation for their listening ear.
Another thing that the contact told me, and others from the exploder suggested as a solution as well, is to call up the offending file in a PRIOR release of the version of WF/Creo that you're on, and then save the file. This will then create a compatible file that you can use in the newer release.
But, as many users also told me, the best policy is to probably avoid this situation if at all possible, and for us as a company moving forward, that will definitely be our policy. In this particular case, however, it was geometry that we received from a vendor, and we never questioned where the data came from, it just came to us as Pro/E files and we used them. I guess the moral of this story is mostly, " caveat emptor "...
