Autodesk Inventor

[#1]

Anyone have experience with nesting phantom iAssemblies within another iAssembly? We are having a problem with the BOM not generating the correct multi-item parts lists. Even though the individual iAssemblies act correctly when viewing there individual BOMs, when these parts are nested inside another iAssembly and switched (Table Replace) between individual items, the BOM shows all dash numbers as the current active one.

Is anyone aware of bugs or unresolved issues within iAssemblies and the BOM?

[#2]

Brian,

Is there anyway that you could share an example file?

Thanks,

[#3]

The problem involves taking an iAssembly part that contains one or two iParts, along with other parts and assemblies.  Now, I have a working iAssembly with a table of various configurations.  This iAssembly is made as BOM set to PHANTOM, because we want the parts to pass up to the next level in the BOM in the next assembly.  At this point, I can create a correct parts list with the different configurations listed (and they output correct qty information).

The problem starts when I go to the next level and create another iAssembly using the first one.  I create another table within this level that uses different configurations of the first iAssembly.  After a few configurations are complete, I check the different configurations within the new iAssembly and they correctly change the parts, but the BOM and parts list show ALL configurations using the ACTIVE iAssembly information (particularly the iParts within), which is not correct.

I'll be happy to send someone the files, but you should be able to recreate this on your own.  It isn't anything special.  If you want the files, where do I send them, because this would involve a few files and I don't want to just post them.

[#4]

I sent you a message. Check your e-mail and please let me know if there is any trouble.

Thanks,

[#5]

Files uploaded to the FTP site.

The iAssembly (Fan-Hood Subassembly) in question is located within the \CAD Library\Adapter\Hood subfolder.  Our intent is to use this one file to place and position a fan subassembly(ies) within a larger assembly.  It is a PHANTOM BOM because we want the parts to show up individually within the next higher assembly.  The problem arises when we try to create the next higher assembly as an iAssembly also (Different size boxes or requirements will use different size fan-hood units).

Note:  These parts are located within a read-only library for our users.

What actually triggered this request was another iAssembly group, but since this one displays the same problem and is simpler to provide, work with this one.

If you open this iAssembly, you can create the correct BOM/Partslist (see attached .idw file).  Then start a new Assembly file and create a new iAssembly using this one as Fan-Hood Subassembly of the parts.  Within the new iAssembly table, make different dash numbers use a different dash of Fan-Hood Subassembly.  Now try to create the same parts list for your new iAssembly.  Doesn't work and the model is very crashy.

Let me know how you make out.

[#6 · Accepted solution]

I've uploaded a file to the FTP site that is a drawing of an iAssembly containing the iAssembly that you uploaded. The top level drawing file is called BOMTypeTest.idw. I was able to create a Parts List that drilled down through to two iAssembly "phantom" levels to the hardware and create a parts list. Can you review this file and let me know if I understand correctly?

Thanks,

[#7]

Thanks for the update.  The thing that confuses me is why the BOM values need to be included the table, and which iAssys need to be included, since none of those values will change through each of the top level iAssembly families.  I did an experiment with and without them in the BOM and the parts list worked as desired.  The funny thing is now I can't recreate the problem I was having with this and another group of files.  I swear on two different iAssemblies I witnessed them list incorrect BOM/partlist info from these IAssemblies when they were placed in a higher level iAssembly (in this case, it didn't matter which part the iAssembly pointed to, the BOM listed only the ACTIVE files for all choices.

We are going to test this again tomorrow and see if the original problem returns or something else crops up.