Cannot check in parts/assys from a vendor? (Duplicate names)

[DavidFrancis]

Hello,

I hope someone can help, but I am afraid I already know the answer.....

We receive assemblies from an off shore vendor and we really only need to modify and release one component.

After making modifications, we try and check this component in, and of course it has assembly references.

1. When we try and check in the whole assembly, it errors because many of the electrical components are already in the library with the same name. I should also mention there is a drawing associated to the part, and I believe this has assembly views, therefore, causing more refernces back to the assembly.

2. So we try and do an update to the workspace, alerting/synchronizing between local and the DB. This goes through the motions and acts as if it were successful, but we still get the same errors and the components still have "+" signs on them.

At this point my only solution was to write out an STL file and then create a new part and read it back in as a single feature. (BTW - I tried to export a STEP file and read it back in, andWF4 failed to properly read in its own exported file)

I still have to reassemble the imported part to the assembly and therefore, recreating assembly references, bringing me full circle to the same issue.

Any insights would be greatly appreciated!

Thank you in advance,

David T. Francis

[bruce.chastain]

You're saying that when you attempt to check in all the objects it's telling you there is a file name conflict even though there is none listed as such in the workspace? I would say make 100% sure that the comparestatus (i think it's called) column lists no file name conflicts.

[sscole1]

David,

You don't mention what release/build of Windchill you are using and whether you are trying to check directly into PDMLink or using ProjectLink with your vendor...

This particular use case scenario is address quite eloquently in PDMLink/ProjectLink Release 10 by adding the ability to override Project-based data with PDM-based data (from Product or Library). There is also an option to rename on the fly during the Send to PDM operation. Please see the attached presentation. In releases prior to R10, the Send to PDM operation will indicate conflicts and you would need to perform the renames (as appropriate) in the Project space prior to completing the operation. If it is desired to leverage existing PDM components, then it you would need to identify those components and share/checkout to the project in a separate operation.

Hope this helps...

Steve

[DavidFrancis]

Thanks for the PPT. Very i nformative.

We are on Intralink 9.1 M050

WF4.0 M160

In Reply to Steve Cole:

David,

You don't mention what release/build of Windchill you are using and whether you are trying to check directly into PDMLink or using ProjectLink with your vendor...

This particular use case scenario is address quite eloquently in PDMLink/ProjectLink Release 10 by adding the ability to override Project-based data with PDM-based data (from Product or Library). There is also an option to rename on the fly during the Send to PDM operation. Please see the attached presentation. In releases prior to R10, the Send to PDM operation will indicate conflicts and you would need to perform the renames (as appropriate) in the Project space prior to completing the operation. If it is desired to leverage existing PDM components, then it you would need to identify those components and share/checkout to the project in a separate operation.

Hope this helps...

Steve

David T. Francis

[GaryMansell]

Steve,

We have a very similar issue to David, and the ProjectLink rename solution has been suggested to us before by PTC, but it just does not work in most situations. This is because a lot of models have assembly/feature references between models and when you rename using ProjectLink in order to save into PDMLink these references all break down.

There is another reason that this rename in ProjectLink before loading into PDMLink does not work for us, and that is because we usually have to return the customer's data to them with the same names as they sent them to us, so renaming (sometimes) most of the components, only to have to rename them all before sending them back and suffering from all the feature reference breakdowns yet again is an absolute nightmare.

We are a global automotive engineering consultancy and so have a lot of the large OEM's as customers for which we do design work. They will send us a load of initial CAD data that we need to import into our PDMLink System, work on and then return the final models to them correctly named. Now a lot of these packages of CAD data from a single OEM will have the same filenames in them as previous packages of data that they might have sent us for other projects as they all re-use data where ever possible. This then becomes a huge headache for us - to the point where we may have to abandon Windchill altogether !!

Now the strange thing is that it is not even clear to me that EPMdoc filenames really need to be unique in a Windchill installation. There is no need for WTdocs to have unique filenames and the Oracle database schema's Uniqueness Indexes do not prevent this - it seems to be the Pro/E and the Universal Workgroup managers that do the filename Uniqueness lookup, so I don't understand why it it is enforced.

This is something that I have raised at every level possible within PTC but have still got nowhere... Do you have any other suggestions as to how we can make Windchill work for us in this scenario?

Best Regards

Gary Mansell

In Reply to Steve Cole:

David,

You don't mention what release/build of Windchill you are using and whether you are trying to check directly into PDMLink or using ProjectLink with your vendor...

This particular use case scenario is address quite eloquently in PDMLink/ProjectLink Release 10 by adding the ability to override Project-based data with PDM-based data (from Product or Library). There is also an option to rename on the fly during the Send to PDM operation. Please see the attached presentation. In releases prior to R10, the Send to PDM operation will indicate conflicts and you would need to perform the renames (as appropriate) in the Project space prior to completing the operation. If it is desired to leverage existing PDM components, then it you would need to identify those components and share/checkout to the project in a separate operation.

Hope this helps...

Steve

[sscole1]

Gary,

While I obviously can't provide best practices without understanding your use case(s) inmuch more detail, I can speak anecdotally to other customers who leverage ProjectLink extensively in GPD with partners/ODMs with great success. The enhancements in R10 were customer-driven to address some of the specific concerns you mention around taking the silo'd project information back into the formally managed PDM environment. In some cases, this makes sense but in some cases it makes more sense to continue to manage the information in a lifecycle-based project (particularly when the information is partner-generated). In the latter instance, you don't need to worry about "redundant" information (filenames)while managing/maintaining the IP since uniqueness isn't required across project contexts. Again, depends on the specific use case and how much leverage/control you have over the partner/ODM data during the collaboration process...

Regards,

Steve

[DarrenStorey]

- My understanding is we work only in ProjectLink, only in PDMLink or share between.

- Working only in PDM is causing us massive problems due to duplicated filenames

- Yes we can bring data into ProjectLink and not worry about the filename, but if we work only in ProjectLink then we have no engineering change or promotion.

- If we try to merge project and PDM data by sharing between, then filename uniqueness problems come back.

- Bulk rename of CAD is not an option for several reasons namely :

1) We often don’t own the data so would have to rename back.

2) Handling partial updates of data from the client becomes unmanageable.

3) Rename of CAD in Windchill does not support feature level file references, it either completely fails (UG) or requires the links to be manually repaired in CAD.

I think I understand the benefits that ProjectLink can bring, but in our case this does not seem to be an appropriate solution or even workaround. I would love to be conviced otherwise though, as we currently do not have a workable solution to this problem.

Regards

Darren

[bruce.chastain]

What about a VM with windchill instance installed onto it. Then you could just make and use a copy of the VM for each time this sort of thing comes up.