best method for getting existing data into pdmlink

[jblittle4]

What is the best method to put an existing assembly outside of PDMLink into PDMlink when half the hardware is already in PDMlink?

PDMLink 9.1

Wildfire 4.0

Thanks in advance!!

[avillanueva]

There is a TPI or TAN on this but I forget the number. Here is out write
up on it.


Steps

Top
<
This is a temporary search path so it does not need to be saved to your
local config.pro file.

7. Open and browse to folder in step 2 and open the top level
parent files. When Wildfire retrieves the dependents, any file that is
in that folder will be loaded. Next it will pull from PDMLink. Any other
fil...

[SteveVinyard]

This is an easy one. Open WF4, connect to PDMLink server and open a workspace. Click tools (from Workspace menu) and select Import. The import manager is far more robust and efficient at bringing in Proe data than a simple open and save.

It will tell you if name conflicts exist and allow you to check off all pre-existing library parts and set them to "reuse". If you need more help from there just click the ? Mark help in the import wizard

[akelly]

Using Pro/Intralink 9.1

Antonio's method is way too complicated. We use a variation of Steve's method. Steve's method makes you sort everything during the import, where our method lets you sort things out in several smaller steps after the import. (Of course, a combination of Steve's method and our method works, too.)

We either use the workspace import functionality and just click through all the defaults, or open the assembly in Pro/E and save it to the workspace. You end up with all new files in the workspace. Ones that already exist in Commonspace are marked with name conflicts. The next steps involve manipulating the metadata to resolve the naming conflicts and exchanging content in the right directions. There are 3 "classes" of files and solutions for dealing with them.

First - content that should use the unmodified commonspace copy. You have to update the related metadata in your workspace for the CAD Document. You also have to download the commonspace content to your workspace to overwrite the content that you just imported.

Second - content that exists in commonspace, but the copy in your workspace is more recent and needs to be checked in. Resolving the metadata in the workspace is the same as the first case. Instead of downloading the content from commonspace, you have to tell Windchill to re-use the content in your workspace. Then you will be left with a CAD Document marked as modified in the workspace, but the naming conflict will be resolved.

Third - content that does not currently exist in Commonspace. Proceed to check-in.

To get the metadata updated in the workspace (i.e. to resolve the name/number conflicts), sometimes requires that you select the CAD Documents and perform Add to Workspace. Other times it requires a workspace update. I think family table objects require using Update and stand-alone objects require Add to Workspace (?). If you want to overwrite your content with the commonspace version, set the CAD Document's action to download; if you want to keep your content for possible future check-in, set the CAD Document's action to re-use. You can set this on a per-file basis.

After this step, you should be left with some CAD Documents marked as modified and (possibly) some CAD Documents marked as new, but you should not have any more conflicts. Check-out the CAD Documents that are modified, then check-in the modified and new CAD Documents.

[avillanueva]

Granted, my procedure was before import to workspace was available. I
should revisit it. I often find that user's who are needing this
technique have been working "really" offline and do not keep track of
what they changed. They try to shove the whole mess in and do not
understand the conflict messages. Worse is that some end up renaming
and copying conflict parts to work around the conflict. Thanks for
sharing.

[SteveVinyard]

The only thing about not using the Import tool is that it doesn't automatically mark things that have a name conflict. For that to happen without the import tool you need to turn on the compare status column. Either will as long as you are comfortable with it.

One of the most important pieces is to start small. Do sub-assemblies and libraries first. This will help minimize issues and you won't be overwhelmed by 200errors. But always try the big assembly first, you never know if it just works.

Most import challenges stem from bring in family tables of the same name but where each have a different number of components.

Also remember the import allows you to grab as many single piece parts as you want and import them all at once. If you did it just with Proe you'd have to open each one individually unless you had some assembly with all of them on there.

[jlittle]

To alleviate all of the problems associated with objects that already
exist in Windchill, we have a Java program that is executed in a
directory containing a Pro/ENGINEER backup of the top level
assembly/drawing to be imported. The program gets a list of all CAD
files in the directory and then connects to Windchill to see if they
already exist. Once that has been determined, it copies only the files
that are not in Windchill to a directory named import. The user can
then launch Pro/E connected to Windchill and set the local working
directory to the newly created import directory, open files and save to
workspace. Any required file not in the import directory is retrieved
from Windchill, thus eliminating the all of the naming conflicts and
workspace downloads.

It works really fast and allows even a novice user (with regards to
Workspace management issues) get files into Windchill through Pro/E.
This was developed prior to the Import/Export command available in 9.0.

Regards,


James Little
Corning Cable Systems
CAD Administrator
Jeremiah 33:3 "Call to Me, and I will answer you, and show you great and
mighty things, which you do not know."

[mnelson-2]

Greetings...
Would you be willing to make this available to others? It sounds like a great tool...

Thanks in advance,
Mark