Pro/INTRALINK 3.X users, how many of use "Modify Relationships" in the workspace

[ptc-113113]

Hi,

Do you use "Modify Relationships" in Pro/INTRALINK 3.X today? If so please reply
If you are planning to migrate to Winchill (any product), please be advised that PTC does not support the migration of the relationships you manually created using the "Modify Relationships" functionality in 3.x. (Pro/E relationships are unaffected, excepting in the case where you may have structured a document to a Pro/E file)

One of our scenarios is for MathCAD files. We have .bmp figures that are linked to the MathCAD document. The links were created in Pro/INTRALINK 3.x using "Modify Relationships". We can find the Mathcad Document in the CommonSpace, select it alone, download it to a workspace and Pro/INTRALINK will collect the linked .bmp files and download them as well to the workspace. In the workspace the relationships are maintained through out the engineers design cycle, with complete support for modified version tracking, status notification, and out-of-date tracking. The migrator tool ignores these relationships as there is nothing to map them to. For us, these files are required for regulatory compliance, and the .bmp files are required to be maintained, as a set, with the document itself.

There is no workspace for non-CAD documents, so working with a set of Mathcad documents degenerates into a working with one and only one object at a time.


I would much appreciate your post to this important thread,

Thank-you

Andrew Amsden
CAD\PDM Administrator
Midmark Corporation
937-526-8770

[gchampoux]

Ouch.

What happended to PTC's claim that Intralink 9.1 closed all of the functionality gaps (relative to 3.4)?

[mreece]

They certainly have not closed all the gaps! It is getting closer, but
I suspect they will never completely close the gaps.



By the way, this certainly is not the first time.... we also lost
functionality going from Pro/PDM to Pro/INTRALINK.

[MikeLockwood]

We also heavily used User-Defined Relationships in Intralink 3.x, and these did not come across to PDMLink. But - Associating documents to WTParts and having these relationships then available for navigation through PDMLink's product structure functionality (and/or using PDMlink's document structure functions) is a fundamentally far better and more comprehensive solution.

Be open to considering the "gap closed" by using alternate approaches that serve the same fundamental need in a better way.

It's maybe not on the same order of magnitude but consider this analogy: This is possibly like the difference between how a specific useful functionality related to how lines are drawn in 2D CAD didn't get replaced when using 3D modeling and producing parametric drawings based on models - a fundamentally different approach that takes some getting used to but is far better in the long run - but which causes some pain for those used to drawing lines.

[sdrzewiczewski]

I agree that is a better technique, but for Intralink 9 customers they
don't get that functionality

Sent from my iPhone

On Sep 14, 2009, at 11:29 AM, "Lockwood,Mike,IRVINE,R&D" <mike.lockwood@alconlabs.com <br="/> > wrote:

