How to add your knowledge

Iv___OccurrencePattern is faster than Child List

    Version as of 17:52, 20 May 2013

    to this version.

    Return to Version archive.

    View current version

    Overview

     

    Consider using Iv___OccurrencePattern designs instead of a Child List rule when you are working with a set of components that are "identical, except...".  You might see a dramatic performance improvement over using Child List rules.  However, there are limitations that may preclude using patterns in your particular situation.

    Key Principles

     

    The following principles provide the foundation for your work with nearly-identical components:

    • "Child List" rules (i.e., using the "Quantity" keyword).  Each child is effectively independent of the others, and can be conditionalized using "child.index".
    • Iv___OccurrencePattern designs use Inventor to replicate components, effectively without creating corresponding Intent parts and rules.

    There are three different "occurrence pattern" designs.  Each will position the components in a particular fashion:

    • IvCircularOccurrencePattern
    • IvFeatureOccurrencePattern
    • IvRectangularOccurrencePattern

    Best Practices

    You would always choose to use one of the "pattern" designs, instead of Child List rule, unless any of the following restrictions apply to your situation.  These situations are common, but sometimes you can structure your application to avoid them.

    • The patterned elements must be exactly the same across the pattern.  There is no provision to make some components different from the rest.  Child List rules allow you to conditionalize the parameters based on "child.index".
    • The patterned elements' position must be described by a circle, a matrix (rectangle), or by following a feature-pattern in a part.
    • The patterned elements must not be referred-to by any other Intent parts.  Note there are some ways to get Inventor-computed information from the elements, but not Intent-computed information.  This restriction is typically encountered in the following common situations:
      • You want to constrain another component to the "nth" component in the pattern.  Note that if you are merely constraining two sets of components to each other in the same pattern, it typically makes sense to only constrain the "parent" components, and then let the pattern replicate multiple components at each "iteration".
      • You want to compute and/or access rule values that correspond to a particular element in the pattern.

    External Links

    This item was mentioned during ETO Potlatch Volume 1.  The "Tips" section is around 30-40 minutes into the video.

    Video:  https://www1.gotomeeting.com/register/676161360