Save
Following the post on Autodesk Vault and Inventor Configurations, I had the privilege to test some of my theories and new workflows during several hands-on advanced Data Management Workshops here in the Novi office. These workflows were well received, and I think its time to share these with the Vault community. First, we’ll talk about standard – not custom – iPart workflows.
iPart Basics
Let’s start with a review of the basics. Inventor iPart Members get their values from a table (MS Excel) within the Factory file. This includes a variety of data like parameters, properties, feature suppression, work features, etc. Another way to look at this is tabulated drawings, but in a 3D representation. All of this is designed to configure the Member file to a pre-defined configuration upon placement within the context of an Assembly, thus conforming to standards. Finally, the file format for iPart Factories and Members alike is .ipt, and Yes, Vault recognizes and knows the differences.
Now, if you’ve ever examined a generated iPart Member, you’ve noticed that this file isn’t meant to be modified directly. The usual part editing tools are not available, and this is by design. In other words, the files are ‘locked’ in their chosen configuration.
You could also say that the member file is set/frozen/released etc. Given that fact, my first suggestion is to leverage the Document Management behaviors and set these files to a Released state.
iPart Categories
In an effort to automate this ‘released’ behavior, we’ll create two new Categories: Configuration Member and Configuration Factory.
Assigning Lifecycle Definitions
Once the Categories are established, you can assign them to either existing Lifecycle Definitions or create new ones. For my example with Configuration Members, I am using the Simple Release Process which I’ve used with Categorizing Content Center Files in Vault. You can also create your own Lifecycle Definition specific to Members with unique state names. The important step here is to modify this Lifecycle Definition to default to the Released state, and this will provide the security that matches our needs for generated iPart Members immediately upon check in to Vault.
The Configuration Factory Category on the other hand can be assigned to another Lifecycle Definition that doesn’t default to Released, and has more Lifecycle states.
The Basic Release Process is suggested here as it has the Obsolete state, which is useful in the event you retire an iPart in the future. This will ensure that user will not place it within an assembly, yet keep a record of it in Vault.
In the next post, we’ll examine Revision Schemes assignment on Configuration Members and Factories within Vault. Stay tuned….
-Brian Schanen
