I've added a column for the material in my family table using PTC_MATERIAL_NAME. However, any instance that doesn't use the assigned Generic material has a regeneration issue. Whenever I press regenerate it says "Material XXXX was assigned to the part" in the message log. And this occurs for any higher level assemblies that use this part. I'm expecting no regeneration to occur if nothing has changed. The higher level assy should say "Automatic regeneration of the parts has been completed.". However, with the instance inside of the assembly, it doesn't say that. It keep on regenerating the assembly and saying "Material XXXXX was assigned to the part. Automatic regeneration of the parts has been completed." I would like to avoid this at all costs because I don't like my assemblies to regenerate if nothing has changed. It causes nightmares when the assembly is promoted and released in Windchill but still used in higher level assemblies. Can anyone help me with this? The easy answer would be to not have the PTC_Material_Name in the family table. I would like to avoid that if possible.
I tested your problem in Creo Parametric 2.0 M090 (without Windchill). The problem disappeared when I saved Instance Accelerators for family table instances. Unfortunatelly I don't know how Windchill manages Instance Accelerators...
I did save the instance accelerators for the instances and it still gave me issues when the instances were placed in an assembly. My specific example is a standoff family table where a swage standoff is going in a board assembly.
it is possible that the problem is related to your data. If you want I can send you my test models (let me know what ProE/Creo release do you use).
I am sorry I am not able to recreate data (that I created and then deleted this morning) to show you assembly regeneration without "Material XXXXX was assigned to the part" message...
It still regenerates unecessarily, causing any higher level assemblies to regenerate. I'd rather it say "Automatic regeneration of the parts has been completed." if possible. These are going to be library parts for about 30 mechanical engineers. I don't need people complaining that the instance is causing their assemblies to regenerate when nothing changed.
It's probably due to the mass properties being recalculated based on the material properties. I've seen this calculation forced by a relation that sets a parameter equal to the mass properties so that the value of the parameter can be pushed to Intralink or PDMLink.
It's possible that eliminating such a relation might quiet the behavior.
An alternative is to open an SPR with PTC.
Attached is a test assembly (zipped).
Just open it up and press Regenerate. Every time you regenerate it keeps on assigning material to the instance.
BTW, what part is it that it's made in so many different materials that it would need a family table for it? Can't you just make seperate parts?
I would make 1 screw family in steel, 1 family in brass, 1 in nylon, etc...
That way you don't need to put the material in the family table, just the dimensions.
It is more important they be in the family table than have the material in the family table. People swap out HW all the time. I really don't NEED the material to be in the table.
HW = Hardware, where an engineer will one day decide s/he needs a brass standoff and the next a nylon one. Using a family table is much quicker and easier than just replacing. The material property within the file isn't really that necessary.
Why would you need the actual material properties to be set? Are you doing analysis on the parts or use the mass properties for anything other than identifying it at next level assemblies?
The idea behind the provided properties in parts is that you don't have to build them yourself in relations/parameters. If you need to, you can build your own but you won't get the additional tools that PTC provides. Meaning; the volume will be the same but the weight of the part will vary. To calculate the weight, you now have to manually calculate the weight for these components and manually add that to components that actually use the built-in material properties.
Making the material global for all family table parts is a huge oversight on PTC's part. I hope there is a simple answer, but I suspect you will get the stock reply... "it works as expected".
Not sure for Joseph, but there are several good reasons for putting materials in the Family table.
#1, materials can include appearances; this is the only way to get different colored items in a family table without adding copies of surfaces that are mostly supressed.
#2, so that the ERP system can access the materials via Windchill
#3, so that engineers get the correct one and don't have to pull out some other document to tell which of the 3000 standoffs is nickel-plated brass.
#4, so that the mass properties are correct.
Given that PTC allowed adding materials to FTs for these reasons, it is probably a screw-up; hence my suggestion to open an SPR with PTC. Consider PTC shipped a recent version of their flagship software that was torpedoed by trying to use it with their other flagship product. C2M080/WC.
I tried to assign specific appearances to family table instances using materials several times. Unfortunatelly this procedure does not work. If you have functional example, please upload it.
A little bit off-topic, but appearances do not work for me either. What I do is use an offset to shrink the part of the model I want colored differently. Then I copy the surfaces. Offset the surface back up with the same distance as the offset down. I then color the offset surface (this is important... only coloring the offset surface will work). Then I solidify the offset surface and the new solid is colored. I repeat for each color starting with the copy surfaces. I then toggle each copy in the family table. Viola - different colored items for family tables. I haven't seen this approach anywhere, but it works nicely. Better than the offset surfaces approach since this is a solid and you don't have quilt issues in drawings with it.
My recollection is the same as follows, except in WF5.
From another thread, http://communities.ptc.com/thread/38056 :
Apr 16, 2012 8:06 AM (in response to GregFrankland)
"You need to have appearances assigned to the materials in the material library that you want to use. Then you need to make sure that ALL the materials used in your family table have been loaded in the generic part. You need to use the parameter: "PTC_MATERIAL_NAME" as a coulmn in the family table, and then you can pick from a pulldown menu a different material (and thus appearance) in the cell for any instances desired."
"I haven't done it in a while, but it was WF4. If I remember, all the instances took the color of the last instance assembled. Then I did a regen and they all went to their respective colors.....until I added another instance. It's definately "buggy", but it DID work for me."
How's your luck with assigning appearance by material in non-family table parts?
If appearance assignment works for ordinary parts and not for family table ones, then push for an SPR. If it's not working for ordinary parts, there is probably an error in the way the material file is referring to the appearance file, or the assignment is being over-ridden by a direct appearance application.
Further Google searches indicate the ability to add materials and control appearances was added in WF3, but I don't see publicly available release notes to confirm. I do recall when that came out because the ability to color items via family tables has been an on-going discussion since rev 12, and likely earlier, so when PTC finally added the capability, it was noteworthy.
Finally, PTC should ship proof models with their software that include working samples of all the features. I realize they cannot include all combinations of all features, but at least baseline cases so one can tell if something is possible and working or not.