The company I work for has a lot of 'similar but different' parts. For example I'm currently working on some end plate assemblies for a conveyor. Each consists of a couple of simple weldments plus sheet-metal cover and fasteners. We make them:
In total I have 33 top level assemblies.
Right now we control material/finish with notes on a document that goes to laser programming with the CAD files, so the same part number gets programmed whether we want a mild or a stainless one: the programmer simply alters the material to suit. We would like to improve upon this so all part numbers call up a mild/galv./stainless part straight from CAD.
I want there to be a link between the three material versions of each size, so if I change the mild steel version, all three versions update, as they all have the same geometry. My question really boils down to whether I do this by deriving the mild steel part into two further parts - galv. and stainless - then form sub-assemblies from these OR do I create iParts/iAssemblies?
I've played with both a little. Derived parts seem a LOT more simple to set up and are understood globally (here anyway!) whereas iParts/iAssemblies seem more convoluted to set up, could only be edited by a few, yet perhaps offer a nicer experience when it comes to inserting in assemblies later.
I've tried to give a bit more context and explain my aim but if anything is unclear, please do ask... Any input welcome!
In my industry experience, derived parts seem to be the way to go for you. iParts can be so... manual and closed-door. iParts are better if you have a set number of parts that will never ever change. I have used them in lieu of content center parts for elbows, or other odd fittings. The base part or assembly can be edited and the changes trickle down to the derived parts.
iParts are best for creating fastener library, as it enables easy changeover in assembly. also no need to have multiple files for each parts.