Autodesk Inventor API - Object Model

Recently, a friend (and colleague) asked me how I go about planning the development of a new application or customisation project. He already has a pretty good handle on code structure and syntax, but struggles to know where to start in actually bringing his idea to life. In his words, he suffers from “the worst kind of writers’ block.” I totally sympathise with this issue as I have the same problem myself, quite frequently. The truth is, unless I’m working on a commercial project that has been carefully scoped, budgeted and scheduled, most of the time I just ‘hack’ something together. Having said that, there are definitely a couple of tips and tricks I can share which should help novice coders get started with customising Autodesk Inventor. If there is enough interest, I could do a similar article on the Vault equivalent.

I’m going to split this up into a couple of categories:

  1. Interrogating a live document to learn from and capture information
  2. Writing pseudo code to figure out the ‘flow’ of your program

Interrogating a live document

Usually when I start working on a customisation job, I only have a rough idea of what I want to achieve. With a limited mental picture of how the finished tool may look, often the only thing I know at the start, is the rough area of Inventor I’ll be working with. For example, if I’m building a tool to ensure that the designer fills out all the appropriate metadata for a model, I know straight away, that I’ll be working a lot with iProperties.

Autodesk Inventor API Documentation

API Documentation for Autodesk Inventor

To find out more where these objects are stored, and how they interact with other objects, you need a reference. The API documentation for Inventor, while thorough, is pretty dry to read and can be difficult to navigate if you’re unfamiliar with it. By using the little trick below however, you can see the API objects in a live document, populated with real data, which makes it a lot easier to understand. Let’s say, for example, you’re looking for the “Work Point” object that represents the origin of a particular part. Now of course can go into the model browser and find it, but what if you want to access it programmatically, where does it live in the structure of the model document? Watch the video below to see how to get this information quickly.

[youtube]Interrogating the Open Document in Inventor VBA Environment

The API is a complex beast, with a lot of objects, and a deep structure. To give you a head-start, the table below lists a few of the objects and collections that I use most often.

Object / Collection Contains
Document.ComponentDefinition Parameters / Constraints / Work Geometry / Occurrences / Mass Properties
Application.Documents File Operations (Open, Save etc.)
Document.Materials Materials
 Document.PropertySets iProperties
 Document.ReferencedDocuments Document References


Before diving in to the actual code, I find it is often helpful to design the logic and flow of the program by using diagrams like flowcharts. Additionally, writing out the decisions that need to be made, in plain English, can help get things clear in your head. Writing pseudo code allows you to get the structure down quickly, without worrying about the syntax and intricacies of the programming language that you will be working in later. So what is pseudo-code exactly, you may ask? I’ll try to explain with an example.

Let’s say that we have a model of a box, whose length can be manipulated. Additionally, it’s colour is dependant on it’s length. Short boxes are red, medium ones are yellow, and long ones are green.

  • Maths
    • Length < 150mm — Red
    • 150mm <= Length < 250mm — Yellow
    • Length >= 250mm — Green
  • Plain English – If the length of the box is less than 150mm, then make it a red colour. If it’s length is between 150mm and 250mm, then make it yellow, and if it is longer than 250mm, then make it green.
  • Pseudo-code



  • Actual code ( for example)

VB Code

Hopefully these techniques give you some confidence to get stuck in and try your first Inventor customisation project. While I’d suggest you begin with iLogic rules and forms, sometimes you hit a wall with iLogic’s scope, and you need to delve into the API to access the areas you want to work with.

’til next time…