Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Skeleton Identification

Sandy McKay

New member
Hi All,

I'm looking for some imput from the real world....

I have an assembly built on a skeleton and I'm looking for a method of identifying that skeleton model so that I can track changes per my ISO documentation. ( We are not currently using Interlink)

Should I:

-assign the skeleton a part number and track it's changes thru our ECN process.

(Benefit; positive control, Problem; another part number to track & administer)?

-assign a descriptive name

(Benefit; less part numbers, Problem; less control-track changes thru ECN's to those parts affected by skeleton)?

Any imput would be warmly recieved....



New member

If changes to the skeleton impact subsequent parts/assemblies and you desire positive already know the answer.....give it a part number and track it's changes thru your ECN.

Advice is something we seek when we already know the answer but wish we didn't....or something like that.


New member
'wcwood', i think both of your ideas sound like a solution to your issues, although i'll give you my spin on this....

Depending on your company numbering and modeling standards, it may be possible to simply consider the skeleton of your assemblies as a model feature in theory. If your assembly model filenames are your part numbers then you may simply create your skeletons in the format PN_skel for PN being the number assigned to your assembly that the skeleton controls. Any subsequent ECN's would most likely be derived to make changes to your assembly design and/or part design criteria, which may be tracked via drawings (if thats what your using) or the ECN itself. Although skeletons control your model values, it doesn't necessarily mean that it's the skeleton you want to track and ECO. ECN's could be established for those assemblies and affected parts and to actually modify the models to make the changes, the design activity would simply change the skeleton values to meet ECN requirements. This shouldn't be a problem in that your assembly changes are tracked and defined by the ECN and in order for users to make the changes to the affected models/drawings, they would have to modify the proper skeleton (which is easily defined by the PN in its name), regardless of ECN. Obviously there are file management issues that are important to this as well, as to maintain a history of CAD files (versions) to reference for ISO and piece of mind reasons.

Example: Assembly named 123.asm would have a ECN requiring a dimensional change to it. Designers would simply open the 123_skel.prt and change the value that is required & save, when the assembly 123.asm is regenerated and saved the versions of all the affected models would be increased, in affect helping create history to track changes. It is the final product and pieces that matters most and needs record of change not necessarily your method of modeling. If your assembly is truely controlled via your skeleton then it would be impossible to make design intent changes issued by ECN without modifying the skeleton, so i'm not sure it would be necessary to ECN the skeleton. By using the PN_skel scheme you don't need to assign a new number or name and it is easily identified which product the skeleton affects just by P/N alone.

I also agree with jeellis if you cannot apply the above mentioned example with good electronic file procedures, then positive changes may best be controlled via ECN and a new P/N for the skeleton.

If anything, this reply gives ya something to think about...

Good luck!


New member
We use a technique similar to what gcook describes. In my mind, you don't assign a part number to something you don't build or buy. You are buying or building the assembly and that is the right place to assign the part number and maintain your control. I would liken the skeleton to another document used to help describe the assembly. The version/revision, or whatever you call them in your compeny, would be in lockstep with the assembly.