Error With Certain Imported Geometry

[DH_9761661]

I am using Creo Parametric - Release 8.0 (connected) Release 8.0 and Datecode8.0.3.0

We are given the error message listed below when adding certain imported parts to an assembly. This has effected numerous parts in our database and reimporting them would be timely. Is there any way to override this error in Creo Parametric 8.0 to avoid having to update all of these parts in our database?

Here are the errors that I faced
"This model cannot be assembled due to it not being a valid Creo file exported from another system. PTC recommends using an intermediate file types, such as STEP or IGES, or approved direct translators to create a valid Creo file."

[StephenW]

I think I would open a case with PTC to get clarification on the error. They may be able to help reduce or eliminate the errors. Or they may be able to tell you why there is an error and how not to generate the error in the process.

[Tdaugherty]

I'm not 100% sure about this but it sounds as if there might not be a way around this one... check out this article.

https://www.ptc.com/en/support/article/CS351641 

[BenLoosli]

What software did your models come from?

It sounds like you may be able to open the models in Creo prior to 7 and then save the Creo model and import that into 7 or 8.

[hadardor]

Hello,

Some software packages, allow the export of so-called "Creo Parametric" part files which have not been created using PTC-approved APIs or the Granite Kernel. Upon retrieval in Creo Parametric, they contain only a coordinate system feature and a "Neutral" feature. We has discovered that these files are missing information that affects reliable regeneration, downstream feature creation, and other uses. Working with such a part will yield unexpected behavior and can not be relied upon.

This "Creo Parametric" part file export functionality that some software packages have is not licensed by PTC. Such parts cannot be considered valid part files, and should not be used in a production environment.

PTC Technical Support can identify if a particular model was generated in this fashion.

PTC recommends use of Intermediate file types, such as IGES or STEP, or direct translators using PTC-approved creation methods, should be used to translate data from other software packages to Creo Parametric.

[remy]

When assembling some component Creo throws an error message and prevents to assemble it. Like previous contributors have explained the reason is that the component, although looks native, was not created with Creo itself but rather another software vendor or a 3rd party translator. 

Since 7, those models are prevented to be assembled to prevent hazardous behaviors. Behaviors that our development team has met in the past. 

Now the resolution may look time consuming but it is up to you to evaluate the investment: there is a requirement to translate that data back to native Creo. 

Like in all migration / translation project there are two stances:

1. translate on the fly 
2. bulk translate

 Given the amount of files, the recurrence of the message, the decision and the investment are up to you

[SW_9175744]

Wow - I've come across some show stoppers before but really !!!!

So now anything that we've imported in from another system over the last 25 years containing a 'neutral' feature can no longer be assembled in our recently upgraded version of Creo (8.0.3.0) which we had to upgrade to as our version of Windchill had reached it's end of shelf life.

The resolution that PTC are offering is that we export the file (save as a step file) then import it back into Creo as a new part which isn't that tricky unless you're using Windchill where you've got to 'set state' to allow you to overwrite the part to check it back in, set state, etc.

On top of this the part will lose any reference it had before therefore any assembly which uses it will fail.

I do hope I've picked this up wrong and there's a simple solution to this problem 🤔.

[TomU]

You summarized it correctly.  Previously imported existing data can continue to live on in any assemblies it already exists in but it cannot be added to any other (new) assemblies unless the file is 'fixed' by recreating the model from a fresh import.  Of course doing this will break all references in all of the existing assemblies.  I get not allowing this kind of data to import in the future but preventing the ability to assemble it really causes problems with existing data already released in the system (Windchill).

[SW_9175744]

It's been suggested to me that I could take out new part numbers to resolve this problem which then creates duplicate parts in our ERP system and more work for our purchasing team having to buy newly created parts just cause our CAD system no longer handles these files which I've personally never experienced any issues with in the 25+ years of using the software. Seems a big backwards step by PTC 🙄. Maybe they'll fix it in Creo 10 🤣

[TomU]

This was an intentional change by product management.  I don't think they will be rolling it back...

[SW_9175744]

😪

[remy]

This change is impacting your workflow greatly and your use case is rich in learnings.

Our Product Management made the deliberate decision to protect the integrity of the native Creo data and this costs you significant consequences.

I'm sorry that this makes for a great amount of rework. 

With this said and from my experience as a former PDM migration specialist, there two schools of thought (like previously explained):

1. convert on the fly the right amount of data
2. batch convert the whole data base

Depending on your business and practices one will fit better than the other.  To help you make the decision, feel free to reach out to our consultants or partners.

[SW_9175744]

It still doesn't quite seem right that a simple change like this can cause us so many problems - I've seen many changes over the years but I find this one right up on the top of my list now at questionable improvements but hey, I'm just the CAD user at the end of day. Why would I do a batch convert of the whole data base when it's not the whole data base that's been affected. If it got to that stage I guess I'd be looking at a migration to another system 🙄

Anyway, thanks for your response - I was really curious as to whether what I had encountered yesterday and this morning was a permanent change and it looks like my question has been answered 🙂