IEF AGENTIC SYSTEM DOC
Island Facades
← WORK CASES
CASE-0001 / WORK CASE

DeliverablesHandler L, H, UnfoldedL, UnfoldedH Dimension Normalization

Addressing the incorrect L, H, UnfoldedL, and UnfoldedH extraction with the DeliverablesHandler and ensure correct source for material calculation

Problem

The material team and the fab team have reported incorrect values in MySQL L, H, UnfoldedL, and UnfoldedH columns, causing inaccurate results in the BOM material estimation.

Identified issue types:

  1. The current method in DeliverablesHandler seems to use Apprentice to extract the 3D dimension from the IPT file, then apply a filtering mechanism to map specific values to L or H. For small parts (under certain dimension threshold), the filtering method does not appear to identify the correct L and H values. For example, a reported part was a 6-inch-long extrusion, but because its profile width was 2.275 inches, the L value in MySQL was recorded as 2.275 inches, even that the IPT had the correct direction of extrusion along the X axis in the model space.
  2. Conflated and inexplicit 1D and 2D part rules for each codification, causing missing H values in certain 2D part codifications. This issue affects not only common 2D parts that produce DXF files, but also less common unique codifications such as COR and STN. When DeliverablesHandler fails to output H, the Fab Leads often have to manually override the part dimensions in the MySQL Components table. With pre-existing rules in the table, this workflow is inefficient, increases maintenance overhead, and creates a risk of future data errors.
  3. For 2D parts, UnfoldedL and UnfoldedH come from the part’s width and height in the sheet metal FlatPattern view. Sometimes UnfoldedL and UnfoldedH are flipped due to incorrect FlatPattern orientation. The L value on 2D parts inconsistently inherits either the UnfoldedL or UnfoldedH value.

Goal

Parts under all codifications should have correct L, H, UnfoldedL, and UnfoldedH values through DeliverablesHandler extraction. The following checkpoints are required to ensure accurate results:

  1. Accurate 1D/2D taxonomy for all part codes.

  2. Accurate identification of each part’s 1D or 2D dimensions.

  3. The 2D dimension handler algorithm is sound, but the flat pattern orientation must be corrected in Inventor.

Method

A logic chain whose performance still needs to be validated would roughly involve the following steps:

  1. Classify and tag part codifications based on modeling logic and output type. See the Fab Codes by Category table in the RND-0001 results. Sub-assembly GA names should first be excluded before classifying the remaining fab codes. CASE-0001 consumes the reviewed RND-0001 taxonomy as an approved input contract; a project name that conflicts with that contract requires upstream naming correction rather than an additional fab-code meaning or a DeliverablesHandler classification exception.

  2. For 1D-Extrusion types, the initial hypothesis was that Apprentice could inspect the part feature structure and identify the relevant extrusion feature. RND-0002 found that Apprentice exposes final B-Rep geometry but not usable parametric feature history, while B-Rep alone cannot reliably recover the historical extrusion direction for ambiguous or heavily machined stock. The selected approach is therefore an Inventor iLogic rule that identifies a bounded, global-axis-aligned extrusion from the full feature model, maintains L_Export and H_Export on save, and persists member-specific values through parameter-backed iPart table columns. DeliverablesHandler should read those normalized exported properties. See RND-0002.

  3. For 2D-Sheet types, the main focus is pre-export validation and automatic correction of the FlatPattern orientation. The handler’s unfolded-dimension extraction logic is generally sound, but the rules for assigning UnfoldedL and UnfoldedH need to be more rigorous and consistent. Pre-export validation is documented in CASE-0002, and the automatic orientation correction case will be developed based on its results.

  4. For 1D-Bar types, the main difficulty is that inconsistent feature construction can result in different geometric interpretations of the same part type. A relatively robust approach is to use the fact that these parts are required to produce DXF files and therefore should contain a valid FlatPattern. The FlatPattern orientation can first be standardized, after which the longer planar extent is assigned to L and the shorter planar extent to H.

  5. For 2D-Misc types, …

If the goal is to reduce the amount of geometry processing required by DeliverablesHandler, a preferable approach may be to pre-populate L, H, UnfoldedL, and UnfoldedH as custom iProperties. The lowest-maintenance option would be to use an iLogic rule triggered on document save to calculate and write the required dimensional properties into the part document.

RND-0002 confirms this pre-population pattern for 1D-Extrusion parts through an Inventor Before Save Document iLogic rule that maintains L_Export and H_Export; the corresponding approaches for the other dimensional categories remain subject to their own research and validation.

The following points still require further validation:

  1. Stability and reliability of the calculation and property-writing logic.

  2. Whether the time gap between updating the iProperties and synchronizing the values to MySQL introduces a risk of stale or inconsistent data.

  3. RND-0002 now defines separate standard iPart factory and child data flows. Remaining validation should confirm persisted factory-row and generated-child outputs after save and reopen.

Resolution

FIGURE / PREVIEW