Subsystem Bend (Press Brake)

Prerequisite: Chapter 00 (repo map) and Chapter 01 (architecture, M/V/Glob, Sheaf, Hub). Goal: Bend is the canonical subsystem. After this chapter you can localize any bug from the press-brake area to the right code and test entry point — without writing a fix. Reading time: 60—90 minutes. Template note: this chapter doubles as the template for future per-subsystem chapters (Fold, Laser, Punch, Nest, BCell). The same 14-section structure should be followed.

1. TL;DR — Bend in twelve lines

Domain: press-brake CAM (classical bending machine: punch + die). The separate domain Fold is the panel bender (TecZoneFold) — don’t confuse them.
Code root: Src\Core\Bend\ (47 files, ~1.7 MB of source).
Top-level model: Part → BendTech → many BendOp (one bending operation each) and one or more BendSetup (one tool layout on the machine).
Auto-tooler: Ops\BendTooler.cs (139 KB) — the central engine that turns a 3D part into a sequence of bends + tool setups + back-gauge positions.
Machine: BendMachine (subclass of Machine) — loaded from X:\Data\Machine\<id>\.
Tools: BTool (punch / die / holder), per-tech Inventory : BToolList, per-catalog BToolLibrary.
Collision: two modules side by side — BendOpCrash.cs (classic) and NBendCrash.cs (new). Both exist simultaneously. Care needed.
UI hooks: Src\UI\Bend\BendOpUI.cs (BendOpGlob, BendOpsGlob) and siblings.
Tests: Test\Bend\ — one file per year (Bend2017.cs through Bend2025.cs) plus thematic files (BendACB.cs, BendAid.cs, BGPath.cs, BendShuffle.cs, …).
Golden-file pattern: auto-tooler runs, tech.Dump (sw) writes a setup text, Assert.AreTextFilesEqual compares against a .txt reference next to the .geo input.
Robotic bend: the logic is not in BCell\ — BendOp itself knows about Robotic cases (regrip, cell stages). BCell models the robot cell, but Bend orchestrates.
Important non-obvious: models and VModels (rendering) live together in Core. UI controllers (Glob) live separately in Flux.UI.

2. The domain in two minutes — vocabulary of the machine world

Before you read code, learn these 22 terms. They appear in every other class:

Term Meaning Where in code

Term	Meaning	Where in code
Press brake	Bending machine: punch (top) presses sheet into die (bottom)	`BendMachine.cs`
Punch / Die	Top tool / bottom tool	`BTool` with `IsUpper` / `IsLower`
Tool piece	One segment of a tool (tools are segmented)	`BTool.Piece`
Mount	A specific tool placement at an X position on the table	`BendMount`
Setup	A complete set of mounts on the machine	`BendSetup`
Stage / Station	An X region of the table with its own tools	inside `BendSetup`
Bend / Flex	A bending operation. Flex = geometry entity, Bend = operation	`E3Flex` (geometry) vs. `BendOp` (CAM)
Phase	Hem and pre-bend operations split a flex into multiple phases	`BendOp.Phases`
Spine	Center line through the cross-section of a bending zone	`IFlexSpine` (Note 1005)
Flat length / bend deduction	Unfolded length / shrinkage when bending	`BendStaples.Deduction`
V-width	Width of the die V-groove	`BTool` property + `BendCalc.SuggestDieWidth`
Open / closed height	Machine stroke parameters	`BendMachine.OpenHeight` / `.ClosedHeight`
BG (back gauge)	Rear stop the operator pushes the sheet against	`BendBG.cs`, `BGPath.cs`, `BGPlacer.cs`
ACB	Adjustable Crowning Beam — not the ACB laser sensor (different concept)	`BendACB.cs`
Bending aid	Helper that supports the sheet during the bend	`BendAid.cs`, `BAPlacer`
Hem	Hemming: closed/open seam bend	`EBendKind.OpenHem` / `.ClosedHem`
Bump-bend	Many small bends to produce a large radius	`EBendKind.BumpBend`, `BumpSteps`
Z-bend	Offset bend with two close opposing flexes	`EBendKind.ZBend*`, `ZBendTool.png`
Coining	Coining bend (higher force, less springback)	`EBendKind.Coining`
TBS	Trumpf Bend Solution (Trumpf’s own bend calculator)	`TBSBendCalc.cs`, `TBSCustomDB.cs`
Springback	Material rebound after bending	`BendStaples.SpringbackD`
Robotic bend	Bend-cell automation (robot, gripper)	`BendOp.Robotic`, `BCRegrip`
Regrip	Gripper repositions the part mid-job	`BCRegrip`

Press brake

