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

Mass attribute relations


Re: Mass attribute relations

That is what I thought, too, but my relation code proves otherwise.

When you add mp_pro_alt_mass to the model tree, it is blank.

My weight code fails until I enter 0 or some other value for mp_pro_alt_mass in the parameter field.

Re: Mass attribute relations

Interesting.  Did you notice that none of the mass property parameters have a type?  Maybe a case is in order...

Re: Mass attribute relations

Prior to a value being assigned they cannot be accessed by J-Link either.  Weird.


"By default, mass property parameters do exist in the models, but have no value assigned."




Re: Mass attribute relations

I opened a case.  We'll see what tech support says.


A few more interesting articles:

Re: Mass attribute relations

I tried this and it still barfed up error codes.

IF EXISTS ( "myVariable" )
  do stuff with myVariable

Always fails if the stuff I want to do involves the (possibly nonexistant) parameter.

I tried out the method I suggested on an existing part, and it worked, but didn't work for a fresh new part, even after I had done a mass properties analysis, which was giving back nonzero values for the mass. This is an oddity, to be sure.



Re: Mass attribute relations

It used to be that this was only valid in repeat region relations (in a drawing).  At some point PTC extended it out to relations in other areas (parts, assemblies, etc.) but I'm not sure how well they actually tested it...

Re: Mass attribute relations

Alternate mass properties are a very important feature to maintain easily the weight of big assemblies, and to have an accurate display of this value in drawings for single parts.


The most important attribute for this feature is PRO_MP_SOURCE. The value of this string attribute can be one of: 




Your relation must valide first where the source is. Geometry act like the default, value is driven by 3D Volumen and MP Density. 


You do not need to add a relation like I saw in all in the examples.


weight = pro_mp_mass


This is all you need, if you don‘t want the PTC‘s default name ,pro_mp_mass‘. Based on my toolkit experience with this attribute, I guess you can‘t initialize this per relation. I thing this makes no sense.


 PRO_MP_SOURCE will decide where the final value comes from.


Make it simple and start with a model. I see no reason why a model can’t have the correct weight. But it will appear, that the reported value is incorrect. 


Your model is not really a twin. What to do, two options here ...


  1. change your density, so your weight is now 100% correct
  2. Change  PRO_MP_SOURCE to Parameters and assigned an alternate density, if you can‘t change the official one, due to some reports dependent on the official density.

This has no effect for center of gravity and most of the other parameters.




Now Creo will report for your model the correct weight and will use that weight in each assembly on reports.


For Assemblies this is even more handy. 


If a sub assembly weight in Creo is invalid, change PRO_MP_SOURCE to Parameters as well and enter your 100% weight at  PRO_MP_ALT_MASS. 





All Assemblies using this sub assemblies will report the weight based on you new value, no further action required (bottom to top).



The value is no longer automatically updated (was wrong, anyway)



If you use FULLY ASSIGNED as your source, you have to enter a value for each alternate parameter to avoid an error. By File your Mass property file must be maintained.



Even in Toolkit, the alternate Parameter a way tricky, because of the strange type, spend some time to initialize them proper :-) Magic NULL


Have fun ...


Re: Mass attribute relations

OK, so I think I understand, we don't actually need to make any relations, instead we should enter the measured mass in PRO_MP_ALT_MASS and change the parameter PRO_MP_SOURCE = PARAMETERS then PRO_MP_MASS will be updated to equal PRO_MP_ALT_MASS.


The only snag I found is that after changing PRO_MP_SOURCE = PARAMETERS you then have to update mass properties in order for PRO_MP_MASS to update, setting mass_property_calculate to automatic will update PRO_MP_MASS on regen but at present we have ours set to by_request.


Also we are asking the users to do 2 new things, set the value of PRO_MP_SOURCE and enter a value in PRO_MP_ALT_MASS


If we use the relations method we can leave the mass properties calculation set to by_request and the only extra step for the user is to enter a value in PRO_MP_ALT_MASS.


What is the effect of setting mass_property_calculate = automatic ?

Re: Mass attribute relations

If you change this to auto, you may end up, in updating or creating new requested parameter for older components, where you don’t have this. E.g old library components, and this may be tricky if you use Windchill. For single components make sure your density will set the perfect weight. You can easily have a small interface for this. For assemblies you ask the user to change the source and mass, or doing both by a small interface as well.


I would not set the source for components to be ‚parameter‘, only for assemblies, and here maybe just before release. In creo you have both reports available. Note: I can’t remember if you can reset this alternate mass parameter back to be void. I would not change my template to have them all included. At all it is a nice feature, which allows you to have proper values at assembly level. 

Re: Mass attribute relations

Thanks a lot for all your contributions, I have 1 additional question, when we designate a mass attribute into Windchill, the calculated mass has 13 decimal places and is displayed in base-10 format as below:


I would like it to display to 3 decimal places with leading zero, as this is how we will enter the estimated mass attribute in the WT part.


I know there are Real to String conversion relations but Im not sure how could I combine this with my relation: