Community
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Custom iProperty & Exported Parameters Correctly Update in BOM for iParts

Custom iProperty & Exported Parameters Correctly Update in BOM for iParts

We've been doing some testing lately, and discovered that iPart tables (and, presumably, iAssembly tables) with custom iProperty values in them do not correctly update and/or pass to assembly BOMs.  This also occurs when using the "Export" checkbox for parameters that you want to use as a custom iProperty.

 

The specific circumstances that led to this discovery has to do with the custom iProperty being used to call out the length of an extruded part.  We have tested with both exported parameters and a custom property column with the value of the dimension simply typed in as dumb text, both with similar results.

 

To replicate this issue:

  1. Create an iPart with a custom iProperty column, setting unique values to each row in the table.  If you test the table out within the iPart, you can switch to each row within the iPart, and the iProperty appears to change correctly.
  2. Place an instance of the iPart into a normal, empty assembly.  You can even place each of the iPart members into the assembly, if you wish.  Shouldn't matter either way.
  3. Add the custom iProperty column to your BOM.

What you'll likely notice is that the column will not display the correct value.  In our case, it displayed a value of "1", and refused to change to display the value entered into the iPart table.  Placing different iPart members simply resulted in multiple rows of the BOM (due to unique part numbers), but the custom property column displayed "1" for each of those rows, instead of the property value we entered in the iPart table.

 

Again, the property seems to work fine in the iPart itself.  But when you add that iPart to an assembly, this is where the issue comes out.  It's as if it's reading the original value out of the iPart factory file, and not redirecting to the actual iProperty value buried down in the iPart member files.

 

If needed, I can generate a Screencast for this behavior.  I have a feeling this is a limitation of the current coding of iParts and iProperties.  But this doesn't behave as-expected, and we'd love to see this issue updated/resolved.

4 Comments
Anonymous
Not applicable

This is NOT one of those "nice to have" requests. It is something vital that our company uses that just doesn't work, but should be fixed in either a hotfix or the next service pack. It is one of those things that MUST be fixed if we are to continue to use Inventor. We are currently moving from AutoCad to Inventory and if Inventor doesn't work the way it's supposed to work then we can't use it.

Anonymous
Not applicable

Inventor should provide this relatively simple and universally indispensable function.  SolidWorks provides this sort of functionality right out of the box.  

eric_schubert2
Advocate

So, testing this some more, I'm finding that it may not always happen.  Submitting this as a support issue to see if Autodesk can replicate via Support.  But, yes, I agree that this is something that should work.

nickada
Advocate

This is really a bug, and not an idea. For an issue like this, on your AutoDesk Account page, click on the ? then on 'Contact Support'. You can then submit your issue by email, but I prefer  phone support. A technician will call you and you can make sure they understand both the issue, and how problematic it is. you can share your screen with the tech using AutoDesk TeamViewer. If the help desk can't fix the issue, they will initiate a support case.

 

This way you can explain your issue to an AutoDesk employee, and impress upon them how big a problem the issue is to you.

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Autodesk Design & Make Report