Automation Tip
Overloaded (150%) Creo Assemblies / BOM Tips
Overview
The core philosophy of overloaded (or 150%) Creo Assemblies centers around ALL available design/configuration options (parts/sub-assemblies) being available as the starting point.

The final Creo Assembly / BOM is often derived/reduced from ALL available options to the final BOM using manual, logic-based or automation operations.

Characteristics of overloaded Assemblies
  • Typically a very "flat" structure for all primary design options
  • Component relationships are placed/constrained with specific purpose
    • delete/suppress of any component will results in a predictable final result (planned for depended items also deleted/suppressed as a result)
  • Stable or predictable placement references
    • Common/Global Coordinate Systems
    • Skeleton Model(s) w/ Placements
    • Conventional Assembly (mate/align) Constraints
    • or ... just "packaged" placement

Overloaded Creo Assembly structures, and the knowledge that drives them, must to be properly managed -and- version controlled just like any other Creo Part/Assembly. PTC's Windchill is an excellent system for this.

Resume vs. Remove vs. Hybrid Philosophies
Resume and Remove approaches assume ALL available design options are pre-assembled into, or within, a top-level assembly as the starting point. Hybrid approaches use combinations of Resume and Remove - but also may include the dynamic addition of new options.

  • Resume Philosophy
    • Common approach used for in-vehicle-position configurations where each designed component/sub-system option are basically static items.
    • Assumes ALL options exist in a SUPPRESSED state by default and are RESUMED / enabled to produce the final geometry.
  • Remove Philosophy
    • Common approach for configurations with anticipated dependent relationships like machine designs where components and/or sub-systems are planned to be included/excluded by default.
    • Assumes ALL options exist in an ACTIVE state by default and are either SUPPRESSED / DELETED to produce the final result.
  • Hybrid Philosophy
    • In some configuration applications, a starting point can be a combination of pre-assembled models that are either active or suppressed by default.
    • This may also include pre-defined locations for new models to be assembled during the automation process. Assembled models typically use known assemble references (e.g. named coordinate systems) or as assume to just be "included" as a "packaged" assembly component.
    • Packaged components can be standard components (parts, assemblies or even bulk items) and are often used for non-geometric items (e.g. oil, paint, packaging materials, etc.) where parameterization of items may be required. These are useful for situations where you need to report information on your drawings (e.g. repeat regions) or leverage/reference them within parametric relations to help drive the design/configuration.
    • It should be noted that other, non-geometric, BOM items are typically (and often better handled) in Windchill via WTParts that are required down stream but may not influence or be technically required within the Creo Assembly.



Overloaded Assemblies typically assume that every option is already known, claims space and are properly aligned/interfaces with other components around them. This making it easier to validate common placement of like items and globally evaluate clearances / changes.

The final design/configuration is often driven from an external data source like a MRP/ERP/Order System... or a simple spreadsheet to drive the final BOM requirements.

When planed for, and executed properly, the simple resume/suppress/delete, or even the dynamic assembly of highly variable, components from the main overloaded assembly can be a trivial process using Excel Power Query and Nitro-CELL.
Common Approaches
The modeling approach for an overloaded Creo Assembly is often driven by the inputs into the configuration process to deliver on downstream needs for information/results. A focus on aligning features, options, and performance requirements with the finally derived results often drives modeling decisions.

The



Resume and Remove approaches assume ALL available design options are pre-assembled into, or within, a top-level assembly as the starting point. Hybrid approaches use combinations of Resume and Remove - but also may include the dynamic addition of new options.

  • Resume Philosophy
    • Common approach used for in-vehicle-position configurations where each designed component/sub-system option are basically static items.
    • Assumes ALL options exist in a SUPPRESSED state by default and are RESUMED / enabled to produce the final geometry.
  • Remove Philosophy
    • Common approach for configurations with anticipated dependent relationships like machine designs where components and/or sub-systems are planned to be included/excluded by default.
    • Assumes ALL options exist in an ACTIVE state by default and are either SUPPRESSED / DELETED to produce the final result.
  • Hybrid Philosophy
    • In some configuration applications, a starting point can be a combination of pre-assembled models that are either active or suppressed by default.
    • This may also include pre-defined locations for new models to be assembled during the automation process. Assembled models typically use known assemble references (e.g. named coordinate systems) or as assume to just be "included" as a "packaged" assembly component.
    • Packaged components can be standard components (parts, assemblies or even bulk items) and are often used for non-geometric items (e.g. oil, paint, packaging materials, etc.) where parameterization of items may be required. These are useful for situations where you need to report information on your drawings (e.g. repeat regions) or leverage/reference them within parametric relations to help drive the design/configuration.
    • It should be noted that other, non-geometric, BOM items are typically (and often better handled) in Windchill via WTParts that are required down stream but may not influence or be technically required within the Creo Assembly.

