IPT Extrusion Direction Identification and Exported Dimension Maintenance

Question

For a part already classified as a 1D extrusion, how can the extrusion direction be identified reliably enough to calculate L and H, and how can those values remain synchronized for normal IPT files and standard iPart members without manual maintenance?

Method

1. Direction-source evaluation

The investigation compared three possible sources for the extrusion direction:

1. Apprentice feature history. Apprentice can read document properties and final B-Rep geometry, but it does not expose usable parametric feature history. In sampled normal parts, iPart factories and iPart children, ComponentDefinition.Features.Count returned zero even though a valid solid SurfaceBody was present. Apprentice therefore cannot reliably identify the modeling extrusion that created the stock.
2. Inference from final B-Rep geometry. A body-level PreciseRangeBox or OrientedMinimumRangeBox can return usable extents, but extents alone do not identify which direction is the stock length. Holes, notches and end miters can weaken geometric symmetry, while a short square or cubic bar can make multiple directions equally valid. A B-Rep recognizer can rank likely directions, but cannot recover the historical modeling operation deterministically for arbitrary machined stock.
3. A maintained direction credential. A user parameter such as ExtrusionAxis_Export was considered and rejected. It would introduce a second manually maintained source of truth, and numeric axis codes would not be sufficiently intuitive for modelers.

The selected source is the full Inventor feature model, accessed by an iLogic rule while the IPT is open in Inventor. The rule inspects the first three part features for a global-axis-aligned extrusion, resolves its X, Y or Z direction, updates the model, and measures the resulting PreciseRangeBox.

For the resolved axis:

• L_Export is the range-box extent parallel to the extrusion direction.
• H_Export is the larger of the two extents perpendicular to the extrusion direction.
• Both values are converted to the document’s length units and rounded to four decimal places using midpoint rounding away from zero.

This is a deliberately bounded 1D-extrusion rule, not a general classifier for arbitrary IPT geometry. The codification taxonomy remains the responsibility of RND-0001.

2. Output-property design

Early versions used generic L and H User Parameters. Runtime inspection showed that L could be calculated per member, while H either failed to appear or appeared in the iPart table as H [Custom]. That heading identified a free custom table column rather than a parameter-backed iPart column. A custom column can contain text or expressions, but it does not establish the required User Parameter and exported Custom iProperty relationship.

The output names were changed to L_Export and H_Export to make their purpose explicit and reduce collision with model parameters created by individual modeling practices. Each output is now created as a numeric User Parameter, marked ExposedAsProperty = True, formatted as a unitless numeric Custom iProperty, marked non-key, and labeled AUTO-CALCULATED BY iLOGIC. A same-name direct Custom iProperty is removed before exposing a newly created parameter because it would otherwise block creation of the parameter-backed property.

3. Normal Part data flow

For a normal IPT, the rule performs the following flow when the document is saved:

1. Confirm that the document is eligible and that a supported extrusion axis can be found.
2. Update the model and calculate L_Export and H_Export from ComponentDefinition.PreciseRangeBox.
3. Create or update the two exposed User Parameters.
4. Allow the active Before Save Document event to persist the changes with the document.

This avoids a separate save call and prevents save-event recursion through a shared-variable re-entry guard. The same rule can also be run in batch before DeliverablesHandler synchronizes data to MySQL.

4. Standard iPart data flow

A factory-level User Parameter has only one active value. It cannot persist a different value for every standard iPart member unless it is included as a parameter-backed iPart table column. The L_Export and H_Export columns are therefore required for per-member persistence.

Inventor’s iPartTableColumns API can inspect existing columns but does not provide a native Add method. The implementation consequently uses the embedded ExcelWorkSheet only when one or both schema columns are missing. It writes the exact User Parameter names into the worksheet header, initializes each row, saves and closes the worksheet, and then reacquires the factory, parameter and column COM references. Excel is not used during normal row calculation.

Factory execution then:

1. Ensures the two User Parameters and parameter-backed table columns exist.
2. Calls CreateMember(row) for each standard row to build that configuration.
3. Measures the generated member’s primary body PreciseRangeBox using the factory extrusion axis.
4. Writes the rounded expressions into that row’s L_Export and H_Export cells.
5. Regenerates only rows whose output values changed.

When the rule runs inside an open standard iPart child, it measures the open child, updates only the matching row in the parent factory, and saves the parent factory if the row changed. It deliberately does not call CreateMember for the currently open child, avoiding an attempt to overwrite or regenerate the document while its own save rule is executing. Custom iPart factories and custom members are outside the current scope.

5. Execution eligibility

The current rule is part_dimension/1D-Extrusion_L_H.iLogicVb, registered as part.sync-extrusion-l-h, and is intended to run from Before Save Document under its current external-rule filename.

Eligibility is evaluated before any mutation:

