Assembly-to-subassembly constraints behaving inconsistently when several sub-assemblies deep

[Pagzma]

Edit:   We managed to reduce our problem to the simplest case and have attached an example of it below.  I removed the original less-informed message and replaced it with a better-informed explanation, which is why the first reply now sounds completely unrelated.

I'm mentoring a FIRST Robotics team, and we think we've found a bug, but we're not 100% certain.  We spent a lot of time designing a robot (which works great), but when we try to place our robot as a sub-assembly inside another assembly which contains the playing field, the robot stops working properly when we use the grab tool. (Sometimes the parts come off the robot, sometimes mechanisms freeze.)

We reduced the problem to a simple two-body test case, attached below.

Here's how to recreate the issue:

1. First, place a part called BLUE in an assembly with a default constraint.
2. Create a second assembly, and place the first assembly in it via a csys-to-csys constraint.
3. Create a third assembly, and place a second part in it called BROWN with a default constraint. Add the second assembly via a part-to-part constraint.
4. Create a fourth assembly. Place the third assembly in it with a default constraint.

CAN_PULL_BLUE_FROM_BROWN_HERE

  \ default

     CANNOT_PULL_BLUE_FROM_BROWN

           | default

           BROWN

               \ blue-to-brown

                   CONSTRAINED_BY_BLUE_TO_BROWN

                       \ csys-to-csys

                           CONSTRAINED_TO_PARENT_VIA_CSYS

                           | default

                           BLUE

Start by opening the CAN_PULL_BLUE_FROM_BROWN_HERE assembly.  If you grab the blue block, you can pull it away from the brown block.  You shouldn't be able to.  Press regenerate, and the block jumps back.

Notice that the only thing inside CAN_PULL_BLUE_FROM_BROWN_HERE is the subassembly CANNOT_PULL_BLUE_FROM_BROWN which is simply attached with a default constraint.  If you now open that subassembly in a separate window, notice you now CANNOT pull the blue block away from the brown block --- exactly as expected!

Now go back to CAN_PULL_BLUE_FROM_BROWN_HERE (because it's the only way you can see the problem.) Inside CANNOT_PULL_BLUE_FROM_BROWN is a brown cube representing the ground body.  Attached to the ground body is an assembly called CONSTRAINED_BY_BLUE_TO_BROWN, which is constrained via a blue-to-brown connection.

Inside CONSTRAINED_BY_BLUE_TO_BROWN is CONSTRAINED_TO_PARENT_VIA_CSYS, which is constrained csys-to-csys.  It also contains the blue block.

If you move the blue block from CONSTRAINED_TO_PARENT_VIA_CSYS to CONSTRAINED_BY_BLUE_TO_BROWN, everything works properly.  If you change the constraint of CONSTRAINED_TO_PARENT_VIA_CSYS to default, everything works properly.  If you don't have this system embedded in so many layers, everything works properly.

Is this a bug, or did we do something we weren't supposed to do?

[pausob]

As there is no CAD model to review, I've only a bunch of conjectures to offer.  Please provide the model or at least screenshots - verbal explanations can only go so far (for example, it's not clear why you have two 3rd bodies in your "mechanism assembly")

In my opinion, when talking about mechanisms in Creo, typically, things will work if you follow the rules.  Trouble is, these rules are not always obvious and documented.  Then things don't work and you don't know where to start, and the system is utterly terrible at giving you guidance.  Just consider that the accepted troubleshooting is to suppress components and go up the tree until the motion becomes unlocked!

Over the years, I've adopted a practice where if things are moving, then I start with the connection type of constraint.  I use the user-defined constraints, but always define the placement fully (no "implied joints" or assumed constraints, etc...) - and of course, you have to be careful about keeping the references consistent and between the connected bodies.

Anyway, to me, it sounds like you are mixing regular constraints with the mechanism joint connection types so that could be an issue.  Fix your component using "Rigid connection" which allows you to use "standard" types of constraints (e.g. 3x distance) to locate and orient it.

I recall that had issues in the past when using the user-defined "default" constraint.  Can't reproduce the issue nowadays, though.

However, I just tried to convert a "Default" constraint to a "Rigid", then was surprised to see that component is now free to move when dragging!  The connection becomes type rigid, specified by the "Default" csys-csys alignment.  (but if I begin with "Rigid", the system does not allow me to use "default" as the specification, so i manually specify a csys-csys coincident constraint - and then it works just fine...)

So... that's not right.  But nothing is perfect, and I'd not be surprised if your issue is caused by software bug.

- Another is to look at some config.pro settings related to component placement and see if they have an effect, eg:

enable_implied_joints

modify_offset_during_comp_drag

comp_placement_assumptions

[Pagzma]

Thanks.  I've narrowed down the problem to something far more specific and posted an example as you suggest.  I edited the original post to save other people time who might read the post.

[pausob]

Intriguing.  Alas, I can't open your file to learn more - Creo 4 here, and your model is I think from a newer version...

[pausob]

You should ask PTC support for this and send them your models.

I cannot open your files but I tried to reproduce your issue by following your procedure and found no problems here:

(blue body moves, brown stays still when dragging is activated from top level assembly)

can_pull_blue_from_brown_here.asm in Creo4 format is attached for your review

[Pagzma]

We finally realize that this is a circular reference that Creo is not detecting.