Bending machine: punch (top) presses sheet into die (bottom)

BendMachine.cs

Punch / Die

Top tool / bottom tool

BTool with IsUpper / IsLower

Tool piece

One segment of a tool (tools are segmented)

BTool.Piece

Mount

A specific tool placement at an X position on the table

BendMount

Setup

A complete set of mounts on the machine

BendSetup

Stage / Station

An X region of the table with its own tools

inside BendSetup

Bend / Flex

A bending operation. Flex = geometry entity, Bend = operation

E3Flex (geometry) vs. BendOp (CAM)

Phase

Hem and pre-bend operations split a flex into multiple phases

BendOp.Phases

Spine

Center line through the cross-section of a bending zone

IFlexSpine (Note 1005)

Flat length / bend deduction

Unfolded length / shrinkage when bending

BendStaples.Deduction

V-width

Width of the die V-groove

BTool property + BendCalc.SuggestDieWidth

Open / closed height

Machine stroke parameters

BendMachine.OpenHeight / .ClosedHeight

BG (back gauge)

Rear stop the operator pushes the sheet against

BendBG.cs, BGPath.cs, BGPlacer.cs

ACB

Adjustable Crowning Beam — not the ACB laser sensor (different concept)

BendACB.cs

Bending aid

Helper that supports the sheet during the bend

BendAid.cs, BAPlacer

Hem

Hemming: closed/open seam bend

EBendKind.OpenHem / .ClosedHem

Bump-bend

Many small bends to produce a large radius

EBendKind.BumpBend, BumpSteps

Z-bend

Offset bend with two close opposing flexes

EBendKind.ZBend*, ZBendTool.png

Coining

Coining bend (higher force, less springback)

EBendKind.Coining

TBS

Trumpf Bend Solution (Trumpf’s own bend calculator)

TBSBendCalc.cs, TBSCustomDB.cs

Springback

Material rebound after bending

BendStaples.SpringbackD

Robotic bend

Bend-cell automation (robot, gripper)

BendOp.Robotic, BCRegrip

Regrip

Gripper repositions the part mid-job

BCRegrip

Visuals for the vocabulary are at X:\Doc\Img\Bend\ — e.g. VWidthType.png, OverbendCrash.png, ZBendTool.png, BumpBendSpine.png. If a term remains unclear, there is usually a picture.

3. The data model — class hierarchy

Part
 └─ BendTech                                      [Src\Core\Bend\BendTech.cs]
     ├─ BMachine : BendMachine                    [BendMachine.cs]
     ├─ Inventory : BToolList                     [BendToolLib.cs]
     ├─ Settings : Sheaf (Bend-specific settings)
     ├─ Ops : List<BendOp>                        [BendOp.cs] — the sequence
     │   ├─ Flexes : E3Flex[]                     (1..n, m:n mapping to flexes)
     │   ├─ Phases : int[]                        (one per flex)
     │   ├─ Kind : EBendKind                      (AirBend / Hem / Coining / BumpBend / ...)
     │   ├─ UsedDie, UsedPunch : BTool
     │   ├─ Setup : BendSetup
     │   ├─ BAPos : BendAidPos[]                  (bending-aid positions)
     │   ├─ BGTransition : Sheaf.EBGTransition    (how does the BG move?)
     │   ├─ BumpSteps : int                       (only for bump-bends)
     │   └─ (~200 more properties — file is 210 KB)
     └─ Setups : List<BendSetup>                  [BendSetup.cs]
         └─ Mounts : List<BendMount>              [BendMount.cs]
             ├─ Tool : BTool
             ├─ Pieces : Piece[]                  (segmentation)
             ├─ MountPt : Point3                  (X/Z position on the table)
             └─ IsFlipped : bool

Three subtleties that trip up newcomers:

m:n between flex and BendOp. A hem bend is two phases that exist as two BendOp objects on the same flex. A group bend bundles parallel flexes into one BendOp. See BendOp.cs lines 22—32.
BendTech is the root, not Part. Part is a generic component that may be laser/punch/fold too. The bend-specific data lives in Part.BendTech.
A BendSetup references Mounts, not Tools. Tool identity is not the unit of granularity for mounts — the same BTool may be mounted at multiple X positions.

4. Module map — the 47 files grouped

