Metamation Developer Notes

  • Developer Notes
  • Resource Map
  • Tools
    • Code Formatting
    • Configuring Git
    • Assignments
    • Testing with Windows Sandbox
    • Single Binary Applications
    • Self-Updating Applications
  • Flux Workflow
    • Flux Workflow
    • Flux Development Style Guide
    • Release notes for Flux
    • SonarCloud analysis for Flux
    • Build a Flux SDK Program
    • Shipping Flux
    • Flux.Test
      • BasicBendAuto Test
      • LaserAuto.cs Detailed Documentation
      • Laserexample:Test1
  • Technical Notes
    • File formats
      • .FX File Format
      • Au(Gold) streams
      • .GEO File Format
      • .LST File Format
      • .LST file - technology
      • .BNC File Format
      • .WAD Files: Flux Resource Packages
      • .Curl Files: ASCII config information
    • Folders App
      • Data\Bendtools
      • Data\Machines
    • FluxCode
      • Welcome & Repo Map
      • Architecture & System Context
      • Subsystem *Bend* (Press Brake)
      • Subsystem *BCell* (Bend Cell Automation)
      • API Maps
      • Data Model Catalog
      • Design Patterns -- A Reader's Guide
      • Tests and Golden Paths
      • Guided Code Tours
      • CAM Glossary with Code Mapping
      • Assignments
      • Flux Onboarding Handbook
    • Data flow
      • Part
        • Part.Dwg
        • Part.Load
        • Part.Load to Part.Dwg
      • BendTech.cs
      • Bend Technology
      • Laser Cutting Technology
    • LTS (Long term support mechanism)
    • Machine ID Scheme
  • FluxTester
    • Commands and Scripts
    • Command Cookbook
    • Script Commands
    • BendTooling.cs Test Inventory
    • LaserTooling.cs Test Steps
    • Fluxtester Recipe Book
    • Nesting.cs Overview
    • Nesting.cs Recipe Book
    • Job.cs Overview
    • Job.cs Recipe Book
  • Software license
  • 3d party software
    • Python
  • Documentation
    • Bento documentation
      • Structure of a Bento page
      • Attributes
    • Software
      • Software Requirement
      • Installation
      • Git workflow for documentation contributors
    • Quick start guide
    • Workflow
      • Roles and responsibilities
      • Analyze
      • Edit
      • Proofread
      • Pre-Publish
      • Publish
      • Release cycle
      • Information required for Documentation Team
      • Checklist for Documenters
    • Styleguide
    • Flavoring
    • Translation
      • Ordering translation for a new document
    • Citations
    • Annotation
Technical Notes
/
FluxCode
/
Data Model Catalog

Data Model Catalog

Goal: know the shape of the most important persisted data classes in Flux — what they are, how they relate, how they serialize, and where the migration hooks live. Reading time: 45 minutes.


1. The five layers of data

Flux’s data model has five conceptual layers. The same Pline may appear in all of them, but the role changes:

1. Geometric primitives          Pline, Vector2/3, Point2/3, Matrix3, Mesh3
                                 ────────────────────────────────────────────
2. Drawing entities              E2*: Line, Arc, Circle, Spline, Bendline, Profile
                                 ────────────────────────────────────────────
3. 3D model entities             E3*: Plane, Flex, Patch, Thick, Forming
                                 ────────────────────────────────────────────
4. Tech projections (per-domain) BendTech, FoldTech, FlatTech, PunchTech
                                 │   contains:   *Op   *Setup   *Mount   *Tool
                                 ────────────────────────────────────────────
5. Top-level aggregate           Part   (one job)
                                 Job    (several parts on a sheet, for nesting)

Layers 1—​3 are what the part is. Layer 4 is what we will do to the part. Layer 5 binds them.


2. Layer 1 — Geometric primitives (Flux.Base)

2.1 Pline — the workhorse