> We also heavily used User-Defined Relationships in Intralink 3.x,
> and these did not come across to PDMLink. But - Associating
> documents to WTParts and having these relationships then available
> for navigation through PDMLink's product structure functionality
> (and/or using PDMlink's document structure functions) is a
> fundamentally far better and more comprehensive solution.
>
> Be open to considering the "gap closed" by using alternate
> approaches that serve the same fundamental need in a better way.
>
> It's maybe not on the same order of magnitude but consider this

[DanielReid]

We use this functionality at least to some degree though not as critical
as Andrew's case. I certainly appreciate that the WTPart functionality
is probably better but the problem is still how to get from Pro/I to
PDMLink with this information intact or restored.

[ptc-113113]

PMDLink appears to be a more labor intensive method for creating and maintaining ECAD product structure.
Also, all the existing structure is gone(it is NOT migrated), and it either has to be manually recreated or it has to be abandoned.
Our team seems ready to accept WT.part as a compromise, but there are still other issues.

Structure is not the only causality:

· There is no workspace for wtdocuments, so tracking modified copies of the working copy is 100% manual. The simplest way to visualize this problem is to remove the Pro/E Workspace. Only allow users to download Pro/E files to a folder on spinning disk. See the problem?

· If you do not see the problem, you might suggest that the versions are tracked in the CommonSpace on the server. You can track "In Work" iterations and these iterations are shared with the team. I would counter, again, with this: "do the same thing the same way in Pro/E". Always autocheck in EVERY modified object. You should never see a modified status in the workspace, nor should you ever find a valid use for the modified status in the workspace. Keep track of what Pro/E files are or are not modified using a pencil or a spread sheet.

We need the ability to retain the functionality that is was purchased and for which we faithfully paid maintenance for in Pro/INTRALINK. People here are starting to suggest non-PTC solutions, such as AutoDesk Vault. Since it more important for a team to collaborate based on discipline, I would most likely find myself supporting this solution, provided we can divide the work by discipline. What happens just a few short years down the road if AutoDesk Vault finds a foot hold? It is only a matter of time before the pendulum swings again and people ask ,"Why don't we have "one source of truth" for product definition??" We would then look for a MCAD solution that would enable us to collaborate seamlessly between MCAD and ECAD product development ( Inventor?)

Thanks everyone for your informative input to this discussion

Andrew Amsden
CAD\PDM Administrator
Midmark Corporation
937-526-8770


From: Stephen Drzewiczewski [

I agree that is a better technique, but for Intralink 9 customers they don't get that functionality

Sent from my iPhone

On Sep 14, 2009, at 11:29 AM, "Lockwood,Mike,IRVINE,R&D" <mike.lockwood@alconlabs.com<<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:mike...

[NATHANBROWN]

We are in the middle of a migration and have encountered the same issue with PDMLink not recognizing Intralink relationships on non-CADD documents. For decal and packaging drawings we use JPEGs in the appearance editor to place on the surface of a Pro/E part. It is a cumbersome task, but we got it working. In order for it to work, the JPEG and appearance file need to be in the working directory (workspace in this case). The appearance file links the JPEG to the Pro/E part. For the appearance file and JPEG to be checked out into the workspace, an Intralinkuser defined relationship had to be defined linking those files to the Pro/E part. During our test migration the relationship to the JPEG was lost. In fact, since the JPEG is not a CADD document, it can not be checked out into the PDMLink workspace. So when we open our decal and packaging drawings no graphics show up. It sounds like we might be able to get this working moving forward using WT.parts, but that won't help us with our files that we are migrating into PDMLink. We also have linked word or excel files to Pro/E parts and those relationships are lost. Is it possible toset all documents to CADD documents? I know this is not how PDMLink is supposed to function, but we're willing to try it.

[rjessen]

Nathan,

If the JPEGS are all related to Pro/E content you should try migrating them as secondary content instead of as standalone objects. You need to edit the pitdmapping.properties mapping file and change the default mapping for JPEG's from:

JPEG=1/@wt.doc.WTDocument/@JPEG Image

and change it to:

and change it to:

JPEG=2/@IMAGE

I haven't tested this for JPEG's, but in theory they shouldthen get pulled into the workspace along with the Pro/E objects.This is the way ToolPath, Instance Accelerator,and FEA Mesh files are all handled.

I haven't tested this for JPEG's, but in theory they shouldthen get pulled into the workspace along with the Pro/E objects.This is the way ToolPath, Instance Accelerator,and FEA Mesh files are all handled.

NOTE: Instead of being standalone objects they will appear as attachements to the Pro/E objects within PDMLink.

In Reply to Nathan Brown:

We are in the middle of a migration and have encountered the same issue with PDMLink not recognizing Intralink relationships on non-CADD documents. For decal and packaging drawings we use JPEGs in the appearance editor to place on the surface of a Pro/E part. It is a cumbersome task, but we got it working. In order for it to work, the JPEG and appearance file need to be in the working directory (workspace in this case). The appearance file links the JPEG to the Pro/E part. For the appearance file and JPEG to be checked out into the workspace, an Intralinkuser defined relationship had to be defined linking those files to the Pro/E part. During our test migration the relationship to the JPEG was lost. In fact, since the JPEG is not a CADD document, it can not be checked out into the PDMLink workspace. So when we open our decal and packaging drawings no graphics show up. It sounds like we might be able to get this working moving forward using WT.parts, but that won't help us with our files that we are migrating into PDMLink. We also have linked word or excel files to Pro/E parts and those relationships are lost. Is it possible toset all documents to CADD documents? I know this is not how PDMLink is supposed to function, but we're willing to try it.