topic Re: PTC_CONSTRAINT_SET and distance calculation in 3D Part & Assembly Design

PTC_CONSTRAINT_SET and distance calculation

avero — Thu, 05 Dec 2019 12:55:51 GMT

Hi,

I have made a simple test assembly to show how components with PTC_CONSTRAINT_SET don't always behave the way I want/expect them to. I want to be able to add/remove/configure components quickly and have used a combination of PTC_CONSTRAINT_SET and distance calculations to achieve this. This assembly consists of four parts - cube, sphere, pyramid and cylinder placed on a fifth part called ground. The four parts can be added or removed based on the value of connected parameters called cube, sphere, pyramid and cylinder. The pyramid and cylinder parts can also change orientation by changing the value of parameters PYRAMID_ORIENTATION and CYLINDER_ORIENTATION. Can someone please have a look at the attached assembly PTC_CONSTRAINT_SET.asm and tell me why the parts behave the way they do?

Initially, the assembly looks like this:

Here is the complete relations text in PTC_CONSTRAINT_SET.asm

Here are the available values for configuration parameters. I have also added planes with the same names in a group called configuration for easy configuration - you can change the parameter values easily by changing the values of these planes.

(The values are initially set to CUBE=1, SPHERE=1, PYRAMID=1, PYRAMID_ORIENTATION=0, cylinder=1 and CYLINDER_ORIENTATION=0).

If I remove the cube part (change value of cube to 0) and click regenerate, the assembly looks like this:

If I change the orientation of the pyramid part (change value of pyramid_orientation to 1), it looks like this:

Finally, changing cylinder_orientation to 1 makes it look like this:

The cylinder part is misplaced and regenerate doesn't do anything, but if I either click edit definition or resume/suppress, the assembly looks like this:

At first, I made the assembly without the cylinder part, but the model would only get stuck occasionally and I could not seem to reproduce it consistently, so I added another part with PTC_CONSTRAINT_SETs and now it gets stuck very often. It will get stuck in certain combinations and regenerate doesn't do anything, can someone please tell me why? How does regenerate and edit definition consider placement differently? This is obviously not a huge problem with this simple assembly, but I am trying to use the same method for more complex assemblies and that causes more problems. As I already wrote, the more components with PTC_CONSTRAINT_SETs, the messier it gets. Any suggestions?

Thanks,

Avero

Edit: I am using Creo 5

Screenshot of Model intent -> Program

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Thu, 05 Dec 2019 14:49:00 GMT

It might be quicker to let PTC technical support look at this. Do you have active maintenance? If not, I'm more than willing to submit this to them and see what they say...

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Thu, 05 Dec 2019 15:16:37 GMT

I can reproduce the issue with Creo Parametric 6.0.3.0. I tried moving the relations into their respective components and features, but it didn't make any difference. After the last orientation change, the correct set seems to be active, and the value is correct, but the model is not snapped to the position specified by the set. For some reason it continues to stay at the last position of this set when it was last active. I think PTC will need to take a look at this.

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Thu, 05 Dec 2019 15:17:47 GMT

I'm going to open a case...

Re: PTC_CONSTRAINT_SET and distance calculation

avero — Fri, 06 Dec 2019 06:55:52 GMT

Thank you!

Re: PTC_CONSTRAINT_SET and distance calculation

jbob — Fri, 06 Dec 2019 19:30:29 GMT

another option would be to create coordinate systems for each of the components and constrain to them. now write your relations to move around the coordinate systems.

question, when using multiple constraint sets and you rotate that component, don't you get invalid constraints during the edit definition?

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Fri, 06 Dec 2019 19:54:26 GMT

@jbob wrote:

question, when using multiple constraint sets and you rotate that component, don't you get invalid constraints during the edit definition?

No, because the first constraint set is completely disabled when the second set is enabled. The two sets don't fight with each other since only one set is active at a time.

Re: PTC_CONSTRAINT_SET and distance calculation

pausob — Fri, 06 Dec 2019 20:06:07 GMT

Hi, this remains an interesting unsolved case.

I can't open your Creo5 file so tried to make toy example similar to your new example - using similar structure of assembly level relations & pro/program code to drive constraint sets and existence of components.

Except I didn't use a value of a dimension to determine the logic of whether a component exists or is rotated - I defined Yes/No assembly level parameters:

Toggling these yes/no parameters and regenerating seems to work just fine. Please try the attached model yourself.

So your code should work, I think, but there is something wrong:

- something in your assembly constraints that gives problems? unlikely as re-edit-definition fixes the connections without picking new references

- using dimensions (real numbers) to define On/Off states - round-off errors causing the logic to fail? - again, unlikely because it seems that the correct offset values and constraint set names are being set.

- bug ? - nah, this is PTC software 🙂

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Fri, 06 Dec 2019 20:31:55 GMT

Forcing a model player regen also fixes the issues with the original model. That's why I wondered if it was a regeneration order issue. Unfortunately I wasn't to find anything like that, even after reordering a bunch of stuff.

Re: PTC_CONSTRAINT_SET and distance calculation

avero — Tue, 10 Dec 2019 06:35:41 GMT

Yes/No parameters seem to work fine, but sometimes I want to have more than two options for each parameter, for example a parameter called placement could have the options left, right, front, back, roof, internal etc. I don't think I could make that work with only yes/no. Perhaps I should give string parameters a try? I would still be interested to know if this is some kind of bug or if I'm doing something wrong somehow.

