Hi All,
I am working on an I-Can't-believe-it's-not-iLogic solution for a customer problem and have run across a glaring limitation with the Inventor Bill of Materials itself.
If I open the (Structured View-All levels) BOM within Inventor 2015 I see the following:
Wherein the parent correctly displays a quantity of 4, and I suppose is correctly displaying a quantity of 1 for the sub assembly.
The other thing that is odd and I assume by design is that exporting the Bill of Materials gets me the same result, it shows exactly what you see above, not the actual total of the (item numbered 111.15.2 above) within the assembly. Another glaring omission is the inability to do any filtering or searching within the BOM interface.
If there isn't already an Ideastation post on this, then I plan to make one.
The problem also affects the Bill of Materials Structured view if I query it with the following piece of code:
Private Function QueryBOMRowProperties(ByVal oBOMRows As BOMRowsEnumerator) As List(Of BomRowItem) Dim tmplist As List(Of BomRowItem) = New List(Of BomRowItem) ' Iterate through the contents of the BOM Rows. Dim i As Long For i = 1 To oBOMRows.Count ' Get the current row. Dim oRow As BOMRow oRow = oBOMRows.Item(i) 'Set a reference to the primary ComponentDefinition of the row Dim oCompDef As ComponentDefinition oCompDef = oRow.ComponentDefinitions.Item(1) tmplist.Add(getRowItem(oCompDef, oRow)) If Not oRow.ChildRows Is Nothing Then tmplist.AddRange(QueryBOMRowProperties(oRow.ChildRows)) End If Next Return tmplist End Function
This returns a total count within the parent assembly of 3 per parent assembly - which in turn gives me a total of 9 for the overall assembly (As this item is used in other places) when in fact the total calculated by legacy means should actually be 18.
I had just tested the following amendment to the above snippet whereby I check for the quantity of each oRow and loop through my QueryBOMRowProperties function that number of times to return the correct result:
Private Function QueryBOMRowProperties(ByVal oBOMRows As BOMRowsEnumerator) As List(Of BomRowItem) Dim tmplist As List(Of BomRowItem) = New List(Of BomRowItem) ' Iterate through the contents of the BOM Rows. Dim i As Long For i = 1 To oBOMRows.Count ' Get the current row. Dim oRow As BOMRow oRow = oBOMRows.Item(i) If oRow.ItemQuantity > 1 Then For itemqty As Integer = 1 To oRow.ItemQuantity 'Set a reference to the primary ComponentDefinition of the row Dim oCompDef As ComponentDefinition = oRow.ComponentDefinitions.Item(1) tmplist.Add(getRowItem(oCompDef, oRow)) If Not oRow.ChildRows Is Nothing Then tmplist.AddRange(QueryBOMRowProperties(oRow.ChildRows)) End If Next Else 'Set a reference to the primary ComponentDefinition of the row Dim oCompDef As ComponentDefinition = oRow.ComponentDefinitions.Item(1) tmplist.Add(getRowItem(oCompDef, oRow)) If Not oRow.ChildRows Is Nothing Then tmplist.AddRange(QueryBOMRowProperties(oRow.ChildRows)) End If End If Next Return tmplist End Function
Using the above snippet, at first glance the result seemed to be bang on what we were expecting, but then we noticed that some items which should only appear 4 times were appearing 19 times so something is amiss with my amendment above.
Now I am left with having to consider querying every occurrence and sub-occurrence within my parent assembly to calculate the correct totals for items, or is there a simple fix I have overlooked to the parts themselves, something that will make the part that is appearing once actually appear three times?
So all in all, it's been a very confusing day so far.
Thanks,
Alex.
PS. none of these missing parts are set to referenced or phantom etc. <- I already checked that because @salariua asked me earlier.
Solved! Go to Solution.
Solved by LukeDavenport. Go to Solution.
Solved by AlexFielder. Go to Solution.
Alex, I think this IS by design, and with my limited knowledge of this assembly, correct. I am assuming that ineach sub-assembly there is only one of that part? The BOM reflects that there are (4) sub-assemblies, each one of which contains (1) of these parts. This is the right way to show it. If it showed a quantity of (4) on the part at the subassembly level, that (4) would then need to be multiplied by the (4) instances of the subassembly... giving you (16) of those parts. I'm fairly certain this is normal behavior for an indented BOM.
Chris Benner
Inventor Tube & Pipe, Vault Professional
Cad Tips Tricks & Workarounds | Twitter | LinkedIn
Autodesk University Classes:
Going With The Flow with Inventor Tube and Pipe | Increasing The Volume with Inventor Tube and Pipe | Power of the Autodesk Community | Getting to Know You | Inventor Styles & Standards |Managing Properties with Vault Professional | Vault Configuration | Vault - What is it & Why Do I Need It? | A Little Less Talk - Tube & Pipe Demo | Change Orders & Revisions - Vault, Inventor & AutoCAD | Authoring & Publishing Custom Content
I'm a bit stumped. I can't see the problem in your description or the images you've supplied. The two highlighted iam's are different. Does 111.15.2 exist in other sub assemblies like 111.15?
Scott Moyse
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Design & Manufacturing Technical Services Manager at Cadpro New Zealand
Co-founder of the Grumpy Sloth full aluminium billet mechanical keyboard project
I better understand now your situation and I must say that the BOM seems correct to me, it would have been more confusing to show total quantity for each child part/subassembly. following me....?
I know using BOM to Parts Only will not help you because you need to check quantity for subassemblies as well.
Can we ask what is the final goal of your ilogic? What are you trying to achieve? Maybe we can work around it.
If it’s just a report then maybe this will help?
http://blog.ads-sol.com/2014/06/parts-list-with-thumbnails.html
Hi @scottmoyse, yes it does appear in other assemblies.
This job is for a seating arrangement and can be explained thus:
I have an assembly 1 unit wide by 4 rows deep.
The rear row doesn't use the offending assembly at all.
Each remaining row includes a left and right hand assembly which has our sub assembly within it making a total count per row so far of two occurrences.
Each of the remaining three rows also includes 4 "standard" assemblies each including one occurrence of the assembly shown as item 111.15.2 so this should equal six occurrences per row for a total of eighteen occurrences overall.
The by-design problem is that the structured view (all levels) doesn't account for the three extra physical occurrences.
I've never noticed this before now because normally this would be taken care of with a parts list on a drawing.
They need Vault Pro
Scott Moyse
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Design & Manufacturing Technical Services Manager at Cadpro New Zealand
Co-founder of the Grumpy Sloth full aluminium billet mechanical keyboard project
Hi @salariua I don't think the Bill of Materials is incorrect either, I'm just trying to grasp how I can achieve the desired report whilst still using the Inventor API.
And (As I just saw it pop up in my email) I agree with you @scottmoyse that they could probably do all of this with Vault Pro.
I guess I need to query every occurrence in the assembly and subassemblies adding them to my partslist as I go.
I'm not sure I uderstand correctly what you need exactly, but if I did, then I think the simplest code would be to iterate through all the occurrences/suboccurrences in the assembly and then keep a list of all the ComponentDefinition objects with a number saying how many times you ran into them. It could be optimized, but would do the job.
Hi Adam,
That's exactly the solution I have implemented:
''' <summary> ''' Queries all the occurrences in the assembly because the Bill of Materials can't be trusted to present the correct quantities of items in sub assemblies. ''' </summary> ''' <param name="activeDocument">The document we wish to parse</param> ''' <returns>Returns a list of BomRowItem objects</returns> Private Function QueryAssemblyOccurrences(activeDocument As Document) As List(Of BomRowItem) Dim tmplist As List(Of BomRowItem) = New List(Of BomRowItem) Dim oCompDef As ComponentDefinition If TypeOf activeDocument Is AssemblyDocument Then Dim assydoc As AssemblyDocument = activeDocument oCompDef = assydoc.ComponentDefinition If Not assydoc.FullFileName = InventorApplication.ActiveDocument.FullFileName Then tmplist.Add(getRowItem(oCompDef)) End If For Each occurrence As ComponentOccurrence In assydoc.ComponentDefinition.Occurrences If TypeOf occurrence.Definition.Document Is AssemblyDocument Then Dim subassydoc As AssemblyDocument = occurrence.Definition.Document oCompDef = subassydoc.ComponentDefinition tmplist.AddRange(QueryAssemblyOccurrences(subassydoc)) Else Dim partdoc As PartDocument = occurrence.Definition.Document oCompDef = partdoc.ComponentDefinition tmplist.Add(getRowItem(oCompDef)) End If Next Else Dim partdoc As PartDocument = activeDocument oCompDef = partdoc.ComponentDefinition tmplist.Add(getRowItem(oCompDef)) End If Return tmplist End Function
There might be an optimisation I have missed, but on the whole the above works better than querying the Bill of Materials.
Thanks,
Alex.
Alex,
I haven't read through all this in detail, but if you are simply after the total summed quantities of each occurrence in the entire assembly, whether in sub-assemblies or not, then the Parts Only BOM will do this for you. Any children components are 'promoted' and merged, no matter how deep in the assembly.
I notice Adrian mentioned this above. What is the reason you can't use 'Parts Only'?
Ah I just read it properly and I think I understand. You want total summed quantities for sub-assembly files AS WELL as the part occurrences they contain? That strikes me as a strange requirement for a bill of materials format!
Anyway, I think you need the ComponentOccurrences.AllReferencedOccurrences Property of the top level assembly occurrences collection. Check the help files. It'll do all the summing for you for each component definition you use it with, and it'll be faster than looping through every occurrence. To get all the component definitions in the whole assembly you need to loop through AllReferencedDocuments.
Hi Luke,
That's exactly the problem. If it was just Parts I needed to count, the Parts-only option would have worked just fine.
And I agree, it is a strange requirement for a Bill of Materials format, but is driven by the customer specification; basically they use a custom true/false iProperty to determine whether a Sub-assembly/part appears on a so-called "fabrication list".
Thanks for the tip on the ComponentOccurrences.AllReferencedOccurrences Property, I'll be sure to take a look when I am back at the customer site this week.
Cheers,
Alex.