Where: Src\Base\Pline\ and Src\Base\Geo\Profile.cs. What: an immutable polyline (vertices + segment-type info). Used for cross-sections, tool outlines, bend spines, cut profiles, you name it. Persistence: Au-serializable. Preserves arc segments (not just point sequences). Notes:

  • Pline is the single polyline type — there is no separate "polygon" or "outline" class.

  • Many algorithms in Flux.Base\Geo operate on Pline (offsets, sorts, intersections, fillets).

2.2 Mesh3 — triangle mesh

Where: Src\Base\Mesh\. Persistence: binary inside Au; STL via Src\Core\IO\STLModel.cs. Used by: machine .mech files, tool meshes, render.

2.3 Vector / Matrix family

Where: Src\Base\Geo\Point.cs, Vector.cs, Matrix.cs. Concrete types: Point2, Point3, Vector2, Vector3, Matrix3, Matrix3f, value-typed. Notes:

  • All units are mm unless explicitly stated otherwise.

  • Angles are stored in radians internally (Geo.PI, Geo.HalfPI, Geo.QuarterPI); conversions via .D2R() / .R2D() extension methods.

  • Float-vs-double choice is not arbitrary — Point3f for render-bound, Point3 for compute-bound.

2.4 Constants and helpers

Where: Src\Base\Geo\Geo.cs (64 KB). Highlights:

  • Geo.PI, Geo.HalfPI, Geo.QuarterPI — fundamental angles.

  • Tolerance constants used pervasively (Geo.EPS, dimensionless and dimensioned variants).

  • Static methods for normalization, classification, comparison.


3. Layer 2 — Drawing entities (E2*)

The 2D drawing model lives in Src\Core\Drawing\ (and a few siblings). Drawings represent the unfolded view of a sheet metal part, the laser/punch toolpath, dimension annotations, etc.

Type Role

E2Line

Straight line segment

E2Arc

Circular arc

E2Circle

Full circle

E2Spline

Parametric curve (B-spline)

E2Bendline

A line annotated as a bend axis (used in unfolded views)

E2Profile

Compound profile (a closed boundary)

Layer2

Layer/category container

Container: Dwg (the part’s drawing) — exposed as Part.Dwg. Walks via Dwg.Entities.

Persistence: Au; DXF/DWG via Src\Core\IO\DXFReader.cs / DXFWriter.cs.


4. Layer 3 — 3D model entities (E3*)

Src\Core\Model\ (9 files, ~290 KB). Every 3D part decomposes into these. The model lives at Part.Model.

4.1 Entity3 (base)

Where: Entity3.cs (29 KB). Subclasses: | Type | Size | Role | |--|--:|--| | E3Plane | 48 KB | A flat region of sheet metal. | | E3Flex | 55 KB | A bend zone. Holds an IFlexSpine and connectivity info. | | E3Patch | 8 KB | A non-developable patch (rare). | | E3Thick | (in BendCore) | Thick-plate entity. | | Forming | 23 KB | A forming feature (louver, rib, lance). |

4.2 The flat-bend topology

A sheet-metal model forms a tree (really a DAG) with one base plane as the root. Alternate levels are bends; a bend connects to one leeward plane and one or more windward planes. The terminology is:

Leeward = "up" side of the bend (the side closer to root)
Windward = "down" side (further from root)

This is documented in Notes\Dev\1005.BendAreaModeling.ftx. The note’s ASCII / image diagrams are worth ten paragraphs of prose.

4.3 IFlexSpine

Where: Src\Core\Model\BendSpine.cs and E3Flex.cs. Members: GetSpine(double bendLie) returns the cross-section polyline at a given bend "lie" (0 = flat, 1 = fully folded); Thickness returns the sheet thickness. Implementations: BendSpine (standard), FlatBendSpine (special), Z-bend variants, hem variants. Used by: rendering, bend area modeling, collision, simulation.

4.4 The Model3 container

Where: Src\Core\Model\Model3.cs (71 KB). What: the entity collection plus utilities (search, traversal, edits). Part.Model is a Model3.


5. Layer 4 — Tech projections

A part can have several tech projections at once. Each one is a per-domain "what we plan to do".

5.1 The shared shape