Characteristics of overloaded Assemblies
  • Typically a very "flat" structure for all primary design options
  • Component relationships are placed/constrained with specific purpose
    • delete/suppress of any component will results in a predictable final result (planned for depended items also deleted/suppressed as a result)
  • Stable or predictable placement references
  • Common/Global coordinate system(s)
  • Skeleton Model(s)
  • Conventional Assembly Constraints
  • or ... just "packaged" placement

Overloaded Assemblies typically assume that every option is already known, claims space and are properly aligned/interfaces with other components around them. This making it easier to validate common placement of like items and globally evaluate clearances / changes.

The final design/configuration is often driven from an external data source like a MRP/ERP/Order System... or a simple spreadsheet to drive the final BOM requirements.

When planed for, and executed properly, the simple resume/suppress/delete, or even the dynamic assembly of highly variable, components from the main overloaded assembly can be a trivial process using Excel Power Query and Nitro-CELL.
Static Overloaded Assemblies (Lego Bricks)
The core philosophy of overloaded (or 150%) Creo Assemblies centers around ALL available design/configuration options (parts/sub-assemblies) being available as the starting point. The final Creo Assembly / BOM is derived/reduced from ALL available options to a final BOM using manual, logic or via automation operations.

Overloaded Creo Assemblies can be static like lego blocks, parametrically driven like rubber bands, or use combinations thereof.

Static Overloaded Creo Assemblies
  • Typically very "flat" structures (often assembled to the root-level)

Characteristics of Static Assemblies
  • Typically a very "flat" structure for all primary design options
  • Component relationships are placed/constrained with specific purpose
    • delete/suppress of any component will results in a predictable final result (planned for depended items also deleted/suppressed as a result)
  • Stable or predictable placement references
  • Common/Global coordinate system(s)
  • Skeleton Model(s)
  • Conventional Assembly Constraints
  • or ... just "packaged" placement

Overloaded Assemblies typically assume that every option is already known, claims space and are properly aligned/interfaces with other components around them. This making it easier to validate common placement of like items and globally evaluate clearances / changes.

The final design/configuration is often driven from an external data source like a MRP/ERP/Order System... or a simple spreadsheet to drive the final BOM requirements.

When planed for, and executed properly, the simple resume/suppress/delete, or even the dynamic assembly of highly variable, components from the main overloaded assembly can be a trivial process using Excel Power Query and Nitro-CELL.
Eliminating Geometric Dependencies
If not properly planned for, conventional geometric (mate/align) constraints can easily cause multiple unwanted configuration problems.

The following guidance only apply for
delete or hybrid philosophies.

The solution... generate a "dumb" version of the Main Assembly to eliminate unwanted geometric constrains/dependencies as the starting point.
1
Autonomous or Dependent Geometry?
IF the configuration process is planned around geometric dependent relationships (e.g. suppressing/deleting of a component(s) results in predicable geometrically referenced component(s) also being suppressed/deleted)... Then rock on! The rest of this section may, or may not, be useful for this scenario.

However, IF geometric dependent relationships are NOT expected and a cascading deletion/suppression of the needed components results... this will likely result in major final configuration problems.

When dealing with unwanted referenced constrains within assemblies, converting the assembly into a "dumb"format can save a lot of time that would be required to test and fix various configurations.

