Back to the Series Introduction and TOC
The concept of passing Parameters is one of the (if not the most) useful things that Autodesk Inventor will do to help you develop your Top-Down design. This involves using Parameters in numerous ‘child’ part and assembly files that have been previously defined in a main ‘parent’ reference file. Even if you only make a box and constrain everything to it, Parameters are still at the heart of the process. The result is that when you change a Parameter in the main file, the entire design recognizes the adjustment.
These recommendations are the focus of this discussion:
- Convey Design Intent with Shared Parameters
- Parameter Naming conventions
- Excel Spreadsheet linking
Convey Design Intent with Shared Parameters
A main skeleton part file should be used to store core parameters that shape the overall design. This skeleton is then passed on to to the other parts and assemblies in the design through a Derived Component. This process permits the overall Parameters to be passed on to the Derived Component, thus inheriting a portion of the design intent. Like DNA from parent to child.
Some common parameter examples: Main mounting hole diameters, Edge clearance offsets, Sheet Thickness, Rivet spacing pattern multipliers, and so on. If these values are referenced over and over in a design then having it defined in one place will make the intent clear, and make alterations to the global design as simple as editing one parameter.
Some stability and efficiency can be achieved with spreading predefined parameters to sub-skeletons that only pertain to a portion of the design. This way you are not passing parameters down through half the design that never reference them. I’ll discuss this more in the derived components discussion.
It takes patience. It is often easier to key in the known value that to dig through the list of parameters. Take the time to dig. What happens when Stress Analysis reports that your sheet thickness is too thin, and the entire design was founded on 0.063” ? You get to search the design from bottom to top looking for that sheet factor and edit them manually.
Parameter Naming Conventions
Parameter names should be established with some certainty up-front before the first component file is created. These parameters will be distributed throughout the design, used in equations, and become the design matrix. Then names can be changed in the main file, and will adapt accordingly throughout the design. However, poorly thought-out naming conventions can leave you with confusion when you are half way into a design.
Names should use something that makes sense so that no matter where you are in a design, when a parameter is discovered, a general understanding of the origin and use can be determined from just looking at the name. It also makes them easier to find in a list when searching for it.
Parameter naming should be:
- Reasonably short
- Reasonably simple
- Absolutely CONSISTENT
- Specifically convey the intended use of the data
I tend to try something like this: Component/Use | Specific Feature | Parameter and type
BracketArmTabLength, NozzlePosAng, HeadToolPatternCount and so on.
Another method might focus on the sub-skeleton file that it was created in. This would convey an understanding of where it was created and in what portion of the design it was utilized.
MainFuselageRibSepFactor, LGUpshaftFreeLength
Roadmap the parameters – build a cheat sheet that includes where the parameter originated at. Distribute it to your project members. Understand that in the beginning there would be a great deal of growing pains, but with these would come more efficiency and less pain than before you had tried to implement a standard.
Excel Spreadsheet Linking
You can link an external spreadsheet for the parameters, but this may become a burden. This has Pros and Cons. We have been able to link an external Excel spreadsheet to design components for some time, and now have a handy link button at the bottom of the Parameters Dialog.
Pros
- Predefined parameters are defined in a spreadsheet and are therefore easily accessible without editing a skeleton file. You can keep the spreadsheet open (in Excel) on the side, making it easy to refer to your parameters.
Cons
- You have ANOTHER file to link to the design
- numerous steps involved to introduce a new parameter
- Changes are not as easily updated
- Parameters often need to be evaluated before applying, and that must be done in the model in the first place
There may have been enhancements since I last used a linked spreadsheet. I can say from experience that the time involved to add parameters to the list and update the respective component files is far too painful in relation to just opening the pertinent skeleton file and editing/adding the Parameter.
Comments
There is much more that can be said, but the best thing to do is just go for it. I guarantee there are so may more smiles that frowns with this methodology. Especially when you back to make the global changes.
Always use your parameter descriptions. Describe what the parameter is, and where it originated at. Eventually you will want to tap into a parameter, and have to play with things to remember which one controlled what.
