Skip to main content
P
Pagzma6-Contributor
6-Contributor
January 27, 2022
Question

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

  • January 27, 2022
  • 2 replies
  • 4821 views

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?

2 replies

P
19-Tanzanite
pausob19-Tanzanite
19-Tanzanite
January 28, 2022

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

 

P
Pagzma6-ContributorAuthor
6-Contributor
January 28, 2022

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.

P
19-Tanzanite
pausob19-Tanzanite
19-Tanzanite
January 28, 2022

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

P
19-Tanzanite
pausob19-Tanzanite
19-Tanzanite
January 29, 2022

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:

pausob_0-1643489542086.png

(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

P
Pagzma6-ContributorAuthor
6-Contributor
January 30, 2022

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.

    P
    Pagzma6-ContributorAuthor
    6-Contributor
    February 3, 2022

    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.

    Terms & ConditionsAccessibility statement