Brown sets blue's position, which determines the CSYS of BLUE-TO-BROWN and CONSTRAINED_TO_PARENT_VIA_CSYS, and in which BLUE is sitting at the default location.  Even though BROWN is sitting at the CSYS (and thus the loop does is not self-contradictory), Creo appears to be unhappy.  The key was in realizing that if Blue wasn't at CSYS, the constraints no longer make sense.  If we just break the loop somewhere, everything starts working again.

So, it's a bug, but only a bug in the sense that Creo didn't warn us that we screwed up.

Thanks.

[Pagzma]

No, it's not a circular reference after all.  It still looks like a bug to us.  I hope support is able to chime in.

We made the mistake of thinking the blue-to-brown constraint would set the CSYS of BLUE, but then realized that's not true: the constraint sets the CYS of CONSTRAINED_BY_BLUE_TO_BROWN instead.  

The CSYS dependencies are supposed to go like this:

• GROUND sets the position of CANNOT_PULL_BLUE_FROM_BROWN
• CANNOT_PULL_BLUE_FROM_BROWN sets  the position of CAN_PULL_BLUE_FROM_BROWN_HERE
• CAN_PULL_BLUE_FROM_BROWN_HERE sets the position of BROWN
• BROWN sets the position of CONSTRAINED_BY_BLUE_TO_BROWN which is determined by
  • figuring out where BLUE would need to be based on the constraint
    
  • which determines where CONSTRAINED_TO_PARENT_VIA_CSYS needs to be
  • which determines where CONSTRAINED_BY_BLUE_TO_BROWN  needs to be
• CONSTRAINED_BY_BLUE_TO_BROWN determines the position of CONSTRAINED_TO_PARENT_VIA_CSYS (which could be cached since we already figured it out)
• CONSTRAINED_TO_PARENT_VIA_CSYS determines the position of BLUE (which could be cached since we already figured it out)

So it does still appear to us that this is a bug.  It's been confusing for us to figure out what's supposed to happen, but we're growing more confident.  If our understanding of what is supposed to happen is correct, it points to Creo failing to back-calculate CONSTRAINED_BY_BLUE_TO_BROWN  under some circumstances: it never sets the position of CONSTRAINED_BY_BLUE_TO_BROWN, and that explains why everything after that point can be pulled away.

The reason we thought there was a circular constraint was that we erroneously thought this was what was happening:

• GROUND sets the position of CANNOT_PULL_BLUE_FROM_BROWN
• CANNOT_PULL_BLUE_FROM_BROWN sets  the position of CAN_PULL_BLUE_FROM_BROWN_HERE
• CAN_PULL_BLUE_FROM_BROWN_HERE sets the position of BROWN
• BROWN sets the position of BLUE while CONSTRAINED_BY_BLUE_TO_BROWN sits on top of Brown (wrong)
• CONSTRAINED_BY_BLUE_TO_BROWN sets the position of  CONSTRAINED_TO_PARENT_VIA_CSYS
• CONSTRAINED_TO_PARENT_VIA_CSYS determines the position of BLUE which was already set by BROWN (wrong)

But this makes no sense: the constraints always set the CSYS of the part/assembly being constrained, never the CSYS of the part they are being constrained to, even if that means having to back calculate though many connections.  If that weren't the case, every single constraint based on a part in an assembly that wasn't at that assembly's default CSYS would fail.

[pausob]

Thanks for the information, but frankly, it is overwhelming and I feel it would take someone not familiar with your problem a couple of hours just to parse it. 

Hopefully that someone will chime in, but anyway let us know what PTC support told you.  I am curious whether you tried to open the file I provided in an earlier reply - and comment on whether it worked as expected?  Maybe you can gain insight by looking at how it is different from what you have in your problematic assembly?  Or gain a clue that it is some setting in your config.pro because it worked on my system...

[Pagzma]

Support hasn't chimed in, and they might not since I am only on an educational license.

Your file works properly.  (You pinned yours while I fully constrained mine, but if I fully constrain yours, it still works properly.)

Interestingly, the two files are very different in an unexpected way.  In your file, I can't choose a constraint for the first object in any assembly, but in my file I can. 

CAN_PULL_BLUE_FROM_BROWN_HERE shows no edit option when I right click it in your file --- but it does in mine.  Same for CANNOT_PULL_BLUE_FROM_BROWN and BROWN.PRT.

I can edit the constraint for CONSTRAINED_BY_BLUE_TO_BROWN and CONSTRAINED_TO_PARENT_VIA_CSYS, but not BLUE.

Your version seems to insist that the first object in any assembly/part must sit at that assembly/part's CSYS.  In my version, I can edit all of them and set them any way I want, and the first part does not have to sit at the assembly/part's CSYS.

Is the way your file works for me the same as the way it works in your version, or are you able to set the constraint of every assembly/part from your end?

Bizarre.

[pausob]

On my system (creo4), if the assembly is completely empty, then the first part assembled into it will be automatically constrained "by default" and it cannot be edited.

If I first create a coordinate system in the empty assembly (first one has to be the "default" one), then the placement of the first component will need to be specified and can be edited thereafter.  So I don't know how you can have an empty-of-datum features assembly and still edit the placement of the 1st part, if that's what you are saying.  Maybe it is specific to the educational version of Creo?  Or Creo 4+ ?  Don't know.  And I assume your model tree is set to display coordinate systems and other datum features?  Screenshots would be helpful since I won't be able to open your files...

[Hedy]

Hi, Pagzma

Thanks for using PTC Community! This has been reported internally to the PTC Academic team.

Regards,
Hedy