Unsolvable constraints on contextual parts

[solid7]

I am having a problem with constraints attached between a contextual and non-contextual part. Basically, I know what the problem is, in layman's terms. However, I don't know whether it should be considered a bug, and I cannot seem to fix it in a way that makes good design sense.

What is happening: a constraint (contact, offset, etc) is placed between the contextual and non-contextual parts. If this is the only constraint, update functions perfectly. However, to constrain all degrees of freedom, this is not sufficient. The next constraint that is attached will not update. The explanation is relatively straightforward: the contextual part has no constraints, (obviously) so the addition of constraints on a subsequent part, which rely on the location of the contextual part, are causing a confusion as to where the constraint update occurs. Proof: Adding a fix constraint to the contextual part causes all constraint updates to function as normal. However, the addition of a fix constraint causes other problems.

What is the answer to this riddle? Is this a bug? Or is this designed-in logic?

Thank you.

-----------------------------------------------------------
Catia Design|Catia Design News|Catia V5 blog

 

[edanmech]

I have tried to reproduce your problem (as I understood it to be)in SP4.
New product with 3 parts:
1 Single (no links)
1 Parent (no links)
1 Child (contextual link to P)

Constraints behaviour :
S-P
normal updates, P drives C as expected

S-C
normal updates, apart for the constraint that interferes with the link - this will not update ( as C cannot drive P as expected)- and the link takes precedence

C-P
normal updates, again apart from the one that interferes with the link, as above


So I think it's a bug...

 

[jackk]

I thought all contextual parts should be fixed, to maintain the same position as the parent and skeleton parts.

(or use an axis-axis coincidence constraint on contextual parts)

why does the fix constraint cause other problems?