I have a conundrum. Typically, the policy for any data that is used for manufacturing is that the Item revision and datasets contained therein are released. The policy for changing any Item is create a new revision.
We utilise part families for designs where there is a lot of commonality, and what is different can be controlled by variables in a table. Sometimes these part families need to be expanded to include new family members. Typically, all common dimensions appear on a drawing associated with the part family seed part including a chart containing all family members and their variables. Typically there is separate CAM data associated with each part family member as a manifestation of the part family member Item Revision.
Policy requires that the part family member and the seed part drawing have the same revision so that the parts are made and inspected to the correct revision of the drawing. This means that if i have, say, 30 members in a part family (and on the chart drawing) then I will have to revise the seed part and every exixting part family member to the next revision, and then create the new family members at that revision also. This way all members and the seed part will be at the same revision level. The problem that this causes is that aside from the significant revision and releasing burden on the drafting office (unsuring all parts pass quality checks and correct attachments, etc.), the manufacturing engineering department need to update all the CAM data, post, test programs, etc. all because we need to add one more member.
The proposed solution also has some drawbacks. The proposed solution is to remove the chart from the drawing face of the seed part, but still leave unresolved variables on some of the dimensions. Each part family member has it's own brief drawing, basically only providing the missing data for the part family drawing in the form of a one line chart. This way the part family drawing never changes when a new member is added (it only changes when a core feature changes that affects all members). This means that the family seed part and all existing members can stay at the same revision and any new members can be created at that same revision level.
The drawback to this solution is that the part family seed part either needs to remain unreleased, which leaves it prone to accidental modification (although baselines could be used to maintain a history, and a checkout could be maintained to ensure no accidental changes), or it could be released and then unreleased modified and re-released each time a new member was added. Obviously, unreleasing is not generally considered to be an acceptable solution.
Has anyone out there in PLM land had the same or similar ussues with maintaining part families, and has anyone found a good solution?
John G from ANCA