Every *Tech follows the same pattern:

  • Constructed via a static Make (Part, Machine, ...) factory returning EResult.

  • Holds a list of operations (Ops) and a list of setups (Setups).

  • Implements ISheafSite (settings cascade through to Part).

  • Has a Dump (TextWriter) method used by golden-file tests.

5.2 BendTech — see chapter 02

The most thoroughly documented tech.

5.3 FlatTech (a.k.a. CutTech)

Where: Src\Core\Laser\ and Src\Core\Punch\. Role: unifies laser, punch, and combo machining into a single flat-cutting projection. Held on Part: Part.CutTech (note the alias FlatTech ≡ CutTech in code). Specialized cuts: LaserCut, PlineCut, ScrapCut, SliceCut, StitchCutter, TraceCut, Bevel3DTooler.

5.4 FoldTech

Where: Src\Core\Fold\ (42 files). Role: panel-bender (TecZoneFold) projection. Different machine kinematics than press brake.

5.5 PunchTech

Where: Src\Core\Punch\ (13 files). Specialization for punching.

5.6 BCell — the orchestration sibling

Not a tech in the strict sense, but lives at the same conceptual level. Models the robot cell’s gripper, regrips, deposits, pickups. The bend operations themselves still own the robotic awareness; BCell models the physical cell that performs them.


6. Layer 5 — Part

6.1 The aggregate

Where: Src\Core\Part\Part.cs (sealed class, 77 KB). Implements: ISheafSite, INotifyPropChanged.

public sealed class Part : ISheafSite, INotifyPropChanged {
   public BendTech BendTech { get; set; }     // press brake projection
   public BendTechMemo BendTechMemo { get; set; }
   public FoldTech FoldTech { get; set; }     // panel bender
   public FlatTech CutTech { get; set; }      // laser/punch
   public Mesh3[] BoostMeshes { get; set; }   // Boost-mode formings
   public Model3 Model { get; }               // 3D model
   public Dwg Dwg { get; }                    // 2D drawing
   public bool IsDirty { get; }
   public Part.EFlags Flags { get; }
   public bool Diagnostic { get; }
   public static Part Current { get; set; }   // active part
   public static List<Part> Active { get; }   // all open parts
   // ... and ~50 more
}

6.2 Static state

Two pieces of static state are notable:

  • Part.Active — list of all parts currently loaded into the process.

  • Part.Current — the part the user is currently editing.

Both are UI-thread-only in practice. Inspect them when debugging anything related to "which part is this affecting?"

6.3 Lifecycle

  1. Construct empty (new Part ()).

  2. Hydrate via Au-deserialize (FX file) or via an IO reader (DXF/GEO/STEP).

  3. Optional DoFoldTo3D if input was unfolded.

  4. Construct one or more techs (BendTech.Make, FoldTech.Make, …​).

  5. User edits / auto-tools.

  6. Save to FX, or export NC code.

  7. Close — removed from Active.


7. Bend-domain catalog (deep-dive companion to chapter 02)

Class File Role

BendTech

Src\Core\Bend\BendTech.cs

Press-brake projection root.

BendOp

Src\Core\Bend\BendOp.cs

A single bending operation.

BendSetup

Src\Core\Bend\BendSetup.cs

A complete tool layout on the machine.

BendMount

Src\Core\Bend\BendMount.cs

One tool mount at one X position.

BendMachine

Src\Core\Bend\BendMachine.cs

The press-brake machine model.

BTool (+ BPunch, BDie, BHolder, BTool.Piece)

Src\Core\Bend\BendTool.cs

The tool model.

BToolList / BToolLibrary

Src\Core\Bend\BendToolLib.cs

Inventory and catalogs.

BendStaples (struct), Workpiece (record)

Src\Core\Bend\BendCalc.cs

Calculation results / inputs.

EBendKind, EBATIssue, EHandlingFlip

Src\Core\Bend\BendCore.cs

Domain enums.

BendAid, BAPlacer, BendAidPos

Src\Core\Bend\BendAid.cs, Ops\BAPlacer.cs

Bending-aid model + placement.

BendBG, BGPath, BGPlacer