• The document must be a saved .ipt Part Document.
• The third hyphen-delimited filename segment must not be GA.
• Part Number matching is case-insensitive and uses an explicit trailing hyphen to prevent one code from capturing another code with the same leading characters.

The current allowed prefixes are:

ALU-, ALU.A-, ALU.C-, ALU.R-, ALU.T-, FRM-, GAS-, SST.A-, SST.C-, SST.T-, STL-, STL.A-, STL.C-, STL.R-, and STL.T-.

As a result, ALU.B- is explicitly excluded instead of being accidentally accepted by a broad StartsWith("ALU") test. ALU.P- is also excluded because RND-0001 classifies it as 2D-Sheet, and ALUMINUM- is excluded because it is not an exact allowed code.

Result

The investigation established the following:

Runtime screenshots from the development iterations proved that the geometry calculation could produce distinct member values: the observed L rows were 80.2503 in, 13.3613 in, and 16.2088 in, with an observed H value of 2.0089 in. Those same screenshots also exposed the original schema defect: only L existed as a User Parameter, while H [Custom] was not parameter-backed and later disappeared entirely on rerun.

The final source corrects that design by using L_Export and H_Export consistently in the User Parameter collection, Custom iProperties and iPart table. Static inspection confirms the normal-part, factory and child branches, four-decimal rounding, re-entry guard, child-safe behavior, explicit prefix boundary matching, and schema-only Excel use. The iLogic registry validator passes for the current source and contract.

The final version has not yet been promoted to runtime_verified under the rule registry protocol. A successful call or save is insufficient evidence; final acceptance still requires effect-specific readback from representative normal parts, a standard factory and generated children after save/reopen.

Conclusion

For CASE-0001, DeliverablesHandler should not attempt to rediscover the 1D-extrusion direction from Apprentice or final B-Rep geometry. The stable division of responsibility is:

1. Inventor iLogic uses feature history to calculate and maintain L_Export and H_Export when an eligible document is saved.
2. Standard iParts persist those outputs as parameter-backed iPart table columns so every member owns a distinct value.
3. DeliverablesHandler reads the already normalized exported properties and synchronizes them to MySQL.

This design removes manual dimension maintenance and avoids the stale-property gap during ordinary modeling, provided that the external rule remains assigned to Before Save Document and that models satisfy the bounded extrusion-feature convention. It also avoids a manually maintained direction credential.

The current implementation should be treated as the mature 1D-extrusion baseline and should not be broadened into a general B-Rep classifier. The ALU.P classification conflict has been resolved by removing ALU.P- from this rule’s eligibility list. Remaining work is limited to final Inventor runtime readback.

Supporting Context

Test and Observations

• Apprentice read-only sampling covered a normal part, a standard iPart factory and a standard iPart child. All three exposed a solid SurfaceBody while ComponentDefinition.Features.Count returned zero. This confirmed that final B-Rep geometry was available but usable parametric feature history was not.
• A read-only audit of the ALU folder found 2,524 IPT files. After excluding 1,269 old or superseded files, 1,255 current candidates remained: 705 normal parts, 204 standard iPart factories and 346 standard iPart children. No metadata read errors or custom iParts were observed. The first-three-feature geometry requirement could not be verified through Apprentice.
• Runtime development observations produced distinct member values while the output schema was still evolving. They demonstrate that member-specific geometry calculation is viable; they do not constitute final save-and-reopen verification of the current L_Export and H_Export implementation.

Failed Attempts

• Treating iPartFactory.DefaultRow as an active geometry selector did not produce member-specific geometry and left exported values at the factory-level default. The final implementation uses CreateMember(row) and measures the generated member body.
• A free H [Custom] table column preserved row values but did not create the required User Parameter and exported Custom iProperty relationship. Attempts to use the generic numeric parameter name H also failed in the tested factory. The outputs were consequently renamed through the intermediate L_Dim / H_Dim form and finalized as L_Export / H_Export.
• A broad StartsWith("ALU") eligibility test admitted unrelated codes such as ALU.B, ALU.P and potentially ALUMINUM. Explicit prefixes with trailing hyphens replaced the broad match.

Known Limitations

• The rule uses the first ExtrudeFeature found among the first three part features and requires its sketch normal to align with a global axis.
• A factory calculation assumes its standard members share the factory extrusion axis and measures the first resultant surface body exposed through the member’s primary body.
• Custom iPart factories and custom members are skipped.
• Unsupported documents, schema failures and individual row failures are written only to the debug output. A factory run can therefore complete with some rows skipped.
• Legacy L, H [Custom], L_Dim and H_Dim outputs are not migrated or removed by the current rule.
• The Before Save Document assignment is an external Inventor configuration. Renaming the external rule requires the event trigger to be rebound.

Verification Status

The current source and registry contract are synchronized and statically inspected. Earlier runtime observations validate parts of the geometry and schema-development path, but the current final implementation still requires effect-specific readback from representative normal parts, a standard factory and generated children after save and reopen.