Link assembly features to view representations

[m.verbunt]

We create composite swimming pools, and a pool is always a sub assy. When we place a pool into an assembly, we need to create cut-outs for lights, skimmers and so on. So we create those cut-outs on the customer specific assembly. With works really well. Now I would like to create a template, where all the possible cut-outs already have been made. Now I would like to use the view representation to create the different options, like one or two lights, left or right and so on. But this is not possible at this moment. Assembly features cannot be made visible/hidden, and unsupressing/supressing those features is useless because it cannot be linked as well in the view representations, and not even with LOD. It would be great if we could hide/show them by selecting a View representation.

[DRoam]

View representations, by definition, represent different ways of viewing the model, so they do not (and should not) physically affect the model. LOD, on the other hand, are intended to capture different physical variations and represent them accurately. So LOD is what needs improving here. And there's somewhat of a push for that started already, both for parts and assemblies.

The best Part idea you can vote on is this one: Level of Detail for Parts . There's not currently a good master idea for assembly LOD's/configurations, but you can vote on this one which will likely be merged into the master assembly LOD idea if and when one gets chosen: Real part & assembly configurations (redo iparts & iassemblies) (see my comment near the end with several other assembly LOD requests).

[swalton]

LOD were designed as a memory management tool.  I'd avoid them for configuration management.

Most of what the OP wants can be controlled with iParts and iAssemblies.  However those tools work best if the OP knows and includes all the possible design variations while building the model.  

So if the OP has a single pool shape, with 8 different light locations and 12 different skimmer locations, then an iPart is a good match.  If the OP has a single pool shape and the customer gets to pick the different light locations during the order process, iParts are not as nice.  

@johnsonshiue has mentioned a potential new feature called Model States.  This feature might be a good fit for the OP's need, but it has not been released.

[jtylerbc]

LOD's are really intended for memory management, rather than part/assembly configurations, so I would disagree that they are a viable path to solving this any more than View Representations are.  They really only work halfway decently as a configuration tool if you involve iLogic to help get the BOM right.  Note that I'm not arguing that we don't need a better configuration tool in Inventor - I'm just saying that I don't think LOD's are what that tool should be based on.

iPart and iAssembly are the real configuration tools in Inventor currently.  They have things they are good at, but are cumbersome to work with, and I don't think they would be a good fit for the application here.

@m.verbunt, if you're intending to use this as a template file anyway, I would propose trying a different technique, and I don't think there is anything limiting you from doing this now.  You would model the cutouts with assembly features just like you described.  However, instead of setting up your common configurations with View Representations (or LOD), you could use parameter and iLogic to create a form with lists, and some simple If/Then code to suppress or unsuppress features as needed.  

So the workflow would be:

1. Create new assembly from your template.
2. Use form to configure the cutouts and other features as needed for the customer.

This would potentially be more flexible than View Reps/LOD's could ever be.  If it were possible, your example with the lights would result in four representations that have to be created in advance:

1. Left side, 1 Light
2. Left side, 2 Lights
3. Right side, 1 Light
4. Right side, 2 Lights

If you add additional variables, this (potentially) gets out of hand very quickly, depending on how many options are available in your product line.  For example, if you also have two options for skimmer locations, you now need 8 representations:

1. Skimmer Location A
   1. Left side, 1 Light
   2. Left side, 2 Lights
   3. Right side, 1 Light
   4. Right side, 2 Lights
2. Skimmer Location B
   1. Left side, 1 Light
   2. Left side, 2 Lights
   3. Right side, 1 Light
   4. Right side, 2 Lights

However, if built via parameters and iLogic, these would all be independently selectable options in three different lists.  You wouldn't have to create every possible combination as a representation in advance, you just pick:

1. Skimmer location B
2. Left Side Lighting
3. Two lights

I think this could be a better solution for your application, without using any features that aren't already available in the program.  I'm still stuck working on Inventor 2018, and I think this would all be possible there.

[DRoam]

I was being a little generous when I said LOD are for physical variations. I really meant they're "closer" to being a viable tool for that than View Reps are. This is true mainly because View Reps, by definition, should never affect the physical model, whereas LOD's actually can affect the physical properties (mass, volume, etc.) of the assembly, if you choose for them to. So in that sense LODs create "physically" different variations of the model.

But as I said, that's being generous. Inventor simply doesn't have a good tool for creating different physical variations of a model, unless those variations are known up front and will essentially never change... which is a massive, game-breaking limitation when so many companies use Inventor for ongoing design work, not to create a predefined catalog of products.

We can use iLogic to get some pretty powerful configuration capabilities, but that also has a huge limitation: a given assembly or part file can only take on one configuration state at a given time. So you can't create a drawing of two or more configurations unless you create a new file for every distinct part/assembly in every configuration. This is also a game-breaker for most ongoing-design scenarios, and is better suited to "pre-configurated" build-to-order applications.

Our best hope is for the ideas I linked to above to be implemented so we can freely create, configure, modify, and swap out assembly and part configurations. Until then, we have to put up with the drawbacks of iPart/iAssembly, iLogic configurators, Derive workarounds, and/or the File-Save-As approach. Those last two are the workarounds I use to create "same-but-different" parts and assemblies, and they're a massive bottleneck when working with ongoing designs.

Hopefully the aforementioned "Model States" are real and would meet this need...... if so, they can't get here too soon for me!