iProperties, Used Properly
Every Autodesk Inventor® file has a set of properties called iProperties. We use iProperties to track and manage files, create reports, and update bills of material, parts lists, title blocks, and other information automatically. Some iProperties are automatically set, such as Part Number and Author.
During a transition from AutoCAD® to Inventor some users get lost in the proper utilization of iProperties in their design tracking. Common problems that arise tend to be incorrect information in parts lists and seemingly repetitive input of the same value in different areas of tracking. If not managed correctly, this can snowball into very poor reporting of critical information to the design process.
In this article we will take a look at the diagnosis, treatment, and preventive maintenance an organization can perform to ensure they are using iProperties effectively and making their data searches more productive.
Diagnosis
Let’s say we have a few iProperties we need filled out in every drawing for our Title Blocks and Bills of Material. These can consist of standard iProperties as well as custom ones we create since Inventor may not ship with the terminology or content we require for our documentation.
If these values do not get filled out initially, we often spend time afterwards opening files and correcting them. In some cases draftsmen and engineers may take the short cut and override these or simply add text on the drawing. This is a horrible practice because these overridden iProperty values persist only in the edited drawing, even though that component may be used in 50 other assemblies. We certainly do not want that attitude in our design group because items will no longer update the way we intend and expect them to. Making simple typographical errors or incorrectly cross referencing a file can lead to manufacturing mistakes and incorrect part orders.
First let's see if your designs have problems right now. After we find out there is an issue, we can correct them for legacy designs and put in safeguards so it doesn't happen again. Open a completed assembly drawing containing one of your designs with a Parts List on it. Right-click on the parts list and choose Edit Parts List. Now look at what is going on in the Parts List Dialog.
The blue text represents overridden properties. Now a little bit of blue text here is not a bad thing. If we need to specify overrides for a part in a special case, then this blue text is okay. If we require that these values be the same in every drawing where this part is referenced, then this is a VERY bad sign. To check the actual iProperty value for a cell, simply right-click on the cell and toggle the Static Value option. If it is blank, then the actual part or assembly file does not contain the information. If the cell returns a value that isn’t correct, then the problem could be worse than we thought.
Incorrect data can be more costly than adding an additional inch to an extrusion due to incorrect ordering, freight involved with shipping, and returning the items whether it be a purchased part or incorrect raw stock. We hope that our purchasing department sees these mishaps before that happens, but even if they catch it in time, there is still downtime involved with the mistake, and egg on your department's face.
With the blue override in place it also makes it harder to search for that value in any other design using either Design Assistant or Autodesk® Vault. Data that doesn't exist in the iProperties cannot be indexed and, therefore, is not searchable.
Treatment
After identifying the overridden property and switching it back to the linked value by toggling off the Static Value, the best course of action is to return to the source file and correct the data in the original part or assembly.
There are actually a couple of different ways to get back to the source.
- Right-click on the modeling file in canvas.
- Right-click on the file in the browser.
- Use the Bill of Material.
The first two methods are a little tricky if you don't know your design intimately. In order to find the file in the drawing model browser, you have to know exactly where it is in the hierarchy of the design and will involve some digging through some expandable nodes.
If you have knowledge of what the component looks like, then you can also open from the canvas by selecting it and picking Open.
“But my cursor doesn't select parts in my drawing, just faces and edges.” Well, here is another free tip: hold Shift and right-click your mouse; this will cause your Selection Filter to pop up and allow you to change the priority of your drawing selection for your left click.
Perhaps the easiest way to fix these problems with the iProperty metadata is to force the update right from the drawing instead by using the Bill of Materials. This command is one of the most powerful for tracking data in a design and allows for quick changes across the file set without having to open every file or having to hunt down the correct file in a list or model tree. There are two ways to get to it in a drawing—right-click on the Parts List, or right-click on the Assembly or Presentation View in the drawing.
Once inside the Bill of Materials, you can customize the columns, change the BOM structure, add new iProperties, modify material properties and, for our purpose, change any data that is linked from the modeling files.
And, just because I don't spend ALL day in my CAD package, I do forget to turn on the CAPS lock key. It is awesome that right-clicking on a cell contains the option to capitalize for me plus some other Excel-type functions such as Find, Replace, and Cell Fill.
A quick check on our Parts List will verify this is a linked value and not a static one and our last step to treat our metadata mishap is to save the drawing and approve the change to force the update and save the linked modeling file.
Preventive Maintenance
Now that we have identified our problem, treated it, and know the dangers involved with the incorrect fudging of data, how can we increase our productivity with the software and avoid missing data fields and taking the easy way out? There are actually a couple of options here: free or purchased add-ins.
So what is the best way to make sure your design team is filling out the data required for your tracking? Some methods could be as simple as education for the team or a process document that shows how the iProperties are utilized in your company and which ones are mission critical to fill out. However, even this management method doesn’t remove human error. Is there an easier way to automate what gets filled out and something to watch dog our designs to ensure we are correctly getting the data we need?
Let’s try some simple iLogic. There is some new stuff in 2012 that really opened up the ease of use for standardizing iProperties and creating easy user input screens.
First off, here are my source files that make this work. There is a decent starter drawing template as well as some free coding included. I just added them to my template directory so I have a new Tab in my New File screen.
http://blogs.rand.com/files/sample-templates.zip
What we have in these templates is a few custom iProperties and settings that help us track our design (AS400DESC, Item Number, Category Number, and Drawing Number). In addition, there is a Rule that will take whatever we put into Description to automatically populate the Part Number, instead of the default Inventor method of making the Part Number equal to the File Name.
Disclaimer: This might not be your way of tracking or incorporate the same properties you use, but you can adjust based on your company’s needs.
Let's start by looking at the existing rules in the Part file. Go to the Manage tab and select the Rule browser. There are only a few (but very potent) rules here.
Let's look at how these rules fire. Click the Event Triggers command to examine. Here I used Before Save Document because it works better with Vault during the Check in and out protocols. I also have iProperty Change firing another rule to make my Part Number equal to the Description so when Description is changed the Part Number follows suit.
So when does the iPropertyEnforcement fire? To find out, examine the iPropertyTriggering rule by right-clicking on it and selecting Edit Rule.
In this rule if any of the values are empty (signified by the empty quotation marks) then the iPropertyEnforcement rule will automatically fire upon trying to save and leave the file. So what's in the iPropertyEnforcement rule? What has five fields and keeps us tracking our data?
This guy...
iLogicForm.Show("iProperties")
This form is created with the new iLogic Form creator that was added to Inventor 2012. To examine this sample form go to the Form tab in the iLogic Rule Browser, right-click on iProperties, and select Edit. These forms can be created and stored locally in a file or stored externally as Global Forms.
If you are using Inventor 2011, this form creation isn't impossible—it’s just harder to set up and very time consuming if you don't already know how to create a VB form outside of Inventor. You could also use the InputListBox in iLogic, but you would need one for each of these fields.
To examine the iProperty tracking further we head on to the Drawing sample I have provided. In that drawing file there are a couple different rules. Here we only have one particular rule: iPropertyCopying. The idea here is to get the values from the original modeling file to be copied directly over to drawing environment not only for Title Block mapping, but also for indexed Vault searches. Normally, during a Vault search it would only return the modeling file, but with this copying it will return both the modeling file and the drawing file since the iProperties are synced.
The single rule here will fire upon Drawing View Changes and Before Save Document and contains logic to not fire if values are already copied correctly or if no view exists.
If the file that has been placed in the drawing is missing any of the required information, a prompt will open stating that the user must return to the original file to make changes to the iProperties so they will copy over correctly for Title Blocks as well as Parts Lists.
This iLogic rule for duplication of the iProperty data to the drawings from the model also ensures that when you search in Vault for the metadata, it will return the modeling file as well as the drawing and that they always stay in sync.
If you receive an error when this rule runs, then you will see a potential downside to this usage. What if the source file didn't come from our team and therefore did not contain any of the custom tracking parameters? Or perhaps it is an older migrated file before we figured out what we wanted to track.
Well, you have three choices. Add the values to the source file, suppress the rule so it doesn't annoy the user, or process your rules to your old files (there is some free code out there to do that). I prefer the first choice and the Design Assistant is an easy way to Copy Model iProperties from a single source file to a series or entire folder of files so they can be tracked correctly. You can also use Vault to force a parameter to exist when it doesn't already.
Other Ideas for Forms
With the aforementioned example we worked through, it assumes we use data tracking from the model to populate title block and drawing properties. But what if we do all or a majority of iProperty usage through the drawing and not the modeling files? What about values that we fill into title blocks?
There are two ways of filling out title block fields, iProperty and Prompted Entries. What’s the difference between these? From an AutoCAD perspective:
- Inventor iProperties are equivalent to AutoCAD Drawing Properties (DWGPROPS)
- Inventor Prompted Entries are equivalent to AutoCAD Block Attributes (ATTDEF)
Based on this precursory knowledge that a lot of transitioning users have about AutoCAD, they almost immediately start creating Prompted Entries for the Title Block since it is a similar method to how things are done by the majority of AutoCAD users.
It seems to be a well-kept secret in AutoCAD that DWGPROPS and the use of FIELDS are the best way to populate a Title Block in AutoCAD. When companies find out about this method of Title Block population, it is usually too late as they might already have created a large number of legacy drawings using attributed blocks. This usually becomes apparent when companies start looking at data management solutions. Some of these programs have a very hard time working with attributed blocks. Autodesk Vault is perhaps the most skilled at this, but others are not that well integrated.
When data management systems index metadata of files they can inherently read the properties of a file, whether it is MS Word, Adobe, Inventor, or AutoCAD. This makes searching for any data in the data management system very easy and greatly speeds up the design process by circumventing the opening of a large amount of files to find the correct one.
In order to have this functionality you must use iProperties in your template. Prompted Entries will not be searchable. Moreover, they can control the same information across multiple layout sheets, so if the information is the same in seven layouts, then the user does not have to change the attributed Title Block seven times; rather it is changed only once in the DWGPROPS. This will work the same way in Inventor across multiple sheets in a drawing, compared to inputting the same information in prompted entries over and over again.
Now if this is our method of input, why don’t we just go all in and make an all-inclusive form for inputting our values that will fill out our iProperties?
Armed with this knowledge about iProperties and some of the tips and tools presented here, we can make our designs easier to locate and more accurate in tracking of important data for reporting and procurement of materials.
John Evans is an Autodesk Certified Inventor Professional . He provides technical troubleshooting at Gustin, Cothern, and Tucker, Inc. He works as design consultant and author from his company John Evans Design and manages the blog "Design and Motion." He can be reached at john@johnevansdesign.net
