Dealing with circular dependencies during Save-As

[gchampoux]

How do you deal with Circular Dependencies which were allowed in Intralink 3.x, but now disallowed in Windchill 9.x?

Now that we have migrated from Intralink 3.4 to Windchill Intralink 9.1, we have discovered that Windchill can be very picky during a Save-As where Circular Dependencies are involved.

To the uninitiated, first understand that a circular dependency is not the same as a circular reference.
Generally, a circular dependency is an external reference, usually through an assembly.
For example, consider assembly A that contains parts B & C, where C has a feature that references part B.
Therefore C is dependent upon B.
C is also dependent upon the assembly A itself, because of B’s & C’s orientation and location within assembly A.
Assembly A is also dependent upon both B & C, simply because they are within A’s structure.
Therefore, A is dependent upon C, and C is dependent upon A. That’s a circular dependency, and it is totally valid.

Personally, I think it is bad modeling practice, and should be avoided, and here is why.

Consider: The user wants to duplicate part C to D.
However, a Windchill Save-As of part C to D also requires a Save-As of Assembly A as well.
If A is not duplicated, Windchill will not allow the Save-As to proceed.

Do you see the problem?
If C were allowed to be duplicated to D without duplicating A, how would that one feature (with the external reference) regenerate?
It can’t, because D is not in A.

Unfortunately, Intralink 3.4 freely allowed duplicating of such parts without the assembly.
Windchill will not, and hence, my dilemma.
I have a bunch of users complaining that “Intralink 3.4 used to allow this. Why won’t Windchill? Why can't we force the Save-As?”
I try to explain that Intralink 3.4 was wrong to allow it in the first place, and that Windchill is now catching these bad modeling practices.

How have you dealt with this?

Gerry

[mlocascio]

I really NEED to hear the REST of this story! In fact someone might want to
archive it.



Mike L.

[JoshuaHouser]

Hi Gerry,

I'm not sure if you're trying to deal with users creating new circular dependancies, how to break old references, or explaining that Windchill is just more stringent in its requirements.

I'll take the easiest to address since nobody has yet 🙂

The Reference Viewer includes a tool to find all circular dependancies as well as to drill down into the references created. While it still REALLY needs to have the ability to go straight to a problemed featured and edit it's definition, at least you can see what features are connected that created the circular reference. You can select the "Reference Info" from there, get a message window pop-up, copy and paste into a text editor, close the Reference Viewer and then edit the problemed features.

Joshua Houser| Pelco by Schneider Electric |Buildings & Business| United States| MCAD Tools Administrator
Phone: +559-292-1981 ext. 3490| Toll Free: +800-289-9100 ext. 3490&nbs

[bfrandsen]

I nearly always use Save a Copy from the ProE, where the below workaround
will loosen up many conflicts, if a good Top Down Modeling practise has
been used.

If the reference in C is in a Copy Geometry, then change it to an External
Copy Geometry before doing the Save-As. This can be done in the workspace
alone. No need to check C back into Commonspace.
This will let you save a copy of C to D, that will still be dependent on
B, but can find its reference without using the assembly A.

As far as I remember, this workaround has no effect on the Save-As in
Windchill.

Bjarne





Gerry Champoux <->
31-10-2011 21:34
Please respond to
Gerry Champoux <->


To
<->
cc

Subject
[solutions] - Dealing with circular dependencies during Save-As






How do you deal with Circular Dependencies which were allowed in Intralink
3.x, but now disallowed in Windchill 9.x?
Now that we have migrated from Intralink 3.4 to Windchill Intralink 9.1,
we have discovered that Windchill can be very picky during a Save-As where
Circular Dependencies are involved.
To the uninitiated, first understand that a circular dependency is not the
same as a circular reference.
Generally, a circular dependency is an external reference, usually through
an assembly.
For example, consider assembly A that contains parts B & C, where C has a
feature that references part B.
Therefore C is dependent upon B.
C is also dependent upon the assembly A itself, because of B’s & C’s
orientation and location within assembly A.
Assembly A is also dependent upon both B & C, simply because they are
within A’s structure.
Therefore, A is dependent upon C, and C is dependent upon A. That’s a
circular dependency, and it is totally valid.

Personally, I think it is bad modeling practice, and should be avoided,
and here is why.
Consider: The user wants to duplicate part C to D.
However, a Windchill Save-As of part C to D also requires a Save-As of
Assembly A as well.
If A is not duplicated, Windchill will not allow the Save-As to proceed.

Do you see the problem?
If C were allowed to be duplicated to D without duplicating A, how would
that one feature (with the external reference) regenerate?
It can’t, because D is not in A.
Unfortunately, Intralink 3.4 freely allowed duplicating of such parts
without the assembly.
Windchill will not, and hence, my dilemma.
I have a bunch of users complaining that “Intralink 3.4 used to allow
this. Why won’t Windchill? Why can't we force the Save-As?”
I try to explain that Intralink 3.4 was wrong to allow it in the first
place, and that Windchill is now catching these bad modeling practices.
How have you dealt with this?
Gerry

Site Links: View post online View mailing list online Send new post
via email Unsubscribe from this mailing list Manage your subscription

Use of this email content is governed by the terms of service at:

[fbaumann]

Hello,

We have got exactly the same problem in my company.

In Intralink, thetre were two switches that allowed to copy objects containing "circular dependancies":

Copy.Circular.All.Type: 6

Copy.Circular.All.Val: False

In Windchill, there is also a switch:

https://fr.ptc.com/appserver/cs/view/solution.jsp?n=145090

We implemented this and it works very well.

Regards,

Fabrice Baumann

CAD/PLM Administration

Liebherr France S.A.S.