Problem with BOM api calls on assembly with Level of detail other than master

[DWhiteley]

These calls fail if the assembly LOD representation is set to anything other than MASTER. 

' Set the structured view to 'all levels'
oBOM.StructuredViewFirstLevelOnly = False
' Make sure that the structured view is enabled.
oBOM.StructuredViewEnabled = True

'oBOM.PartsOnlyViewEnabled = True
oBOMView = oBOM.BOMViews.Item("Structured")

Inventor 2018.1.2

Is this a known issue?

Dave

Envisage UK Ltd

[pball · Accepted solution]

I can't say if it's an issue or just designed that way, but I have run into that.

If you need to run this code in a different level of detail I don't know what to say. If you are ok with switching the master to run this code I did the following which prompts the user if they want to switch to master and run or exit.

        Dim oDoc As AssemblyDocument = ThisApplication.ActiveEditDocument

        If (oDoc.ComponentDefinition.RepresentationsManager.ActiveLevelOfDetailRepresentation.Name <> "Master") Then
            If (MsgBox("Master level of detail not selected." & vbNewLine & "Click Yes to switch to Master LOD or No to cancel.", MsgBoxStyle.YesNo) = MsgBoxResult.Yes) Then
                oDoc.ComponentDefinition.RepresentationsManager.LevelOfDetailRepresentations.Item("Master").Activate()
            Else
                Me.Close()
                Exit Sub
            End If
        End If

Update:

There are other threads on this exact issue. The consensus is that the BOM can only be accessed in the main level of detail. Search up the other threads if you want to read more about it.

[DWhiteley]

Nice one! Many thanks

[frederic.vandenplas]

What i did , is loop through the assembly and set all supressed parts a reference, switch to master and loop the bom, quantities are correct and tv en switch back to lod and revert the reference state, quite a challenge but it Works!

[jjstr8]

I would consider this a bug.  The BOM command from the ribbon bar doesn't seem to care about suppressed parts, so why should the API.  

[C-Hoppen]

Why ist this thread marked as solved???

The problem still exists even in Inventor 2020. If I call the BOM with a user defined LOD, BomRow.ChildRows are always nothing/null. Even when BomView is "Model" (Bom.BOMViews[1])

Is there any useful solution?

Thanks,

Christoph

[Anonymous]

Perhaps it is a bug or is intentional due to other programming complexities. This code works well to change LOD to master and back to whatever LOD was originally set.  I use this in my BOM export codes and it works great. I have over 18 staff that use the bom export codes that has this embedded in it:

'To Get the ActiveLevelOfDetailRepresentation Name

                        Dim MyLOD_Name As String

                        MyLOD_Name = odef.RepresentationsManager.ActiveLevelOfDetailRepresentation.Name

                        If Not MyLOD_Name = "Master" Then

                        'activate master because only it can enable access to the BOM

                            Call odef.RepresentationsManager.LevelOfDetailRepresentations.Item(1).Activate

                        End If

'To set your LOD back to original

    odef.RepresentationsManager.LevelOfDetailRepresentations.Item(MyLOD_Name).Activate

[pball]

@C-Hoppen 

Level of Details were designed as memory management tools, not as configuration tools. That is most likely why the BOM cannot be accessed in anything but the main LOD. It wasn't designed that way.

[C-Hoppen]

Thanks. My intention was not to configure the BOM by LOD. I just wanted to query the BOM regardless what LOD is  activated....

Why can I call the BOM from the UI with any LOD, but the API fails? 

Regards

Christoph

[Anonymous]

I think I understand your wanting to query the BOM. But why can't you use the code to change LOD to Master level while you query and then back once you are done with the query? I know, a work around as usual.

Almost all my macros that I have created are work around for one or another wall that is in place. Its like a maze game with hidden clues.

[jjstr8]

---

@pball wrote:

@C-Hoppen 

Level of Details were designed as memory management tools, not as configuration tools. That is most likely why the BOM cannot be accessed in anything but the main LOD. It wasn't designed that way.

---

The point being made is that the UI BOM doesn't care what the LOD is set to, so why should the API access?  I agree with what you're saying about the purpose for the LOD, but the BOM is separate from the LOD.

[C-Hoppen]

---

@jjstr8 wrote:The point being made is that the UI BOM doesn't care what the LOD is set to, so why should the API access? 

That's the point! The UI BOM doesn't care what the LOD is set to. But the API does! Any access to the BOM object fails if the LOD is not set to "Master".

[BrianEkins]

I don't have any inside knowledge about LOD's and the BOM but have run into this issue myself on a project I'm working on.  One thing that's interesting is that if you open an assembly with a lot of LOD's active and look at the numbers in the lower-right corner of the Inventor window.  The second number is the number of documents currently open.  When I run the BOM command, this number jumps up and when I exit the command it goes back down. 

When a part is suppressed that document isn't loaded, but to create a BOM Inventor needs to get information from that document.  Apparently it's opening the document independently of the assembly to get what it needs and then when you close the command it closes the document.  The command is playing these tricks to allow it to work with any LOD.  The API could certainly be enhanced to do something like this but it would need a way to know when you're done so it can close the documents.  I would be a little concerned about a very large assembly with a lot of active LOD's. 

[C-Hoppen]

---

@BrianEkins wrote:

When I run the BOM command, this number jumps up and when I exit the command it goes back down.

---

Brian,

I have never noticed that, but it explains everthing.

---

The command is playing these tricks to allow it to work with any LOD.  The API could certainly be enhanced to do something like this...

---

Would be great to have the ability to open (all) the documents independently from the LOD. Because its a time difference to open some files or switch to LOD "Master" in huge assemblies.

I could write my own BOM funtion, but calling the BOM is much more faster than reading all iProperties for all occurrences. Why is reading iProperties such slow...?

Regards

Christoph