Src\Core\Bend\BendBG.cs, BGPath.cs, Ops\BGPlacer.cs

Back-gauge model + path + placement.

BCRegrip, BWaypoint, BGripper

Src\Core\BCell\

Robotic cell concepts.


8. Cross-cutting state

8.1 Sheaf — settings dictionary

Where: Src\Core\Settings\Sheaf.cs. Shape: every site has its own Dictionary<SH, object> and a parent. Resolution walks the chain. The keys are values of enum SH (a closed registry of setting identifiers). Persistence: sheafs persist with their owning object (e.g. BendOp carries its SHDict).

8.2 BendTechMemo

Where: Src\Core\Bend\Ops\BendTechMemo.cs. Why: when a BendTech is replaced, the prior state is captured into a memo so editing history can be preserved. Pattern repeats elsewhere — look for *Memo types.

8.3 Tags, layers, moods

Across rendering and editing you’ll see:

  • ELayer.<*> — render layer (BendMount, LaserCut, …​).

  • EMood.<*> — visual mood (Selected, Normal, Hover, …​).

  • EGTag — glob-action tags (AddAtClamp, AddAtStation, …​) for command routing.

These are not "data" in the persistence sense, but they are first-class nouns in the code.


9. Persistence formats and migration

9.1 Au / Gold (binary)

Format: compact tagged binary. See Notes\Dev\1003.AuGoldEncoding.ftx. Encodes: Part, BendTech, BendOp, BendSetup, machine definitions, etc. Versioning: every Au type has a ObjVersion. Migrations are applied via [PostLoad].

9.2 Curl (text)

Format: Lisp-flavored text with named fields. See Notes\Tech\2007.CurlFiles.ftx. Encodes: human-curated data — machines, tool catalogs, settings profiles.

9.3 FX file

Format: zip containing Curl + Au + thumbnail. Encodes: the user’s part as a saveable, shareable bundle.

9.4 DXF / GEO / 3D import / STL / BMC / DLD

| Format | Role | Reader / Writer | |--|--|--| | DXF / DWG | 2D drawing exchange | DXFReader.cs, DXFWriter.cs | | GEO | Trumpf geometry exchange | GeoReader.cs, GeoWriter.cs | | HOOPS-driven 3D | CATIA / Parasolid / ACIS / Pro-E / STEP | HXReader.cs (despite the name, this is HoopsReader, not a Hex reader) | | NC post output | Press-brake NC code per dialect | C# writers in Src\API\Bend\Post\; dispatched by Src\API\Basis\Basis.cs:138 (no Hex involved) | | STL | Mesh exchange | STLModel.cs, MeshIO.cs | | BMC | Trumpf machine format (bend) | Bend\Ops\ImportBMC.cs, ExportBMC.cs | | DLD | Trumpf NC format (bend) | Bend\Ops\DLDExporter.cs |

9.5 The [PostLoad] migration hook

The pattern (from BendSetup.cs lines 64—​76):

[PostLoad]
void PostLoad () {
   mMounts.RemoveIf (a => a.Tool == null);
   mMounts.Changed += MountsChanged;
   if (mClampPos != null && AuType.ObjVersion < 4 && BMachine != null) {
      float dx = BMachine.Clamp0XPos;
      for (int i = 0; i < mClampPos.Length; i++) mClampPos[i] += dx;
   }
   if (AuType.ObjVersion < 5)
      foreach (var m in mMounts)
         if (m.Tool.TopValency.IsBlade () && m.SensorPair != null)
            AdjustLockedMount (m);
}

Two things to note:

  • AuType.ObjVersion is the version that came in, not the current one.

  • Migrations are forward-only — you migrate version 3 → 4, you never read a future version.


10. Identity and uniqueness

Concept Where Used for

BendOp.UID

per-tech sequence

comparing ops across edits

BendOp.SeqNo

sequence index

display order

BendSetup.UID

per-tech sequence

mount routing

Part GUID

Workpiece.PartGuid

cross-system identification

Machine ID

integer, used as folder name

BendMachine.Get(id)

Tool ID

per catalog

