Is there an automated way to toggle between constraint sets without using Family Tables?

[kkrahmer]

Hello,

I have an assembly with a number of flip platforms. I have created them with pin connections and am using mechanism analyses to drive the assy into different configurations using servo motors on the pins. This works well as long as I am careful with the constraints so I don't lock up one or more of the connections.

These flip platforms also have guard rails and ladders that need to be installed or stored depending on the configuration. My current method is:

1. Run the mechanism analysis for the desired configuration.
2. Edit definition on all of the different guard rails and ladders and enable and disable the appropriate constraints.
3. Update the snapshot of the individual configuration.

My model has grown more complex and step 2 is becoming quite tedious. I loathe family table assemblies and they are forbidden here as well, so I will not/ cannot use them. Is there something I can use in Mechanism, to switch between them?  I have tried using Rigid connections and was then hoping I could use the enable/disable connections constraint in Snapshot. But the Rigid Constraints were not selectable when I tried that.

I would love it if there were something I could set up in my mechanism analysis that would work.

Thanks in advance,

Karl Krahmer

[TomU · Accepted solution]

Constraint sets can be controlled via simple relations.  I would suggest using a top level assembly parameter to determine which constraint set is currently active across each of the components.  Take a look at this article: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS46389  Let me know if you need help implementing it.

[kkrahmer]

Hi Tom,

   Thanks for the help.  This is very helpful. Just showing the constraint sets in the model tree is very helpful.  I am trying to write relations to drive the different states but I am having trouble with the syntax. I created a Yes/No parameter for my first constraint set and then added the constraint set from the list as shown in the link you provided. But it is telling me the relation has an error. I have tried with and without the quotes around the name of the constraint (which is "STORED").

