Skip to main content
S
sgunnam1-Visitor
1-Visitor
November 16, 2017
Question

BOM Table With Flexible Parts

  • November 16, 2017
  • 1 reply
  • 2767 views

Is there any way that you can specify in the assembly that you don't want this component to show up on the BOM? SW has an "Exclude from BOM" checkbox for the components. We have an Top Level assembly, lets say "A" and it has parts ("B", "C" & "D") & Subassemblies ("E", "F" & "G"). While creating the Nested repeat Region BOM for the item "A" in the Drawing Environment, I want to avoid some Child items from the list like ("B" & "F").

Soultions I'm aware of :

Filters: Its a manual process, so I want to find an automated process.

Simplified Rep: Best process but would be avoiding.

Parameter &  Releation: https://community.ptc.com/t5/Creo-Modeling-Questions/BOM-TABLE-WITH-FLEXIBLE-QTY-AND-UOM/td-p/248590 I'm thinking of may be, we can make use of Parameters to make the parts "on" & "off" for the selection based on the above example but I'm not sure of it because I'm completely new to creo and I even dont have a better idea on how to use Parameters & Relations (I'm still digging into "Parameters" Topic.)

I really appreciate all your time .  Please present some screenshots while you are presenting your ideas, that why it will be very helpful for a beginner.

1 reply

D
dschenken1-Visitor
1-Visitor
November 16, 2017

BOMs are handled by 'Repeat Regions' which are the output of a query against the assembly. The method is flexible enough to do a large number of complicated things. It is also different enough from the way most programming works that it is tough pick up for a lot of users.(1) One factor is that multiple repeat regions can be on a single drawing for the same assembly with entirely different contents. Eventually all solutions end up being the same amount of effort if one wants to get the same variety of results.

 

For example, it's not too hard to create custom BOM callout symbols that display the component name instead of a number or any other information that's associated with them.

 

OTOH, PTC is terrible at documenting how this function works (OK, at documenting most functionality) and doesn't pre-package workable applications of these functions. This sets the minimum amount of knowledge to be productive for the entire life of product design and documentation somewhat higher, but when that level is reached one can be far more productive.

 

1) I've had people say blah-blah-blah is impossible, and then I take a couple minutes to set up just what they said could not be done. The reason it didn't work for them was they never worked past the initial learning required. I dunno. Last place I worked I made a full tutorial and index guide to all the functionality in Repeat Regions with a number of examples, distributed it, and got 0 comments; too much trouble to read a few pages I guess. Since I was paid by them I don't have rights to it and have no copies.

    S
    sgunnam1-VisitorAuthor
    1-Visitor
    November 17, 2017

    Thats fine and I'm not gonna ask for any documentation but if you think that it could be possible, could you please go through the details of how to do it.

    D
    dschenken1-Visitor
    1-Visitor
    November 17, 2017

    From memory, there are four chunks to the puzzle:

     

    1) The assembly itself which contains components. Each component can have it's own internal parameters (which will be set within those components) and each entry in the model tree can have component parameters (which are set uniquely within the assembly.)  This is where any distinguishing factors can be stored. If a component will always be dealt with in the same way, then create a parameter is in that component. If it depends on which assembly it's in, then create a component parameter in that assembly.

     

    2) The repeat region makes a match-list of certain information and performs a few operations. So, one can match on component names, user created parameters, automatic parameters. Wherever there is a match the repeat region adds a row entry. Depending on repeat region settings, it can create one row for each item or create one row for duplicates and total them; it can also work all the way through a structure or just look at the top level assembly. It can also assign a counting number to identify what row of the table they are on, sometimes used as an item ID number, but it's a dynamic assignment which can be over-ridden with 'Fix' The operations are creating the row number and the count on that row.

     

    Repeat regions can be nested so that information that applies to a particular component can be further expanded based on that match.

     

    Finally, there are 2-D regions, different than nesting, that allow evaluation of groups of components in family tables.

     

    3) The repeat region relations which can be used to create a parameter that exists only within the region context. This is useful for substituting information into a repeat region that is deriveable from the information in the components and assembly. So, if some item is better represented by a length than a row count, it can create a new parameter that is used instead. These are seen in the repeat region as rpt.rel.parameter_name, where 'parameter_name' is one the user creates. If models are set up with parameters such as qty_override then a relation such as:

     

    if exists(qty_override) /* tests to see if the component has a parameter named 'qty_override')

     override_qty = qty_override

    else

     override_qty= rpt.qty

    endif

     

    and the repeat region will have rpt.rel.override_qty in the table instead of rpt.qty.

     

    If one needs to force the situation one can also use:

     

    if mdl.name = "WHATEVER_MODEL"

     override_qty = "LENGTH 5"

    else

     override_qty= rpt.qty

    endif

     

    The second method is useful when the components cannot be changed to add parameters.

     

    One thing that repeat regions relations cannot do is back-drive component or assembly parameters, so something like:

     

    if exists(qty_override)   /* tests to see if the component has a parameter named 'qty_override'

     rpt.qty = qty_override

    endif

     

    does not work.

     

    4) Repeat region filters are simple matches. They only let through whatever matches and it's easy to set up filters that don't match anything by failing to understand that if one filters to allow only condition A and then also filters to allow only condition B that nothing can match both. The result is the entire table contents seems to disappear. As I wrote before, tables are built on a query, so change the query and create a different table. Repeat region relations are excellent ways to build parameters for repeat region filters, which is good, becuase filters can't have complex logic in them, like IF ELSE ENDIF

     

     

    There should be some examples of all of this on this website and on the Internet. Most of the problems I see people having is from failing to understand that the process works according to what it is given, and not based on their expectations, exactly like all programming does. They are surprised when a giant table vanishes because they made a filter that matches nothing, as if the table is a spreadsheet that they manually entered information instead of a dynamic result of running a program. I don't know if they can't understand or just don't want to make the effort.

     

    Rest assured, if something fails that you think should work it is probably your fault, which also means it is something you can figure out and fix. When you do get it you will wonder why you ever thought it was difficult.

      Terms & ConditionsAccessibility statement