Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Multilevel BOM Callouts in Drawing not working. What am I doing wrong?

StephenGStephenG Member Posts: 369 ✭✭✭
I have a simple multi-level structured BOM that is doesn't want to create proper item # balloon callouts in a drawing.





BOM items 2 though 4 callouts are not getting their item balloon numbers.

Not sure want I am doing wrong. Would appreciate some guidance.


Answers

  • PrachiPrachi Member, OS Professional Posts: 262 ✭✭✭
    Try inserting BOM as structured multilevel.

  • StephenGStephenG Member Posts: 369 ✭✭✭
    There appears to something going on in the drawing that is causing the unresolved (red) balloon items. The problem drawing in question is a multi-sheet drawing with a mix of sheets documenting individual piece parts, a sub-assembly, and the top level assy. Problem is with this particular drawing, not the sheet, since creating a new sheet in this drawing tab/member exhibits the same problem.

    I created a new drawing tab/member and the issue disappeared. Initially, I thought it might have to do with the view referencing an explode state and that there might be a bug in OS, but this does not appear to be the case.  

    Did some additional experimentation and the only way I found to get an unresolved (red) balloon item is to change the Explode/named position such that the arrow pointing to the item geometry is no longer rendered in the view (obscured by other overlapping geometer.)  This behavior makes sense.  
  • PrachiPrachi Member, OS Professional Posts: 262 ✭✭✭
    The only time I've seen unresolved call outs is when an item is not listed in the BOM. Item on right side of this clip came from another part studio/assembly.


  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @StephenG - Its a long shot, but have you double checked that the BOM reference and drawing reference are the same (and same version)? I've run into issues in the past where these somehow got mixed up and were referencing different assembly versions or something when updating old multi-page drawings.
  • StephenGStephenG Member Posts: 369 ✭✭✭
    I have yet to create any versions in this document. Yes, this is poor OS usage design technique, but the model is relatively simple, and I am the only user of the data, I haven't had to concern myself with design iterations. 
  • PrachiPrachi Member, OS Professional Posts: 262 ✭✭✭
    Best way to get help with something like this is to share the document and post a link here.

  • shawn_crockershawn_crocker Member, OS Professional Posts: 862 PRO
    When inserting the Bom, have you tried manually selecting the desired assembly reference from the dialog to be sure the Bom isn't trying to reference some other assembly on a different sheet?
  • StephenGStephenG Member Posts: 369 ✭✭✭
    Did some additional experimentation and it appears there is a bug in Onshape.

    1) Item Ballooning gets confused if assembly BOM references another assembly (a sub-assembly) which is also in the same drawing (on a different sheet). Item Ballooning cannot distinguish between instances that are part of an assembly instance (sub-assembly), or instances of the part in the assembly at the top level. 
     
    2) When you delete and reinsert the BOM item balloons cannot be created; they show up read with a "----" item number.

    I have created an very simple OS document that reproduces the bug and submitted a Bug Report. 

            
  • StephenGStephenG Member Posts: 369 ✭✭✭
    Well, it appears I am the problem; proverbial user error.

    @shawn_crocker's comment did point me in the right direction, but I completely missed its subtlety. I did recheck to make sure the BOM that was inserted in the drawing was associated with the assembly the view in the drawing was created from. It never dawned on me that it is possible to associate a view of an assembly to different BOM than the one that truly reflects the content of the assembly. 

    I am at a loss as to why anyone would want to point to a different assembly's BOM to document an assembly view in a drawing, but apparently OS allows it. Could someone describe a real world scenario where this makes sense?

    Why does OS not always make the "BOM Table Reference" for an assembly view point to the assembly's BOM the default? 

    Even in the situation where multiple BOM's for different assemblies might be inserted on the same sheet (which I have never seen done), I cannot fathom why one would want to do point to a different BOM than the "real" BOM (assembly hierarchy) of the assembly shown in the drawing.  

    I see that OS has a provision to insert a BOM created/managed externally; but it seems that automatic fill-in of balloon text would no longer function - it is all manual balloon text entry at that point.     

  • PeteYodisPeteYodis Moderator, Onshape Employees Posts: 541
    edited May 2021
    @StephenG There are cases where users want views of subassemblies to use the BOM and callouts that relate to the assembly top level.  We have not delivered this yet for callouts within drawings (Planned improvement), but our approach here would make that possible when we deliver on it.  If you have not submitted a ticket and shared your document with Onshape Support, I'd encourage you to do that and we can take a closer look at your scenario.  
  • StephenGStephenG Member Posts: 369 ✭✭✭
    @PeteYodis, I did submit a ticket and OS Support did straighten me out and I have a much better understanding on how OS BOM's work in drawings.
     
    "There are cases where users want views of subassemblies to use the BOM and callouts that relate to the assembly top level."

    The above explains why there is an option for an view of an assembly to reference a different assembly's BOM.

    Interesting use case, but I am not convinced this is a wise approach. Might work for designs involving a small number of parts, but certainly would not scale to large products with hundreds/thousands of unique parts. Also, this complicates design reuse of subassemblies in other product designs.

    This functionality appears to be partially implemented already; however, it currently only works for a "Flattened" BOM. I find it curious that a BOM must be inserted into the drawing before automatic labeling of callouts/balloons will work.  Also, why is it an assembly tab BOM does not have the "Structured - Multi level" view option that drawings have? 

    It has been my experience there is not a precise definition of what a BOM/Parts List is and how they are used in a company's business process. Personally, I have come to the conclusion that BOM/Parts List should not appear on the face of classic engineering drawings, but should be built and maintained by a dedicated application specifically designed for that purpose, which is tightly linked to the CAD system. The drawing document need only contain a link to the appropriate BOM/Parts List data. While every CAD product has some basic BOM functionality, invariably its "out-of-the-box" capability does not meets the unique needs of a company.  

  • PeteYodisPeteYodis Moderator, Onshape Employees Posts: 541
    edited May 2021
    @StephenG I long ago convinced a previous company of mine to abandon BOMs on drawings and using item numbers for callouts.   The BOM in our case was officially in ERP, and trying to make item numbers consistent between two different BOM systems was a nightmare when you take designs through changes.  We moved to the callout containing the part number on the drawings and sorting our BOM in ERP by ascending part numbers.  We freed ourselves from an antiquated tradition of item numbers (in my opinion) in favor of the truly unique identifier  - the part number.  In addition, the shop floor loved seeing part numbers immediately next to the components on the drawing.  It saved them from having to look something up in a BOM table by first finding the item numbers.  

    https://forum.onshape.com/discussion/comment/10046/#Comment_10046

    For Onshape, we have to maintain some flexibility in how lots of companies choose to work.  Still more for us to do for sure, but we do have to keep an eye towards flexibility where it is needed.  
Sign In or Register to comment.