Finding the Logic in iLogic™

1. Finding the Logic in iLogic™ Stan Wile Sr. Application Engineer Image courtesy of Engineering Center LTD, Russia

2. Rules Based Design

3. For Enterprise Customers

4. For the Average Inventor User

5. iLogic Overview • Autodesk® Inventor® iLogic enables Rules Driven Design (RDD) • iLogic reachesbeyond what can be achieved with existing parametric design technology. • iLogic  provides a more effective means of creating, capturing and reusing product knowledge.

6. iLogic Parameters • The iLogic Parameters dialog is used to create and edit custom parameters. • User = standard inventor user parameter • String = text • Boolean = true/false • Multi-value = combo box list of valid sizes or equations) • Advanced parameter filtering to assist in parameter input definition, management and editing.

7. iLogic Rule Editor • The iLogic rule editor is used to create and edit rules.  • A rule is a small Visual Basic (VB.NET) program, • usually with connections to Inventor parameters, features or components.

8. Rule Editor Options • Suppressed • A suppressed rule will not run automatically.   • You can still run it manually.   • You can also suppress a rule in the iLogic Tree Editor. • Silent Operation • Rule will run without displaying Inventor dialog boxes.  • Don't run automatically when parameters change • Checking this option will prevent the rule from running in response to parameter changes.  You will have to run it manually (or with iLogicVb.RunRule). • Straight VB code • This option is for Advanced Rule Programming.  • It allows you to share code between rules, but the shared code is harder to write.  • Don't use this unless you need it!

9. Place iLogic Component • Place most Inventor parts or assemblies as components in a larger assembly. • What this does: • Allows you to modify the value of component parameters before placing the component. • Makes a unique copy of the component, so it can be individually modified and driven by rules in the assembly. • Makes a copy of the component part (or assembly and parts) • Located in the directory of the assembly you are working in.  • All parameters are initially <Free>. • They are not driven by assembly parameters.

10. iLogic Demonstration

11. Best Practice - Do’s • If you’re an iLogic rookie do complete the tutorials that come with the iLogic install and have a look at the iLogic sample designs that also get installed automatically.  • Review the iLogic help documentation before attempting your first iLogic project.  • I know you all love reading help documents  • Do give meaningful names to parameters, features, and components in your models that will be directly referenced by rules.  • Do change all component names in an assembly that will be referenced by rules.  • Write out (in plain language) the rules you plan to write using iLogic.  • Determine key parameter, feature and component names in advance of building the actual parametric base model.  • Don’t worry about syntax at this point, but rather focus on completely expressing what all the rules are and try to cover all the cases you want to handle as exhaustively as possible. 

12. Best Practice - Do’s • Build (or rebuild) your Inventor model as necessary to support the full scope of modifiability that you hope to achieve using rules.  • Use rules in assemblies to do assembly level things • Suppress/unsuppress components, change component pattern quantity, replace components, change ipart configuration, etc • Keep rules as simple and as small and concise as possible.  • A rule should be dedicated to one or two tasks and its name should give a clear indication about what the rule is all about.  • Include sufficient comments in the rules you write to make understanding them easier for those who will attempt to read and perhaps even edit them later. • Avail yourself of the many good books or on line resources that can help you develop your basic understanding of VB.net programming.  • You certainly do not need to be an expert VB programmer to write rules that do a lot of really valuable and powerful things with iLogic.  • I  am living proof of that! 

13. Best Practice - Don'ts • Don’t try to “boil the ocean” on your first iLogic project.  • Pick something you can accomplish in a single day or less.  • There is a lot you can do and for you to learn about iLogic.  • Don’t write rules that reference ambiguous (default) parameter, feature or component names. • (ie. “if d0 = 1.25 then FeatureIsActive(“feature1”) = false” )  • Something like “if Width = 1.25 then FeatureIsActive(“MountHole”) = false”  makes understanding what the rule is actually doing much clearer and easier to understand. • Don’t change parameter, feature or component names after the rules are written.   • Doing so would cause rules that reference these elements (by their names) to fail because changes to the names are not automatically reflected in the existing rules.  • Don’t start writing rules without a plan. (without really knowing what the rules are) • Don’t write really long rules that could otherwise be broken up into much smaller bite size rules.  • Short rules are much easier for those who didn’t author them to read and understand. 

14. Best Practice - Don'ts • Don’t expect rules to work in a model that you can’t even modify the parameters of manually without it blowing up every time.  • Don’t expect rules to be able to do what you can’t already do manually with inventor.  • Rules must themselves follow Inventor’s “rules”.  • Think of it this way;  rules don’t change how Inventor works but rather what “works” Inventor.  • Don’t use hard coded paths and document names in rules where you could otherwise use relative paths and document names.  • Design paths can change when copies are made, or when file folders are moved.  • iLogic supports methods for defining relative paths and filenames so your “logimetric” models don’t get confused when such things happen. • Don’t put rules in iFeature, iPart or iAssembly factory documents.  • Don’t allow people who do not have the iLogic add-in installed to modify your designs • Rules won’t fire and do what they are supposed to in an Inventor session where the iLogic add-in is not running.