cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Your Friends List is a way to easily have access to the community members that you interact with the most! X

PTC_CONSTRAINT_SET Doesn't quite work properly using relations.

MikeJ85
5-Regular Member

PTC_CONSTRAINT_SET Doesn't quite work properly using relations.

Through the power of search, I found this parameter (PTC_CONSTRAINT_SET) to help me insert a single part into an assembly, and place it in different locations using different constraint sets.  During my search, I found this and used it in my assembly relations.

 

if POSITION == 2
  PTC_CONSTRAINT_SET:FID_40 = "Set_no_2"
endif
if POSITION == 1
  PTC_CONSTRAINT_SET:FID_40 = "Set_no_1"
endif

 

It works exactly how I need EXCEPT, the sub-assembly is dynamic, meaning when condition 2 exists, the rest of the sub-assembly changes sizes.  When condition 1 exists, the part is located on the side, when condition 2 exists, it is located on the front.  It positions the parte parallel to all of its constraints upon regenerate, but it does not "snap" to the surface It needs to. Although the sub-assembly is changing dimensionally, the parts are the same, and the constraining surfaces are the same, so no constraints are being broken, they just aren't "snapping" to the surfaces they should.

 

When I hit edit definition, it immediately constrains exactly how it should without me hitting any other buttons.  If I revert back to condition 1, it positions it correctly as if the actual sub-assembly did not change dimensionally from the last size (but since it did change sizes, the part is not located in the correct spot) .  Not until I hit "Edit Definition" does it snap to the correct surfaces. 

 

It knows what it needs to do but it won't do it until I hit "Edit Definition".  I have noticed this happen before randomly while using Creo, but we have not been using the PTC_CONSTRAINT_SET until now.  We normally insert the component multiple times and use programming to turn FID on or off.  This is cumbersome, but as with many options in CREO, they don't seem to ever work 100 percent properly, so we usually have to find an old outdated clunky way to make things happen.  No matter how many regens I do, the part will not snap back into place until "Edit Definition" is clicked.  Frustrated....

19 REPLIES 19

