Inventor Model I was attempting to create some additional flexibility in a Top-Down Design by adding adaptability. Some of the design community was wondering if I’ve become unstable, and after countless hours of troubleshooting, I am now wondering the same thing.

Short Version

Concept – Incorporate child influenced adaptable features into the base skeleton file of a Top Down Design

Assessment – Not gonna happen.

Results – Corruption

Details – The Inventor history based, derived design parts are looking for updates while trying to adapt their information source, creating a conflict, and ultimately resulting is various corruptions.

Solution – Design with adaptability in mind, but farther down the line

Rest of the story

Though the attempt was a failure, I learned some things that I would like to pass on.

Top Down Background

A Top Down design is dependent on a configuration of one or more simplified Base Skeleton Files that distribute basic information to an entire design. The Base Skeleton is never dependent on any final parts and never refers to information or constraints from components that are derived from it. A parent can never be dependent on it’s children. This project was akin to a parent being dependent on one of it’s children’s friends.

The Project

I am modeling a Mill Head Riser that was created to add substantial stability and clearance to an existing vertical mill. The application had never been tested or refined, and I thought it would be a cool project. The model incorporates the following features:

  • A Top-Down design skeleton to easily adapt features and form to future design improvements
  • A Chain Drive design accelerator with unknown axis offsets
  • A motor of unknown size and power

Adaptable Skeleton Concept

In the list above you should see that there are variables that are unaccounted for at the beginning of the design. A motor and chain drive are key in the overall design. Since we do not know how the design will fare, we need it to be somewhat flexible in use and application so that Stress analysis, Simulation, and Design Accelerator results can be easily incorporated in the design.

From my perspective, the farther I traveled into the design, the more it bugged me that I would have to return to the design skeleton and manually edit dimensional constraints, and then tweak things to make the assembly fit the Design Accelerator. 

It should be able to compensate, it’s a Design “Accelerator”!!

Motor Mount     image

Constrain the Sketch, Not the Component

So I attempted to add an adaptable sketch into the base skeleton, and have that adapt by virtue of the assembly constraints:

  • Motor part to Skeleton Mount Bolt Pattern sketch – this would spread the pattern
  • Chain Drive (DA) axis to Skeleton Mount Bolt Pattern axis – this would adapt the chain drive offset

I determined rather quickly that the key to success (or so I thought) would be to avoid the downhill component update problem by attaching straight to the adaptive skeleton sketching. Then when the constrained mount bolt patter changed, the sketch would adapt, and hand down the changes to the dependent parts. We would not constrain to the mount plate component, but instead to the placed base skeleton sketch.

Adaptive parts in Top Down Design Chart

It Worked !!

As soon as I attached the motor, the gearbox subassembly updated beautifully !!!! Then came the chain drive offset constraints. 

It Died

As you might expect I tried everything. No joy.  So I removed the motor, and started over. All adaptability was shot. The results were inconsistent. In some cases I found the Base Skeleton File’s adaptable bolt pattern sketch to be jammed. That’s right, jammed. The lines that should have indicated DOF were colored as if they had none, yet there were no such dimensional or geometric constraints.  I turned off adaptability, but no luck.

In some cases lines had become constrained at the end of other lines when they crossed as if during the adaptation they crossed paths and locked. Very odd reactions.

What Happened?

The simplest method I can use to describe the condition is that the sub-assembly contains not only the child parts, but ALSO the PARENT skeleton. The sub-assembly is updating the parent at the same time it is updating child components within itself.  This workflow is not expected and not part of the Inventor API.

The Solution

The solution was really easy. I determined that having the bolt pattern in the base skeleton file was not all that important to the design. A primary and subordinate instruction set was required.  I cut the motor bolt sketching and pasted it into the already derived mount plate part file down the line.

 Adaptive Mount Plate  Adaptive Mount Plate

The mount plate derived its instructions from the base skeleton file, except for the motor bolt pattern. That was pasted into a new sketch in the derived part, and then constrained to the derived centerline.  A work axis was constrained to that sketch’s motor shaft axis. That new sketch (MountPattern) was made adaptive, and so was the mount plate (plate 5) in the sub-assembly.

   Constrained Motor to Mount  Constrained Design Accelerator


The result was the part updates perfectly when any bolt pattern is constrained, and the entire bolt pattern moves along the centerline plane when constrained to the chain drive Design Accelerator. When I edit the Design Accelerator, the Mount Plate (Plate 5) automatically updates.  Now that’s sweet.


While the thought that ‘it should have worked fine’ was present, Inventor does not agree. I tried an unorthodox workflow to see what happens, and found why it is not employed. Because it does not work.

I was warned by a good friend ( 😛 )that this was a bad idea, at the very least from the stand point that the workflows are two separate procedures and thought processes, and should not be mixed within the same operation.  While I acknowledged the warning, I was determined to see it through and to see it work. And I did see it work, and then watched it fail.

Having adaptability in a base skeleton part is not a bad thing per se, but only if that adaptation comes from up above. Having derived children partially involved in the adaptation process is bad mojo.

Sometimes solid foundation workflows are there because they work better.