BTool

VModel.Id

per process

scene-graph routing

Convention: UIDs are stable across save/load (they live on the object). VModel.Id is only stable for the lifetime of one Flux process — never persist it.


11. Coordinate systems

  • World CS — overall scene. CoordSystem.World.

  • Plane CS (per E3Plane) — Org / XVec / YVec / ZVec are anchored to a side wall (see Notes\Dev\1005.BendAreaModeling.ftx).

  • Flex CS — bends inherit from their leeward plane.

  • Machine CS — anchored to the bend machine table; X along table length.

  • Mount CS — mount X is a local coordinate on the table.

When a bug looks like "things drawn in the wrong spot", always ask which CS the coordinates are in. The transition between Plane CS and World CS is a frequent source of subtle errors.


12. Units and tolerances

  • All lengths in mm. All angles in radians at runtime; degrees only for user-facing strings (use .R2D() / .D2R()).

  • Tolerances live in Geo.cs and are domain-specific (geometric tolerance vs. simulation tolerance vs. file-format precision).

  • Determinism — sorting must use GeomSort or Pline-aware comparators that handle floating-point near-ties consistently. Plain OrderBy on doubles is a smell.


13. Self-check

  1. What’s the difference between E3Flex and BendOp? (§4.1 / chapter 02 §3)

  2. Which class implements IFlexSpine for a hem? (§4.3, search for hem-specific spine subclass)

  3. Which method is the test contract for BendTech / BendSetup? (§5.1 + §9.5 — Dump)

  4. What format is a Machine.curl? (§9.2)

  5. Where do you put a forward-migration when you change a class’s persisted shape? (§9.5)

  6. What is the unit of all lengths in Flux? (§12)


14. If you take just one thing from this chapter

A Part aggregates one or more tech projections, each with its own Ops and Setups. Geometry sits in Model (3D) and Dwg (2D). Settings cascade through Sheaf. Persisted shape is migrated forward via [PostLoad]. Once you can place any class on this map, you can read any subsystem.


Last updated: 2026-05-04. Verified against Src\Core\Part\Part.cs, Src\Core\Model\, Src\Core\Bend\, Src\Core\Settings\Sheaf.cs, and Notes 1003/1005/2007.

Contents

  • 1. The five layers of data
  • 2. Layer 1 — Geometric primitives (Flux.Base)
  • 2.1 Pline — the workhorse
  • 2.2 Mesh3 — triangle mesh
  • 2.3 Vector / Matrix family
  • 2.4 Constants and helpers
  • 3. Layer 2 — Drawing entities (E2*)
  • 4. Layer 3 — 3D model entities (E3*)
  • 4.1 Entity3 (base)
  • 4.2 The flat-bend topology
  • 4.3 IFlexSpine
  • 4.4 The Model3 container
  • 5. Layer 4 — Tech projections
  • 5.1 The shared shape
  • 5.2 BendTech — see chapter 02
  • 5.3 FlatTech (a.k.a. CutTech)
  • 5.4 FoldTech
  • 5.5 PunchTech
  • 5.6 BCell — the orchestration sibling
  • 6. Layer 5 — Part
  • 6.1 The aggregate
  • 6.2 Static state
  • 6.3 Lifecycle
  • 7. Bend-domain catalog (deep-dive companion to chapter 02)
  • 8. Cross-cutting state
  • 8.1 Sheaf — settings dictionary
  • 8.2 BendTechMemo
  • 8.3 Tags, layers, moods
  • 9. Persistence formats and migration
  • 9.1 Au / Gold (binary)
  • 9.2 Curl (text)
  • 9.3 FX file
  • 9.4 DXF / GEO / 3D import / STL / BMC / DLD
  • 9.5 The [PostLoad] migration hook
  • 10. Identity and uniqueness
  • 11. Coordinate systems
  • 12. Units and tolerances
  • 13. Self-check
  • 14. If you take just one thing from this chapter
API Maps Design Patterns -- A Reader's Guide

      Copyright © 2025 TRUMPF Metamation. All rights reserved.

    Compiled by Bento