What version of Creo are you using? I filed a ticket on Creo 2.0 probably 3-4 years and I believe it resulted in an SPR. I do not recall if the issue was ever resolved. (I haven't used the functionality since.)

Dave Martin - dmartin@creowindchill.com - https://www.mcaeconsulting.com
MikeJ85
5-Regular Member
(To:DaveMartin)


@DaveMartin wrote:

What version of Creo are you using? I filed a ticket on Creo 2.0 probably 3-4 years and I believe it resulted in an SPR. I do not recall if the issue was ever resolved. (I haven't used the functionality since.)


Using 3.0. It would be great for this functionality to exist, as it seems it would cut our file sizes down quite a bit.  

I tried a test assembly with Creo 2.0 (M240) - I got the same behaviour as you describe - namely, the programmed component would get "unstuck" only if the edit definition function was used on it.  Then I saved this assembly (with the component floating in space because it hasn't snapped to the updated surface), erased all displayed, and then re-opened the assembly.  The component was in the correct place and the odd behaviour stopped - give it a try...

MikeJ85
5-Regular Member
(To:pausob)


@pausob wrote:

I tried a test assembly with Creo 2.0 (M240) - I got the same behaviour as you describe - namely, the programmed component would get "unstuck" only if the edit definition function was used on it.  Then I saved this assembly (with the component floating in space because it hasn't snapped to the updated surface), erased all displayed, and then re-opened the assembly.  The component was in the correct place and the odd behaviour stopped - give it a try...


I am using 3.0.  Thank you for taking the time to replicate this issue.  Makes me feel better to know that this is not isolated. As to the possible solution you have come up with, the problem is that we often work in a single session.  after all of our initial work is done to build our models with the configurability through the layouts, we work off a single session to complete a custom job and then we go on to the next job.  it would be prohibitive to accept this as the only solution.  Thank you again for testing this out.

Well, I did something and the example assembly I concocted last night wouldn't work again this morning.  Same bogus sticking behaviour fixed only by "edit definition".  This all seems to do with how Creo "flags" what needs regenerating.

 

Anyway, I dug a little more into it and was able to get better results if I put in the relations at the component level.

 

In your example, you had assembly level relations:

if POSITION == 2
  PTC_CONSTRAINT_SET:FID_40 = "Set_no_2"
endif 
if POSITION == 1
  PTC_CONSTRAINT_SET:FID_40 = "Set_no_1"
endif

Try changing those to be evaluated at the component level (in your case, you would execute tools->relations->look in "component"->pick the component FID_40->enter in these directly:

 

if POSITION == 2
  PTC_CONSTRAINT_SET = "Set_no_2"
endif 
if POSITION == 1
  PTC_CONSTRAINT_SET = "Set_no_1"
endif

 

MikeJ85
5-Regular Member
(To:pausob)


@pausob wrote:

Well, I did something and the example assembly I concocted last night wouldn't work again this morning.  Same bogus sticking behaviour fixed only by "edit definition".  This all seems to do with how Creo "flags" what needs regenerating.

 

Anyway, I dug a little more into it and was able to get better results if I put in the relations at the component level.

 

In your example, you had assembly level relations:

if POSITION == 2
  PTC_CONSTRAINT_SET:FID_40 = "Set_no_2"
endif 
if POSITION == 1
  PTC_CONSTRAINT_SET:FID_40 = "Set_no_1"
endif

Try changing those to be evaluated at the component level (in your case, you would execute tools->relations->look in "component"->pick the component FID_40->enter in these directly:

 

if POSITION == 2
  PTC_CONSTRAINT_SET = "Set_no_2"
endif 
if POSITION == 1
  PTC_CONSTRAINT_SET = "Set_no_1"
endif

 


Thank you for your continued support on this.  I don't believe this will work for us though, because we use that component in many different assemblies.  Or do I have this incorrect?  In the example you propose, are the relations actually being saved into the part or into the assembly, but at a different level?   I should try this out and at least learn something.  Thank you again.

TomU
23-Emerald IV
(To:MikeJ85)

A component is the unique occurrence of an object in an assembly.  The component is part of the assembly and any relations placed inside a component are stored in that assembly.  Think of a component as a unique object + assembly relations + assembly placement constraints.  If the same model is assembled 4 times there is only one model but there are 4 unique components.

avero
13-Aquamarine
(To:pausob)

I had no luck putting relations at the component level. Manually clicking "edit definition" on every component that is misplaced is still the only solution. It is quite annoying trying to make smarter 3d models with skeleton/relations/program when errors like this show up. One would think this would be highly prioritized for a program called Creo Parametric? Why doesn't Creo seem to flag all components with placement relations for regeneration? Anyone found a solution to this problem?

pausob
18-Opal
(To:avero)

Well, it seems to work for me.  I attach a toy model for demonstration:

multi_position_demo.png

 

Changing the value of the assembly parameter "POSITION" changes the configuration of this assembly.

This includes change of shape of the stationary part (1st block), the displayed labels and notes, and the constraint types of the 2nd block (the one labelled with the prime').

 

The logic is coded in relations at various levels (assembly, component and feature).  Another important bit is use of associated parameters as this assembly involves flexible components.

 

There is still something wonky going on in that switching from configuration "1" to configuration "3" requires a double-regeneration (the 1st regeneration leads to a green-light, but the component is clearly not in the right place) I think that is a bug related to the slider connection having motion limits.

 

Modifying or debugging such a model can be a nightmare.

For example, when I was adding the 3rd configuration, I found I had to temporarily delete all the component relations in the 2nd block.  Otherwise the system didn't really let me add the slider constraint set as it was failing in "finding" a connection - I think it was because the relations were in play and during the definition of the new constraint, they would try to make one of the previously defined constraint sets active (even though I disabled them all during the definition).  I suppose I should have set the value of "POSITION" to 3 during this phase.

As expected, there were no helpful messages as to what was going wrong.

 

In summary, I'm not surprised that relations involving PTC_CONSTRAINT_SET can lead to frustration, because  a lot of things can go wrong while building such a model.  But if the relation logic is sound, the software does work - for the most part.

 

(attached models are made using Creo 2.0 - I'd be interested to hear if the "slider bug" is solved in newer versions)

avero
13-Aquamarine
(To:pausob)

Thank you for looking into this. I am using Creo 4 and switching from configuration 1 to 3 in your model requires a double regeneration for me as well.

 

I have made a slightly more complex dummy assembly consisting of several subassemblies and parts to show how "ptc_constraint_set" seems to not work as intended.


If you open "combustion_air_system.asm" and i.e. change the values of planes in skeleton group configuration like this:

reducer_type from value 1 to 0
silencer from value 1 to 0
heater from value 1 to 0

and then hit regenerate they are clearly misplaced.

 

1.JPG 2.JPG Config.JPG

 

Double regeneration doesn't do anything but edit definition fixes the placement of these components. The placement of each component is defined in relations through "ptc_constraint_set" (component level) and "distance=length1+length2+length3..." (assembly level). Why doesn't regenerate place them correctly but edit definition does?

pausob
18-Opal
(To:avero)

I'll be able to take a look when I get Creo 4.0 installed on my PC (soon).  Until then, I have no input as to why your model doesn't work parametrically...

avero
13-Aquamarine
(To:pausob)

The problem seems to be mainly when I use "ptc_constraint_set" in combination with

 

IF <condition>

distance=L1+L2+L3...

ELSE

IF <condition>

distance=L1+L2+L3...

 

The correct constraint set seems to be enabled, but the distance is wrong. My question is still - why doesn't regenerate place them correctly but edit definition does? Has anyone used this combination successfully before?

avero
13-Aquamarine
(To:avero)

I suspect this may have something to do with how I usually use IF <condition1> to decide which constraint set should be activated at the start of relations and then sometimes use the same IF <condition1> to decide distances later on. I have done this because I want a constraint set to be activated and let a distance change (depending on multiple other conditions) at the same time. Creo might only consider the first time the condition is met and ignore the others below(?) I haven't had time to test this yet, but it would be weird if that would cause regenerate to fail placement and edit definition to get it right. I would want Creo to consider every IF statement upon regeneration even when the same statement is met multiple times (so I can organize relations however I want). There is no color coding or anything so it gets quite complicated sometimes.

cwilkes
7-Bedrock
(To:avero)

Have you tried moving the IF statements to some point after you edit the dimensional values in your relations? It SHOULDN'T make a difference but, you know, this is Creo. 

avero
13-Aquamarine
(To:cwilkes)

Thanks for the suggestion, I have tried to move relations around and even copy paste the entire thing twice to force some kind of double regeneration/calculation, but no luck.

pausob
18-Opal
(To:avero)

So I got Creo 4 and had a chance to take a look at your model.

I'm pretty sure the reason it's not working isn't related to PTC_CONSTRAINT_SET, simply because isolating the investigation to AIR_INLET_UNIT.ASM shows the same weirdness.

Initially, the driving values of the following dimensions are:

REDUCER_TYPE=1
SILENCER=1
HEATER=1

and the model look like this:

Initial modelInitial model

Upon changing the values:

 

REDUCER_TYPE=0
SILENCER=0
HEATER=0

 

and regenerating leads to:

After changing the driving valuesAfter changing the driving values

(note the message in the log that suggests something is wrong with the design...)

Suppressing and resuming the components leads to the correct situation:

Model after suppressing-and-resuming the componentsModel after suppressing-and-resuming the components

 

 

Alas, I can't really spend more time on this as your "simple" example is actually fairly complicated and involves Pro/Program interactions.  I do think that it's all in the relations and pro/program code inside the AIR_INLET_UNIT.ASM (and not involving the COMBUSTION_AIR_SYSTEM_SKELETON, as making the features of that skeleton read-only does not change anything).

 

I'd investigate the relations and code that involve the REDUCER_TYPE and HEATER parameters, because changing the SILENCER parameter seems to work as expected.

 

avero
13-Aquamarine
(To:pausob)

Thank you for your reply, I understand it takes time to really dig into this.

 

I think the SILENCER parameter works better simply because it is controlled by fewer IF statements than the REDUCER_TYPE and HEATER parameters, as it is "first in line". I just did a test however, and the silencer part does fail placement when REDUCER_TYPE and FLAME_ARRESTOR is changed from 0 to 1.

 

If anyone knows why the "design inconsistent for current parameter values" message is shown, I'd be interested to know. It seems to be quite rare, a Google search didn't give many results. I didn't get this message myself for some reason (using Creo 5 now). I would also be interested to know how/why regeneration and edit definition/suppress + resume considers component placement differently.

 

For now I am moving the "insert here" arrow to the top to quickly suppress everything, and then back down to resume. This does fix component placements, but if anyone else has a look at this and figures out why, I would be very interested to know.

 

In the attached model (zip) I have moved all relations to assembly level so it should be easier to understand.  I have also added some component length parameters so the distance/placement relations are much easier to read. In Pro/Program the components are only suppressed/resumed based on whether the connected parameter is 0 or 1. I don't see how that could cause or affect this behaviour.

 

ProProgram.JPG

 

I just did another test and changing the same three parameters that you did (REDUCER_TYPE, SILENCER and HEATER) from 1 to 0 *one at a time* rather than all at once gets the placement right. That isn't always the case however, so problem still not solved. Until someone can tell me what I'm doing wrong, it seems like some kind of bug in Creo to me, why can't it decide ptc_constraint_set and distance at the same time? And why would it behave differently when changing parameters one at a time rather than all at once? Shouldn't the logic below place the heater part correctly based on the values of connected parameters (when I click regenerate)?

 

Heater relations.JPG

 

As far as I can see there aren't any better ways to accomplish what I'm trying to do. I have had a look at Creo Options Modeler but I'm not sure it works well for very large assemblies and configuring both component existence and placement/orientation at the same time.

avero
13-Aquamarine
(To:pausob)

Disregard this

avero
13-Aquamarine
(To:pausob)

Attached is the same model from Creo 4, the file above can probably only be opened in Creo 5.

Top Tags