Nitro-PROGRAM is an excellent tool for quickly, and visually, identifying, and validating model dependencies if relying on geometric constraints within configuration processes.
    2
    Converting to "Dumb" Geometry
    Converting your main assembly to a "dumb" assembly as your starting point is an excellent way to eliminate accidental suppression/deletion of dependent items that are actually needed in the final BOM.

    When working with highly constrained geometric dependencies within your BOM structure, converting the main Assembly into "something dumb" is always a good thing.

    For example:
    Export your main design as any of these file types:

    • STEP
    • NEUTRAL
    • PVZ
    • IGES
    Then Import them back into Creo. This will break all of your assembly constraints (obviously) and give you a model that you can easily prune models from by suppress/delete operations to your final BOM configuration goals.

    The caveat of doing this... the import back into Creo may not have the same name as what was exported. They typically import with an "_#" or "_asm" or a combination thereof for each new item imported to Creo. Assemblies also tend to import as sub-assemblies not just a straight import of the content as it was exported.

    The good news... much of this can be handed in excel for cleanup/processing.
    3
    Identifying items to Suppress/Delete with Excel Power Query
    For this example, assume that a final BOM (list of components) is delivered as a CSV File and that needs to be used as an input to your automation process - but you have to keep the items in the CSV File and suppress/delete everything else in the main Assembly.

    Seems simple enough.. right? It is with the right plan!


    • Batch Worksheet - The list of Models/Drawings you want to process,
    • Execution Worksheet - The execution instructions to perform for each batch step.
    Consider these functions based on your use case:

    • Active or In-Session:
      • application : BATCH_GET_FILES
      • application : BATCH_APPEND_GET_FILES
      • application : BATCH_LIST_INSTANCES
      • application : BATCH_LIST_SIMP_REPS
    • Local Working Directory / Search Path
      • application : BATCH_LIST_FILES
      • application : BATCH_APPEND_LIST_FILES
    • Windchill
      • application : WC_WS_BCH_APND_LIST_FILES
      • application : WC_WS_BCH_LIST_FILES
    The information gathered from the above functions expect to be written to a Nitro-CELL BATCH Worksheet. There is no need to worry about the Worksheet Location for the Data to write with these calls, just the Worksheet Name where the batch list will be written.

    PRO-TIP: If you want to batch process Assemblies first, then Parts, you would need two commands to populate the BATCH Worksheet in Excel.

    For Example:
    1. application : BATCH_GET_FILES *.asm
    2. application : BATCH_APPEND_FILES *.prt
    would clear the BATCH Worksheet, write any Assembly Model Names to the Batch, then APPEND the Part Model Names to the Batch (stacking the request results one after the other in Excel)
    4
    Start / Reset the Batch
    If you specified that the Batch Worksheet should be included in the NItro-CELL_MAIN Workflow, every time you press the "Do It" Button, the Batch will be processed (unless excluded manually or by formula in Nitro-CELL_MAIN).

    Otherwise, you can force a Batch process to be executed by another Nitro-CELL Worksheet (not the one that will be used to process operations on each file - but earlier in the overall automation). When executing in this way, use the following commands to control the workflow:

    • application : BATCH_START - to kick off the batch process
    • application : BATCH_RESET - to reset the start position to the top of the list

    PRO-TIP: application : CLEAR_BATCHSHEET is not a commonly used function, but there are scenarios where your operation sequence may find use of this function.

    5
    Execution Errors - Skipping Batch Items
    Sometimes a model or drawing you are trying to process in a batch may have an error in regeneration or export. By default Nitro-CELL will flag errors in light red on your Batch Worksheet indicating that the item was not processed - but will keep going until the batch ends.

    If you detect an intermediate, during execution, problem in your data/expectations, you can stop continued execution on the batch step simply by using:

    • application : BATCH_SKIP

    This will flag an item in your batch list as "skipped".

    PRO-TIP: Consider using Nitro-CELL Worksheet Functions to append an log problems when you skip a batch. The following function is particularly handy for logging execution problems in Excel:

    • worksheet : APPEND_ROW
    6
    Converting / Exporting Files
    While Batch Processing File Conversion/Export is the subject of this document, ANYTHING you want to do to a file that you are currently batching.

    Each Batch Item is available at the top of the Batch Sheet Based on the index that is currently being processed within the Batch. This is determined by a formula in the Batch Sheet.

    Simply reference the active model at the top of the batch sheet in your Execution sheet using:

    • model : OPEN <batchActiveModelRef>
    This will ensure that all executions there after will be using the active model in Creo.

    From that you can perform export functions in Nitro-CELL, look at the EXPORT_* functions as a reference for available options.

    PRO-TIP: some export functions are not in Nitro-CELL functions, for special export options in Creo you can use a application : MAPKEY to process them. Search the Automation Advisor for "Mapkeys" to learn more.
    7
    DONE!