/*SET CONSTRAINT SETS BASED ON PARAMETER VALUES

IF FSPAP_FLIP_EXTENDED== YES

PTC_CONSTRAINT_SET:FID_23684 = "STORED"

error Relation has an error.

Can you help me again?

[TomU]

Quick guess without testing... try changing to PTC_CONSTRAINT_SET:CID_23684 = "STORED"  Constraints are part of the component (CID), not a feature (FID).

Let me know if that doesn't work and I'll do a quick test.

By the way, it might be simpler to place the relations in each component and simply reference the top level assembly YES/NO parameter.  That way the relations will be nearly identical for each component.

[kkrahmer]

Unfortunately that didn't work. I tried it with and without quotes. Also the PTC document shows that they use FID.

Unfortunately they don't show the syntax of the rest of the relation.

[kkrahmer]

I am kind of stumped.

If I write a simple relation to set the name of the constraint set, it works:

/*SET CONSTRAINT SET BASED ON k0000060260 PARAMETER

/*IF FSPAP_FLIP_EXTENDED == YES

/*PTC_CONSTRAINT_SET= "STORED"

/*ELSE

PTC_CONSTRAINT_SET= "INSTALLED"

but if I make it part of the IF set, I get an error:

[TomU]

Are you sure you have the second constraint name spelled correctly?

I'm not getting any errors with this:

See attached assembly (Creo 3).  The relations are in the component relations section for the second model.

[psobejko]

Hi Karl,

Your code fragment looks correct.  PTC_CONSTRAINT_SET:FID_2364 is meant to hold a string, so assigning it a value of a string type parameter should work.

I tested this code on Creo Parametric 2, M210 and it worked just fine:

/*SET CONSTRAINT SETS BASED ON PARAMETER VALUES

IF FSPAP_FLIP_EXTENDED== YES

PTC_CONSTRAINT_SET:FID_23684 = "EXTENDED"

ELSE

PTC_CONSTRAINT_SET:FID_23684 = "STORED"

ENDIF

FSPAP_FLIP_EXTENDED is a YES/NO parameter.

"STORED" and "EXTENDED" are the names of two constraint sets defined in the component FID_23684.

BTW, the case doesn't matter - you can assign "ExTeNdEd" and it will still pick the correct constraint.

So just two ideas:

1) you sure you're not mixing types; from your explanation it sounds like "STORED" is a YES/NO parameter?

(I was confused about the constraint sets because in the GUI, you can "activate" and "deactivate" each constraint set independently).

2) you do have the ENDIF in your code (your example doesn't show it)?

[kkrahmer]

MISSING THE "ENDIF"...

no, STORED is just the name of the constraint set, so it is a string parameter.

Thanks Paul

[TomU]

you do have the ENDIF in your code (your example doesn't show it)?

I was just going to ask the same thing... 

[sroodhooft]

You can also steer parameters without relations or family tables.

Add the column "PTC_CONSTRAINT_SET" in a simplified rep and bob's your uncle 🙂.

The column can be added in the same way as you would add a column to the model tree.

[kkrahmer]

Thank you Tom and Paul!

I have been able to combine to motor driven mechanism analyses and constraint sets to get exactly what I need.

I created the top level assembly parameters as yes/no type that say what the overall state is.

I created component level IF relations to drive the appropriate constraint set based on the top level assy parameters.

Now I just set my top level assy parameter to the correct state and regenerate to move the components to their correct location.

Then I go into Mechanism and run the appropriate analysis. Then I open the Snapshots dialog box (drag components) and update the Snapshot for that state.

The total time is now down to 1-2 minutes from ~5-10 mins.

I might also be able to get rid of the mechanism portion altogether and not have to deal with the touchiness of Mechanism.

[kkrahmer]

Ok, So I thought I would try to apply this technique throughout my assy and replace the finicky Motor Driven Analyses.

I can't seem to get sub assy level constraint sets to switch at the parent assy level. For instance, I have a hinge assy that I have 2 constraint sets defined with relations to drive them. I have made it flexible. But since the constraint set I am using in this assy is a bolted connection, that doesn't help.

I tried defining a subassy level parameter and use that to drive the constraint set. It works at the standalone level.

I made the subassy flexible and added the parameter to the flexible items. I  then added a relation to the parent assy to drive the subassy parameter (not optimum as if there were numerous instances of this assy, I may want them opened or closed independently).

The relation is:

IF FSPAP_FLIP_EXTENDED == YES

EXTENDED:FID_24412= "YES"

ELSE

EXTENDED:FID_24412= "NO"

ENDIF

And the parameter updates:

But the position of the hinge does not.

Can anyone help with why this is behaving this way?

[psobejko]

I'm not sure, but I found that when I wanted to write assembly or component level relations involving flexible components that go more than 1 level deep, then I had to use "associated parameters", which are parameters that are bound to the flexible component instance and available for controlling at the parent-assembly level.

Please read up on this, this is how they are defined (their access is hidden by default and a column needs to be added to the varied item table):

So keeping the figure above in mind, suppose this MCMASTER_91290A318.PRT is being assembled and made flexible and ends up with FID of 24412.

Now suppose I want to change the value of the HARDNESS parameter for this component with an assembly level relation:  The code you listed is analogous to doing this:

HARDNESS:FID_24412 = "Rc60"

This would seem to be the logical way, and it would be accepted without immediate errors - but usually warnings about flexible var dims being re-set would start showing up in your message logs and you'd in general get weird results.

The correct way is to control the value of the HARDNESS parameter for this component by changing the value of the associated parameter "COMP1_HARDNESS":

COMP1_HARDNESS:FID_24412 = "Rc60"

That's the way I taught myself; I don't know why it works like that, but try and see if it works for you.

[kkrahmer]

Hi Paul,

Thanks again for the help. You were correct. The way I got it to work in my situation is add the "Associated Parameter" to the definition of the Hinge Assy. I had to create unique parameter names for each instance of the Hinge Assy. I used LEFT_FLIP_EXTENDED & LEFT_FLIP_EXTENDED_2 for the 2 hinges.

Then I added the following relations to the top level assy relations:

IF FSPAP_FLIP_EXTENDED == YES

LEFT_FLIP_EXTENDED:FID_24412= "YES"

ELSE

LEFT_FLIP_EXTENDED:FID_24412= "NO"

ENDIF

IF FSPAP_FLIP_EXTENDED == YES

LEFT_FLIP_EXTENDED_2:FID_24413= "YES"

ELSE

LEFT_FLIP_EXTENDED_2:FID_24413= "NO"

ENDIF

So that worked, but I am very hesitant to utilize this technique. It will require too many relations at too many levels. And having to add a hidden column that has very little documentation as to how it works means that very few other users would be able too maintain this model.

[psobejko]

Yes, no arguments from me about misgivings of this technique and that hidden column is also just baffling.

Just two more cents:

  - you don't have to have a unique parameter name for every flexible instance; in your case, the associated parameter could have been called "LEFT_FLIP_EXTENDED" in every instance, and relations would read: LEFT_FLIP_EXTENDED:FID_24413 = ....

  -  in general, using relations in your models means that other users are not able to maintain it effectively unless you document it with comments / annotations, etc...