It can be controlled by ACL's on the context so any file downloaded is read-only.
I am trying to remember what the Windchill preference is that can be set, too.
Problem is - any PRT or ASM in any context used for any reason can be a family table. May not start out as one.
This is where most of the issues come from when using family tables!
If you have a part and use it in 3 assemblies and then have to do an almost identical part, only 1/2 inch longer. Do you create a new standalone part or make the original part a generic and add the new one as an instance? If you do the latter, you have just shot yourself in the foot! PTC will tell you that the generic should NEVER be used, always use an instance. To take an existing part and make it a generic, it has to be renamed, 2 instances added, one matches the generic, the other is longer. Then all uses of the generic need to be replaced with the new 1st instance that matches the generic. If you only have 3, not too bad. If you have a few hundred uses, suicide!
Family tables need to be thought out and applied where they provide proper functionality. Ok it is easier to add an instance than create a new part and drawing, but you have still created a new part number that needs released into the system. Unless these parts may need to be interchanged, like using a longer bolt, or have very common features, washer or nut, why are you doing family tables? Like most things in CAD, just because it can be done doesn't mean it should be done. There are ususally multiple ways to accomplish a task, but only one, maybe two, or good for long term usage and part reuse.
Yes to this. Too many users see family tables as a magic part factory where they can just create and delete parts without any thought. Add in the 'tidy up' users who feel like if -they- don't see a need then there must be no need, so just delete to clean up what they don't understand and not just family tables are ruined. In the real world these people would be seen using belt sanders to wash cars.
I haven't done that for a long time, but
In WC 9.1, we have a particular method that allow to remove a PRT from the familly table and transform it as a "standalone" classic PRT EPMDocument
To allow assemblies working well , without using the last version of generic that does not contain anymore the PRT as instance
download the Full FT in the Workspace
Open the instance in Creo session (important to have the instance in session)
Open the Generic in Creo session
activate the Generic and remove the instance and save
activate the instance and save it.
should be now a standalone classic PRT
Windchill keep history iteration so we can see that old itérations are instances.
and if get old assemblies "as_stored", get the instances, not the last standalone PRT
Don't know is still work in 10.2 or 11....
Correct. We use WC 10.1 and this still works. We usually use this method to make the obsolete instances standalone.
So ideally the entire family table along with the drawing will be revised together to the next revision before making the instance standalone.
To piggy back on Greg Perasso comments about making instances standalone........We have tons of legacy family table data, especially with all types of fasteners, fittings, clamps, etc, etc.
But a lot of the instances are at different revisions. We do have them all in a library context which is read only so the users cannot modify the family tables. But we have begun to associate CAD docs to wtpart for CAD driven purposes. Family Tables, Windchill and CAD driven BOM can be a headache at times.
So, we decided to strip the instances from the family tables on an as needed basis. This is a slick way so all instances will become stand a lone and the assemblies they belong to will not fail.
As an admin.........
Now, all assemblies in Windchill will have stand a lone parts in their assemblies, not instances.
One downside, if those family table files were in other workspaces, it will not let you update those components in your workspaces, PTC confirmed this.Here are some options........
Brad, George and Al must be having a fit at this!
The family tables would have parts at different revision levels as they were not fully populated at the same time. There is nothing wrong with adding new members to a family table at iteration 20. Just remember that the users will need to sync their workspace to replace the iteration 15 file they have in order to get that new addition.
Great idea/trick for making the obsolete instance(s) standalone but it seems like that needs to be done before instances get deleted/checked in? I have been trying to test if this could be done after the someone had already deleted the instance from the generic but I haven't had much luck as you have to check out the generic again to do the trick. I could look at combining it with leapfrogging but that seems like it could be hard to remember/repeat consistently even if it worked.
You can actually create a family table from an existing part and not lose the references to existing assemblies. I've written it as a 17 step process but at least you don't have to open up 100's of assemblies to change them. Here are the instructions that I wrote for doing that.
We don't allow family tables for assemblies, but do on parts. Needed to have a little bit of give and take. But we also have different instructions for if a family table object becomes obsolete, and for creating new instances when the revision of the table isn't the first revision in the revision table. Before we came up with these instructions and rules, there were so many family table issues that could not be undone that we put a moratorium on creating new family tables until we resolved all of it. Since then, there have been an issue here or there, but not like it was when we first went to Windchill and had users with a Wild West mentality. We also limited family tables to users that passed a family table test. So far users that shouldn't use family tables are pretty good at not.