I was wondering if anyone had a set of best practices for setting up master models and simplified reps? Currently I'm dealing with a very large master model containing about 10 different versions of a large piece of machinery. The master model has a simplified rep for each version of the machine, but the current structure is causing the simplified reps to fall apart when parts are changed or updated. Here is an example of the current structure:
In this example, sub-XXX would be a major subsystem like an engine or chassis. The part-100X would be a part/subsystem for a specific version of the machine. For example, machine A may have a 4 cylinder engine and machine B would have a 6 cylinder engine. The problem we are having is that the simplified reps have been created using the part level (in bold). When parts are changed, the simplified reps are no longer correct and someone must go back and update everything again. This has caused a great deal of frustration and wasted time, so I'm proposing that we change the structure to something more like this:
In this example, the sub-100 and sub-100A levels would be a permanent structure that is setup when the master model is created. The 100 level would represent something like the engine group and the 100A level would represent the specific size/type of engine. The simplified reps would be created using the permanent structure rather than the part level so that they will stay up to date when parts are changed.
Is this the best way to make sure that the master model doesn't constantly fall apart or is there a better way?
I would suggest looking into family tables rather than simplified reps:
I would love to use family tables, but they are strictly forbidden because our data management system can't handle them. We are even forced to use simplified reps to create sheet metal flat patterns.
Family tables are good for low option content / small assembly where only one individual is touching the assembly. But if you are in a develoment environment of collaborating with mutliple design groups with multiple systems and options than simplified reps is what I've found to be the most reliable.
Your best bet is to have the top level simplified reps substitute in reps from the lower level defined sub-assemlbies as you have identified. This requires some upfront work of creating the assemlby structure and defining the sub-assemblies that contain the simplfied reps where users are populating new content into the assemlbies. You may find out that some system assemblies benefit from having simplified reps at multiple levels(picture below). The key is that you need to have a simplified rep in the assembly where the engineers are adding/changing .prt files. This does require a lot of upfront work in creating the assembly structure with intimate knowledge of each system and the organization of your design groups. Applying consistancy is key. Naming of the assembly, naming of the simplfied reps, assembly level where the simpflied reps exist are all important. If you place all the simplfied rep in the first level sub-assembly of the master model...you may find out that some systems require multiple sub-assemblies...that is when you will see the simplfied rep as shown below. In our environment this happens often...if you can avoid it then try to. You don't want to manage simplified reps at multiple levels.
In the picture below...the "derived" items are being turned on by the parent assembly simplfied rep. Anytime somebody updates the assembly with rep "no_xty_single", then the parent assembly containing the rep called hd_boc_365sb automatically loads the latest information when changes occur. This is what I define as collaborating with the latest information.
I believe you have already hit on the best solution -- have an assembly for each option. There are other ways to configure optionality, but I know of nothing that would be as robust.
Have you considered using Options Modeler? From your high level description - seems like it may be a good fit to what you are looking for. Options Modeler uses also simpreps, but does it in an automated fashion that includes/excludes items in each Module per applied configuration spec. That may help you get away from having to go down the structure and update "manually" each sub-level simprep.