Re: PTC_CONSTRAINT_SET and distance calculation

avero — Tue, 10 Dec 2019 06:39:38 GMT

I'm not really sure how PTC handles these technical support cases, have you heard anything from them yet?

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Tue, 10 Dec 2019 13:57:34 GMT

Yes and no. They asked a couple of follow up questions after I opened the case, but I haven't heard back on why the behavior is happening yet. I'll let you know when I do.

Re: PTC_CONSTRAINT_SET and distance calculation

pausob — Wed, 11 Dec 2019 06:56:10 GMT

As you suggest, string type parameters should work great for those multiple-choice scenarios.

You could also use parameter of integer type (though the coding would have to be documented - which is a good thing).

In general, I think that parameters are more appropriate for storing and manipulating the "meta" information about the model, while dimensions should just describe feature locations and sizes.

So, frankly, I think that your implementation of using the dimension values to encode "state information" is an inventive hack which will be hard to maintain and to explain to new users. Nevertheless, I don't see why it would cause the demonstrated weird behaviour - therefore I am curious about PTC response.

Re: PTC_CONSTRAINT_SET and distance calculation

avero — Mon, 16 Dec 2019 12:28:35 GMT

Where does L1_DIST and L2_DIST come from in your model? I can't seem to find parameters with those names on any level?

The main difference between my model and yours seem to be that you have attached the components to a number of level planes (I don't think I could use this method as I might want to place the components on any side of the component named ground) rather than it being constrained to a distance from the assembly coordinate system origin, which made me wonder - If I want Creo to do more than one distance calculation (one for each constraint set) the correct way to do this is

IF CUBE==1&SPHERE==1&PYRAMID==0

D31=500

D26=500

Right? I have also tried

IF CUBE==1&SPHERE==1&PYRAMID==0

D31=500&D26=500

But that gives an error.

I have now also tried using integer, yes/no and string parameters instead of real number, but the same behavior as before occurs in my model.

PARAMETER is real number, as used on the first page of this thread. PARAMETER_1 is integer type, PARAMETER_2 is yes/no and PARAMETER_3 is string type parameter. It doesn't seem to matter (to Creo) which one I use.

Re: PTC_CONSTRAINT_SET and distance calculation

pausob — Mon, 16 Dec 2019 23:36:41 GMT

@avero wrote:

Where does L1_DIST and L2_DIST come from in your model? I can't seem to find parameters with those names on any level?

L1_DIST and L2_DIST are just named dimensions - they control the distances between the level planes.

The main difference between my model and yours seem to be that you have attached the components to a number of level planes (I don't think I could use this method as I might want to place the components on any side of the component named ground) rather than it being constrained to a distance from the assembly coordinate system origin, which made me wonder - If I want Creo to do more than one distance calculation (one for each constraint set) the correct way to do this is

IF CUBE==1&SPHERE==1&PYRAMID==0

D31=500

D26=500

That should work... (see below)

Right? I have also tried

IF CUBE==1&SPHERE==1&PYRAMID==0

D31=500&D26=500

The above syntax is not correct.

But that gives an error.

I have now also tried using integer, yes/no and string parameters instead of real number, but the same behavior as before occurs in my model.

PARAMETER is real number, as used on the first page of this thread. PARAMETER_1 is integer type, PARAMETER_2 is yes/no and PARAMETER_3 is string type parameter. It doesn't seem to matter (to Creo) which one I use.

So just as you were saying all along, it seems that there is a bug in the software because changing value of dimensions that belong to inactive constraint set does not update the placement (the value changes, but system does not regenerate the component in the new location).

This is very hard to explain well, so I attach the model for your review.

if link3's constraint set "Upright" is active because link3_rotated parameter is set to NO, then changing the above relations to offset_upright = 0 and regenerating will lower link3.

However, if instead you change the above to offset_side = 0, then set the value of parameter link3_rotated to YES, and then regenerate - this will leave the link3 in its old location (44 units above). Then doing the "edit definition" will snap it back to the new setting of 0.

Re: PTC_CONSTRAINT_SET and distance calculation

avero — Wed, 18 Dec 2019 08:49:37 GMT

I don't think you attached the model as you intended, but I understood the explanation. It seems we agree this must be a software bug then; you should be able to change values of currently inactive constraint sets and the components should then be placed correctly when the active constraint set changes upon regenerating the model. This doesn't seem to happen when you manually edit values of inactive constraint sets though, only when using relations.

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Tue, 17 Dec 2019 13:59:08 GMT

Just to follow up on this, an SPR has been filed and R&D is supposed to be taking a look at this. I'm not expecting to hear anything back until some time in January.

https://www.ptc.com/en/support/article?n=CS318195

https://support.ptc.com/appserver/cs/view/spr.jsp?n=9618855

Re: PTC_CONSTRAINT_SET and distance calculation

TomU — Fri, 31 Jan 2020 17:32:16 GMT

Latest update from tech support:

"A fix to this SPR has been submitted to Creo 6.0.4.0 which is scheduled for release mid-late February. After retrieving the assembly, edit the definition of the cylinder part and complete and the process outlined in the case and post will behave as expected – the cylinder will use the correct placement location and orientation."