I have a work flow I'd frequently like to use but I can't figure out how to use Inventor this way.
As an example, I'll take aluminum X-extrusion. If you're unfamiliar, I've attached a picture of a short piece of 20/20 X-extrusion:
The shiny part is 20mm square, and you can get it in various lengths or cut it. The simple way to model this in Inventor is, of course, to sketch the X shape, then extrude the sketch for the length you want. But this is actually 4 identical slots at 90 degree intervals, so sketching a single slot and using a circular pattern in the sketch makes some sense.
But it would be useful to have the single slot in its own sketch; you might want to use the slot sketch to extrude a rail to slide into the slot, for example. It would also keep the complication of the slot geometry separate from the complication of the circular pattern. But suppose the sketch doesn't quite match the real object or you start using a different brand of X-extrusion that's shaped slightly differently; or you want to scale everything up or down. You might want to change a dimension, or even change the sketch geometry a little. But you'd want those changes - geometry and parameters - to percolate from the slot sketch to the X sketch. Also, you might want to use the same sketch in multiple parts or even projects, placed in different locations with respect to the context you're using it in, and have geometry corrections update the sketches in all those places. This behavior might even have much more utility when there's more happening in the complex part than a simple circular pattern.
So, the goal is to have two general objects available: a more complex object which contains (a reference to) a simpler object.
- Changes to the objects update all instances of the objects;
- Changes to the more primitive object updates the more complex object (and all instances of both objects);
- Parameter changes in instances of the more complex object can affect the contained instance of the primitive (but obviously, not the general primitive object or any other instances of it). For the X-extrusion example, there would be available for placement in parts and/or assemblies a "slot" and an "X"; if "slots" had a "slot width" parameter, changing a corresponding parameter in "X" would change the "slot width" parameter of the "slots", but only in that "X" instance.
SKETCH BLOCKS
So I explored sketch blocks as a solution, including putting sketch blocks into their own part and deriving from it.
The obvious limitation is they only work with sketches. If all you're doing is extruding the sketch, it's easy to do that each time. But if you add other features you can't encapsulate them in a sketch block. I can live with this limitation, but the worst limitation is parameters: You can parameterize dimensions in a sketch block, but each usage instance doesn't have its own set of parameters. When you derive, it "sort of" does, but when you update the part it uses whatever the parameters are set to in the sketch block part at the time. I've written iLogic code to set the parameters, enable the derivation link, update the derived part, then disable the derivation link again. It kind of works, in a really junky and convoluted way, and it may be the best solution. Putting the code into a DLL might clean things up a bit, but it doesn't seem to be "as intended" to leave the link disabled most of the time.
iPARTS & iFEATURES
So I delved into iParts and iFeatures. Their parameters are per instance, and they work for solids. The problem with iParts and iFeatures for this purpose are different.
With iParts, I could find no way for iParts to percolate parameters up the chain to the more primitive parts (like the slot sketch). Placing an iPart in an assembly requires that you populate the iPart's parameters with hard-coded numbers. It doesn't create regular parameters in the assembly, and if you created user parameters in the assembly first, it doesn't let you use them for the iPart parameter values. If you derive a part from the assembly (with the intention of creating a more complex iPart factory), there's no way for that part to set the primitive iPart's parameters. That's too bad, because otherwise iParts would do it. You can change the geometry and do another "Create iPart", and then when you are in the assembly Manage - Update puts the changed geometry into the already-placed instances in the assembly.
Unlike with iParts, I found no way to change an already-placed iFeature; re-extracting the iFeature didn't update already placed instances. This seems to be "by design", according to a forum post entitled "Update of an iFeature doesn't update existing files". Other than that, iFeatures seem to work the way I want. I was able to nest and a parameter specified in the more complex iFeature could affect the part of it from the less-complex iFeature, and the parameter could be changed after placement either by double-clicking the instance or via the regular parameters list. If I'm not mistaken, iFeatures work for sketches as well. But that one limitation evicerates the capability.
CONTENT CENTER
So I gave up on iParts and iFeatures, and looked at Content Center.
Published Content Center features can be placed, and then those instances can be included in other published features. While the parameter names are not preserved, at least for dimensions the placed complex feature will have a model parameter for each dimension in the primitive it includes. This seems to be independent of any other placements of the primitive. Unfortunately, there appears to be no way to include user parameter in a published feature. But that's a limitation I could probably live with.
Content Center features can't be updated. They must be republished. As far as I could tell, this requires that you actually explicitly delete the feature from the library using the Content Center Editor, then publish it again as you did the first time. In my testing it appears that the placed instances are orphaned; at least, they show the features before the republishing, and I know of no way to update them to match the republished version.
END OF THE ROAD?
Is there anything else I should explore to achieve this fairly basic generic functionality?