4.1 Root `Src\Core\Bend\` (24 files)

Size File Contents

Size	File	Contents
6 KB	`BendCore.cs`	Enums (`EBendKind`, `EBATIssue`, `EHandlingFlip`), small shared types. Read this first — everything else references these enums.
13 KB	`BendCalc.cs`	Interface `IBendCalc` + data classes `BendStaples`, `Workpiece`, `ToolSet`. Central calculation abstraction (force, deduction, stroke, springback).
23 KB	`TBSBendCalc.cs`	Trumpf-specific `IBendCalc` implementation.
41 KB	`TBSCustomDB.cs`	Trumpf custom database.
17 KB	`TSOBatch.cs`	Tool-Setup-Optimizer batch mode.
11 KB	`BendAid.cs`	Bending-aid model.
21 KB	`BendBG.cs`	Back-gauge model.
14 KB	`BGPath.cs`	BG motion path between bends.
60 KB	`BendACB.cs`	Adjustable Crowning Beam.
16 KB	`BendExtensions.cs`	Extension methods on the core types.
11 KB	`Clamp.cs`	Punch-clamp model.
7 KB	`FlexCell.cs`	Flex bend-cell special case.
107 KB	`BendTech.cs`	Main facade. Constructor reads the model, groups flexes, builds the initial `BendOp` sequence. Read lines 19—120 for the constructor logic.
210 KB	`BendOp.cs`	The operation. Sealed partial class with ~200 properties. Represents one bending operation. Single source of truth for bend state.
95 KB	`BendOpStatus.cs`	Status / validation logic for an op.
68 KB	`BendOpCrash.cs`	Classical collision check.
78 KB	`NBendCrash.cs`	"New" collision check. Both are alive — a runtime branch picks one.
101 KB	`BendSetup.cs`	Tool layout on the machine.
76 KB	`BendMount.cs`	Single tool mount.
103 KB	`BendMachine.cs`	Press-brake machine definition.
119 KB	`BendTool.cs`	Tool model (`BTool`, `BPunch`, `BDie`, `BHolder`, …).
42 KB	`BendToolLib.cs`	Tool library (`BToolLibrary`, `BToolList`).
23 KB	`BTParametric.cs`	Parametric tools.
59 KB	`BendVM.cs`	View-models: `BendMountVM`, `BendNoVM`, `BendTechVM` (render via `Lux`).
3 KB	`BC7000TestVM.cs`	Test VM for a specific machine class.

6 KB

BendCore.cs

Enums (EBendKind, EBATIssue, EHandlingFlip), small shared types. Read this first — everything else references these enums.

13 KB

BendCalc.cs

Interface IBendCalc + data classes BendStaples, Workpiece, ToolSet. Central calculation abstraction (force, deduction, stroke, springback).

23 KB

TBSBendCalc.cs

Trumpf-specific IBendCalc implementation.

41 KB

TBSCustomDB.cs

Trumpf custom database.

17 KB

TSOBatch.cs

Tool-Setup-Optimizer batch mode.

11 KB

BendAid.cs

Bending-aid model.

21 KB

BendBG.cs

Back-gauge model.

14 KB

BGPath.cs

BG motion path between bends.

60 KB

BendACB.cs

Adjustable Crowning Beam.

16 KB

BendExtensions.cs

Extension methods on the core types.

11 KB

Clamp.cs

Punch-clamp model.

7 KB

FlexCell.cs

Flex bend-cell special case.

107 KB

BendTech.cs

Main facade. Constructor reads the model, groups flexes, builds the initial BendOp sequence. Read lines 19—120 for the constructor logic.

210 KB

BendOp.cs

The operation. Sealed partial class with ~200 properties. Represents one bending operation. Single source of truth for bend state.

95 KB

BendOpStatus.cs

Status / validation logic for an op.

68 KB

BendOpCrash.cs

Classical collision check.

78 KB

NBendCrash.cs

"New" collision check. Both are alive — a runtime branch picks one.

101 KB

BendSetup.cs

Tool layout on the machine.

76 KB

BendMount.cs

Single tool mount.

103 KB

BendMachine.cs

Press-brake machine definition.

119 KB

BendTool.cs

Tool model (BTool, BPunch, BDie, BHolder, …).

42 KB

BendToolLib.cs

Tool library (BToolLibrary, BToolList).

23 KB

BTParametric.cs

Parametric tools.

59 KB

BendVM.cs

View-models: BendMountVM, BendNoVM, BendTechVM (render via Lux).

3 KB

BC7000TestVM.cs

Test VM for a specific machine class.

4.2 `Src\Core\Bend\Ops\` (17 files — toolpath / sequencing)

This is the algorithmic heart. The root holds model + validation; Ops\ holds computation.

Size File Contents

Size	File	Contents
139 KB	`BendTooler.cs`	Auto-tooler. Central engine. Constructor + `DoTooling` orchestrates: sequence → tool score → setup generation → BG placement. Read lines 16—80 for the main pipeline.
15 KB	`BendToolerCore.cs`	Shared data types for the tooler.
9 KB	`BendToolerACB.cs`	ACB-specific tool scoring.
14 KB	`BendToolerAux.cs`	Helpers.
23 KB	`BendToolerRefine.cs`	Refinement pass after initial sequencing.
35 KB	`BendToolHint.cs`	Tool suggestions / constraints.
50 KB	`BAPlacer.cs`	Bending-aid placer.
101 KB	`BGPlacer.cs`	BG placer — where does the back gauge position the sheet? Very complex (stability, collision, rotation).
16 KB	`BGPlacer2X.cs`	Special case with two BG axes.
47 KB	`BendGAPAdjust.cs`	GAP-adjust pass (tool spacing).
41 KB	`BendOpStep.cs`	Single steps of an op.
11 KB	`BendOpSim.cs`	Op-level simulation.
37 KB	`BSimulate.cs`	Simulation pipeline.
21 KB	`BOptimizer.cs`	Sequence optimizer.
11 KB	`BendTechMemo.cs`	Memo structures.
15 KB	`BNCReader.cs`	NC-code reader (re-import).
16 KB	`DLDExporter.cs`	DLD-format export (Trumpf NC format).
20 KB / 43 KB	`ExportBMC.cs` / `ImportBMC.cs`	BMC format I/O (Trumpf machine format, see Note 2016).
9 KB	`JupiduReader.cs`	Legacy reader.
30 KB / 64 KB	`TBendLibExport.cs` / `TBendLibImport.cs`	Tool library exchange.
28 KB	`BToolDXF.cs`	DXF tool I/O.

139 KB

BendTooler.cs

Auto-tooler. Central engine. Constructor + DoTooling orchestrates: sequence → tool score → setup generation → BG placement. Read lines 16—80 for the main pipeline.

15 KB

BendToolerCore.cs

Shared data types for the tooler.

9 KB

BendToolerACB.cs

ACB-specific tool scoring.

14 KB

BendToolerAux.cs

Helpers.

23 KB

BendToolerRefine.cs

Refinement pass after initial sequencing.

35 KB

BendToolHint.cs

Tool suggestions / constraints.

50 KB

BAPlacer.cs

Bending-aid placer.

101 KB

BGPlacer.cs

BG placer — where does the back gauge position the sheet? Very complex (stability, collision, rotation).

16 KB

BGPlacer2X.cs

Special case with two BG axes.

47 KB

BendGAPAdjust.cs

GAP-adjust pass (tool spacing).

41 KB

BendOpStep.cs

Single steps of an op.

11 KB

BendOpSim.cs

Op-level simulation.

37 KB

BSimulate.cs

Simulation pipeline.

21 KB

BOptimizer.cs

Sequence optimizer.

11 KB

BendTechMemo.cs

Memo structures.

15 KB

BNCReader.cs

NC-code reader (re-import).

16 KB

DLDExporter.cs

DLD-format export (Trumpf NC format).

20 KB / 43 KB

ExportBMC.cs / ImportBMC.cs

BMC format I/O (Trumpf machine format, see Note 2016).

9 KB

JupiduReader.cs

Legacy reader.

30 KB / 64 KB

TBendLibExport.cs / TBendLibImport.cs

Tool library exchange.

28 KB

BToolDXF.cs

DXF tool I/O.

4.3 UI hooks `Src\UI\Bend\` (8 files)

File Exposes

File	Exposes
`BendOpUI.cs`	`BendOpGlob` (single-select controller), `BendOpsGlob` (multi-select). Starts with `[Glob (Draw = true, Mouse = EMouse.LDown)]`.
`BendSetupUI.cs`	Setup-editor controller.
`BendMountUI.cs`	Single-mount controller.
`BendACBUI.cs`	ACB editor.
`BendAidUI.cs`	Bending-aid editor.
`BendClampUI.cs`	Clamp editor.
`BendAgent.cs`	Bend agent (mouse / keyboard handler).
`BendSheet.cs`	"Sheet" view of the bend sequence.

BendOpUI.cs

BendOpGlob (single-select controller), BendOpsGlob (multi-select). Starts with [Glob (Draw = true, Mouse = EMouse.LDown)].

BendSetupUI.cs

Setup-editor controller.

BendMountUI.cs

Single-mount controller.

BendACBUI.cs

ACB editor.

BendAidUI.cs

Bending-aid editor.

BendClampUI.cs

Clamp editor.

BendAgent.cs

Bend agent (mouse / keyboard handler).

BendSheet.cs

"Sheet" view of the bend sequence.

4.4 Notes (FTex)

Note Content

Note	Content
`Notes\Dev\1005.BendAreaModeling.ftx`	Required reading. How Flux models bend geometry (`E3Plane` ↔ `E3Flex`, `IFlexSpine`).
`Notes\Dev\1008.BendTools.ftx`	Tool-import conventions.
`Notes\Tech\2006.BendInfoInDXF.ftx`	Bend information in DXF files.
`Notes\Tech\2016.ImportBMC.ftx`	BMC-format import.
`Notes\Tech\2017.CupGripperInfoInDwg.ftx`	Cup-gripper info embedded in drawings (for robotic).

Notes\Dev\1005.BendAreaModeling.ftx

Required reading. How Flux models bend geometry (E3Plane ↔ E3Flex, IFlexSpine).

Notes\Dev\1008.BendTools.ftx

Tool-import conventions.

Notes\Tech\2006.BendInfoInDXF.ftx

Bend information in DXF files.

Notes\Tech\2016.ImportBMC.ftx

BMC-format import.

Notes\Tech\2017.CupGripperInfoInDwg.ftx

Cup-gripper info embedded in drawings (for robotic).

5. Lifecycle of a part — sequence diagram in words

What happens internally when a user opens a 3D part and clicks "Bend Auto-Tool"?

1. Part loads (CAD import or .fx file).
   └─ Part.Model contains E3Plane + E3Flex entities.

2. BendTech.Make (part, machine) is called.
   └─ BendTech constructor (BendTech.cs lines 19–120):
       a. RefineColliders() on the model
       b. Split hem phases (one hem → 2 phases)
       c. Identify groupable flexes (CanGroupWith / CanGroupDoubleSheet)
       d. Per group + phase: create one BendOp
       e. ValidOrder() on the list — topological sequence sort
       f. Assign SeqNo
       g. Decouple "flange-in-hole" multi-span bends into a manual list

3. BendTooler.Process (tech, flags) starts the auto-tooler.
   └─ Pipeline (BendTooler.cs lines 48–80):
       a. PrepareForTooling – drop setups, reset sequence
       b. SetupBasicSequence – dead-reckoning order
       c. TurnOnBumpBending – large radii without tools → bump-bends
       d. DemoteCrashingTools – 2D cross-section collisions
       e. UpdateToolScores – favor tools every bend likes
       f. DoToolerCore – final sequence + setup + BG placement

4. Per BendOp: BAPlacer + BGPlacer
   └─ Bending-aid position
   └─ Back-gauge position per op + BG motion path between ops

5. Validation — BendOpStatus + BendOpCrash (or NBendCrash)
   └─ Per-op issues collected as EBATIssue flags.

6. NC code generation runs through `BendTech.GenerateNCCode` → `Hub.GenerateNC`.
   └─ Dispatched by `Src\API\Basis\Basis.cs::GenerateNC` (line 138) to a C# writer
     in `Src\API\Bend\Post\` (TrumpfDLD, Bystronic, LVD, ...) based on the post
     name token in `BMachine.Post`. The XML doc literally says
     *"Generate NC code directly for a part (without using Hex)"*.

6. Three canonical reading tours (15 min each)

Tour A — "How does a 3D model become a bend sequence?"

Src\Core\Bend\BendCore.cs — all enums (5 min).
Src\Core\Bend\BendTech.cs lines 19—120 — constructor (5 min).
Src\Core\Bend\Ops\BendTooler.cs lines 16—80 — constructor + DoTooling skeleton (5 min).

You should be able to answer:

Why does a hem bend produce two BendOps?
What is a "group bend"?
What are the six phases of the auto-tooler?

Tour B — "What does a tool setup look like internally?"

Src\Core\Bend\BendSetup.cs lines 14—80 — class + Dump (very revealing because Dump is exactly the format compared in tests) (5 min).
Src\Core\Bend\BendMount.cs — the BendMount data structure (5 min).
Src\Core\Bend\BendTool.cs — search class BTool and its subclasses BPunch, BDie, BHolder (5 min).

You should be able to answer:

What is the difference between BTool and BTool.Piece?
How is a setup serialized? (Hint: Dump and ComputeHash.)
Where does a Mount X position originate?

Tour C — "What does a test look like, and what is a golden file?"

Test\Bend\BasicBendAuto.cs lines 11—84 — class BasicBendAuto and the Test helper (5 min).
Open X:\TData\Bend\Auto\Bend_04.geo (binary — just confirm it exists).
Open X:\TData\Bend\Auto\Bend_04.txt — the golden file that tech.Dump (sw) produces (5 min).
Mentally walk through it: test 82 loads Bend_04.geo, calls BendTech.Make + BendTooler.Process, dumps → compared to Bend_04.txt. Any change to the auto-tooler requires regenerating Bend_04.txt (5 min).

You should be able to answer:

How is a Bend bug typically frozen as a test?
Why do we have files Bend2017.cs … Bend2025.cs?
How would you redirect a test to a different machine? (Hint: idMachine = 13.)

7. Common stumbling blocks (observations from the code)

7.1 Two crash engines side by side

BendOpCrash.cs (old) and NBendCrash.cs (new) live together. Both are large (68 + 78 KB). When working on collision logic:

Find out which one is active first (settings/flag).
Never modify only one without knowing what the other does.
This duplication is presumably an in-flight migration.

7.2 The `BendTech` constructor is the logic

BendTech.Make is a thin wrapper — the real sequence creation lives in the constructor (private, ~250 lines). Unusual but consistent: in Flux, constructors often contain "real" logic because they guarantee a fully constructed object.

7.3 `BendOp` is a `partial class`

BendOp.cs (210 KB) holds one part. Grep "partial.BendOp" finds others (e.g. test-related auto-generated parts). *When editing: search the whole solution, not just one file.

7.4 Robotic bend lives in `BendOp`, not separately

For a bug from the BCell / robotics context (e.g. "regrip at the wrong point"), the logic is in BendOp` (properties `Robotic, RegripDuringBend, IsFirstOp/IsLastOp with cell-stage logic) and in the UI glob (BendOpGlob.AddRegrip in Src\UI\Bend\BendOpUI.cs lines 21—55). Don’t only search under BCell\.

7.5 Trumpf-specific paths

BendCalc has two implementations: StdBendCalc (default) and TBSBendCalc (Trumpf). The selection happens in BendMachine.BendCalc:

public IBendCalc BendCalc => Settings.BendCalc switch {
   Sheaf.EBendCalc.Default => IsTrumpf ? TBSBendCalc.It : StdBendCalc.It,
   _ => StdBendCalc.It,
};

If a bug only reproduces on Trumpf machines: look at TBSBendCalc.cs and TBSCustomDB.cs.

7.6 Dump format = test contract

If you change BendSetup.Dump or BendTech.Dump, you break every Bend test at once. That’s by design — the dump format is the contract between auto-tooler and tests. Changes here must come with a full golden-file regeneration.

8. Tests — how they are organized

Inventory (`X:\Test\Bend\`, 25 files)

Category Files

Category	Files
Auto-tooler basics	`BasicBendAuto.cs`, `BendAutoGeneric.cs`, `BendAutoIGS.cs`, `BendAutoV2.cs`
Yearly regression bundles	`Bend2017.cs` … `Bend2025.cs` (one per year)
Topical	`BendACB.cs`, `BendAid.cs`, `BendShuffle.cs`, `BGPath.cs`, `Bend9AxisBG.cs`
Tweaks / crash	`BendTweak.cs`, `BendSelfCrashTest.cs`, `BendMisc.cs`
Bug-fix suite	`BugFixes.cs`
I/O	`BToolIO.cs`
TSO	`TSOTest.cs`
Other	`MCTypes.cs`

Auto-tooler basics

BasicBendAuto.cs, BendAutoGeneric.cs, BendAutoIGS.cs, BendAutoV2.cs

Yearly regression bundles

Bend2017.cs … Bend2025.cs (one per year)

Topical

BendACB.cs, BendAid.cs, BendShuffle.cs, BGPath.cs, Bend9AxisBG.cs

Tweaks / crash

BendTweak.cs, BendSelfCrashTest.cs, BendMisc.cs

Bug-fix suite

BugFixes.cs

I/O

BToolIO.cs

TSO

TSOTest.cs

Other

MCTypes.cs

The standard test pattern

[TestFixture (4, "Basic bend auto-tooler tests", Module = "Bend", Subsystem = "AutoTool")]
class BasicBendAuto {
   [Test (82, "Tooling basic part: Bend_04.geo")]
   void Test1 () => Test ("Bend/Auto/Bend_04.geo");

   public static Part Test (string file, int idMachine = 13, /* ... */) {
      Part part = FX.LoadTestPart (file);
      if (part.Model == null) part.DoFoldTo3D ().Is (EResult.OK);
      BendTech.Make (part, BendMachine.Get (idMachine)).Is (EResult.OK);
      var tech = part.BendTech;
      // ...
      BendTooler.Process (part.BendTech, flags);
      CheckDump (tech, outfile);   // ← golden-file compare
      return part;
   }

   public static void CheckDump (BendTech tech, string refFile) {
      string file = FX.TmpTestFile;
      using (StreamWriter sw = new (file)) tech.Dump (sw);
      Assert.AreTextFilesEqual (refFile, file);
   }
}

Three takeaways:

Test IDs are globally unique (82, 84, 85, …) and stable. An ID conflict is a merge problem.
Golden-file path mirrors the input — Bend_04.geo ↔ Bend_04.txt.
Machine 13 is the default test machine. X:\Data\Machine\13\ holds its definition.

9. The two productively important machine paths

When you want to understand machine behavior:

X:\Data\Machine\13\         ← default test BendMachine
X:\Data\Machine\99\         ← BendMachine.Default in BA.Testing mode
X:\Data\Machine\<custom>\   ← customer machines (delivered with installation)

Per machine:

Machine.curl — machine definition (mandatory)
Machine.mech — 3D mechanism (animatable)
Model\*.iges — 3D parts of the machine
BMachine.Post (a string in Machine.curl such as wad:Post/Bend/TrumpfB23.hx) — only a routing token. The basename selects a C# writer in Src\API\Bend\Post\ via Hub.GenerateNC. The legacy .hx extension is preserved for backward compatibility; the file content is not interpreted as Hex.

Note	`BendMachine` inherits from `Machine` (in `Src\Core\Model\` or similar). A bend machine is therefore a specialization. The pattern repeats for `LaserMachine`, `PunchMachine`, etc.

10. When a Bend bug arrives — 60-second triage

Symptom Likely code area First file

Symptom	Likely code area	First file
"Wrong tool selection"	Auto-tooler scoring	`Ops\BendTooler.cs` + `Ops\BendToolHint.cs`
"Wrong bend order"	Sequence optimizer or `BendTech` constructor	`Ops\BOptimizer.cs`, `BendTech.cs`
"Hem detected wrong / not at all"	Phase splitting	`BendTech.cs` lines 32—46
"Tool mounted in wrong spot"	Mount generation	`BendMount.cs`, `Ops\BendTooler.cs`
"Back-gauge position wrong"	BG placer	`Ops\BGPlacer.cs` (or `BGPlacer2X.cs`)
"Bending aid placed wrong"	BA placer	`Ops\BAPlacer.cs`
"Spurious collision warning"	Crash engine	`BendOpCrash.cs` or `NBendCrash.cs` (which is active?)
"Force/deduction value off"	Bend calc	`BendCalc.cs` (Std) or `TBSBendCalc.cs` (Trumpf)
"Robotic regrip in wrong place"	UI glob + BendOp	`Src\UI\Bend\BendOpUI.cs` lines 21—55
"GAP between tools wrong"	GAP-adjust pass	`Ops\BendGAPAdjust.cs`
"NC code wrong"	Post-processor (C# writer per dialect)	`Src\API\Bend\Post\<Dialect>.cs` (TrumpfDLD, Bystronic, LVD, …); dispatcher in `Src\API\Basis\Basis.cs:138`
"BMC/DLD export wrong"	Format exporter	`Ops\ExportBMC.cs` / `DLDExporter.cs`
"ACB sensor positioned wrong"	ACB	`BendACB.cs`
"TBS custom data not picked up"	Trumpf DB	`TBSCustomDB.cs`

"Wrong tool selection"

Auto-tooler scoring

Ops\BendTooler.cs + Ops\BendToolHint.cs

"Wrong bend order"

Sequence optimizer or BendTech constructor

Ops\BOptimizer.cs, BendTech.cs

"Hem detected wrong / not at all"

Phase splitting

BendTech.cs lines 32—46

"Tool mounted in wrong spot"

Mount generation

BendMount.cs, Ops\BendTooler.cs

"Back-gauge position wrong"

BG placer

Ops\BGPlacer.cs (or BGPlacer2X.cs)

"Bending aid placed wrong"

BA placer

Ops\BAPlacer.cs

"Spurious collision warning"

Crash engine

BendOpCrash.cs or NBendCrash.cs (which is active?)

"Force/deduction value off"

Bend calc

BendCalc.cs (Std) or TBSBendCalc.cs (Trumpf)

"Robotic regrip in wrong place"

UI glob + BendOp

Src\UI\Bend\BendOpUI.cs lines 21—55

"GAP between tools wrong"

GAP-adjust pass

Ops\BendGAPAdjust.cs

"NC code wrong"

Post-processor (C# writer per dialect)

Src\API\Bend\Post\<Dialect>.cs (TrumpfDLD, Bystronic, LVD, …); dispatcher in Src\API\Basis\Basis.cs:138

"BMC/DLD export wrong"

Format exporter

Ops\ExportBMC.cs / DLDExporter.cs

"ACB sensor positioned wrong"

ACB

BendACB.cs

"TBS custom data not picked up"

Trumpf DB

TBSCustomDB.cs

11. Exercise 1 — "Find & Explain" (30 min, read-only)

Task: in half a page, explain how a hem bend flows from geometry to the emitted Dump line.

Approach:

BendCore.cs: which EBendKind values belong to hems? (Hint: 4 of them.)
BendTech.cs lines 32—46: how is a hem flex split into two BendOps?
BendOp constructor (lines 36—54): how is mKind set for hem bends? What is OpenHemLimit?
BendSetup.Dump lines 46—62: which fields of a BendMount end up in the output?
Bonus: which test in Test\Bend\ covers the hem path? (Hint: BasicBendAuto2.Test6 is a clue.)

Rubric:

Level	Criterion
1	Finds `EBendKind.OpenHem` / `.ClosedHem` and `BendTech.cs` with the hem-phase logic
2	Can explain why a hem yields two `BendOp`s
3	Connects this to the `Dump` format and a test
4	Identifies the "hem prebend with pre-angle" edge case and locates the code path (`BendTech.cs` lines 81—88)

12. Exercise 2 — "Localize a real bug" (45 min, read-only)

Task: look at commit 4a5119dcb: "Case 45728: Changing the suction cup state no longer deletes adjusted waypoints." Answer:

Which classes were touched?
Which subsystem (Bend root, Ops\, UI, BCell)?
What was the trigger (which property setter)?
Which test covers the case?

Allowed tools: git show 4a5119dcb and Grep. Do not write any code.

This exercise trains the most important reading skill in a repo this size: derive a code path backwards from an issue number.

13. What this chapter does not cover

Fold domain (panel bender / TecZoneFold) — separate chapter, similar model but different machine kinematics (clamping beam vs. press beam).
BCell (robot cell) — separate chapter, own vocabulary (gripper, suction cups, regrip stations).
NC writers per dialect (Src\API\Bend\Post\) — each is a substantial subsystem of its own and a candidate for a dedicated chapter. Note 2004 (Hex) is historical — the postprocessors have all been rewritten in C#.
E3Plane / E3Flex geometry model — see Note 1005, separate chapter for Flux.Core\Model.
Tool-Setup-Optimizer (TSO) in detail — separate special topic (TSOBatch.cs, Ops\BOptimizer.cs).

14. If you take just one thing from this chapter

Bend is not one operation but a sequence. The sequence is produced jointly by the BendTech constructor and the BendTooler. If a bug is about ordering, tool choice, or setup partitioning, the answer is almost always in Src\Core\Bend\Ops\ — not in the root. The root holds state, Ops\ holds algorithms.

Last updated: 2026-05-04. Code paths verified against Src\Core\Bend\ and Test\Bend\. When this document disagrees with the repo, the repo wins.

Subsystem *Bend* (Press Brake)

1. TL;DR — Bend in twelve lines

2. The domain in two minutes — vocabulary of the machine world

3. The data model — class hierarchy

4. Module map — the 47 files grouped

4.1 Root Src\Core\Bend\ (24 files)

4.2 Src\Core\Bend\Ops\ (17 files — toolpath / sequencing)

4.3 UI hooks Src\UI\Bend\ (8 files)

4.4 Notes (FTex)

5. Lifecycle of a part — sequence diagram in words

6. Three canonical reading tours (15 min each)

Tour A — "How does a 3D model become a bend sequence?"

Tour B — "What does a tool setup look like internally?"

Tour C — "What does a test look like, and what is a golden file?"

7. Common stumbling blocks (observations from the code)

7.1 Two crash engines side by side

7.2 The BendTech constructor is the logic

7.3 BendOp is a partial class

7.4 Robotic bend lives in BendOp, not separately

7.5 Trumpf-specific paths

7.6 Dump format = test contract

8. Tests — how they are organized

Inventory (X:\Test\Bend\, 25 files)

The standard test pattern

9. The two productively important machine paths

10. When a Bend bug arrives — 60-second triage

11. Exercise 1 — "Find & Explain" (30 min, read-only)

12. Exercise 2 — "Localize a real bug" (45 min, read-only)

13. What this chapter does not cover

14. If you take just one thing from this chapter

Subsystem Bend (Press Brake)

4.1 Root `Src\Core\Bend\` (24 files)

4.2 `Src\Core\Bend\Ops\` (17 files — toolpath / sequencing)

4.3 UI hooks `Src\UI\Bend\` (8 files)

7.2 The `BendTech` constructor is the logic

7.3 `BendOp` is a `partial class`

7.4 Robotic bend lives in `BendOp`, not separately

Inventory (`X:\Test\Bend\`, 25 files)