Shape tables & tooling configuration
The shape table is Eclipse's model of one machine's punching hardware: its presses, the tools mounted on them, the named shapes those tools can produce, and the axes that position them. When a pattern is solved for a machine, this is the table its shape codes are matched against — a shape the table doesn't have is a shape that machine can't punch.
It lives on the XL machine's detail page, on the Shape Table tab (shown when shape punching is enabled for your system). Each machine has its own; the same shape code can map onto completely different presses and tools from one machine to the next, which is exactly what makes shape punches portable.
Creating a shape table
A machine without one shows "No shape table defined." and a Create button, with two starting points:
- From Machine Configuration — seeds presses, tools, and axes from the machine's controller tool and axis configuration (which Eclipse keeps synced), and creates one shape per tool, named after the tool number. This gets a real machine's table 90% written; you then rename the shapes to your shape codes and fill in the details.
- Empty — start from nothing.
The shape table is owned and edited in Eclipse from then on. The controller's tool/axis configuration is only a seed — later controller changes don't overwrite your table.
Table properties
The header shows, and the Edit shape table properties dialog edits:
| Property | Meaning |
|---|---|
| Kerf | The machine's kerf allowance. |
| Tolerance | Position tolerance the solver may use when matching operations. |
| Machine Ref | The machine's Y reference convention — Center, MinusEdge, or PlusEdge: where the controller measures Y positions from. |
Presses, tools, and shapes
Each press gets its own tab, with its Dwell Up / Dwell Down times and two grids:
- Tools — the physical hardware on the press: Tool Id, Tool Name, X Offset and Y Offset (the tool's position), Gag, and the Axis that moves it (or none for a fixed tool).
- Shapes — what the press can produce: each row maps a shape code (Current Shape) onto a Tool Id, with its own X Offset / Y Offset relative to the tool and an R. This is the row a pattern's shape code matches.
R is the tolerance the solver matches positions within — it is not the size of the hole and it does not affect any drawing. What the hole actually looks like comes from the shape geometry library.
The tool–shape relationship runs many-to-one in both useful directions:
- Several shapes can share one tool. The same physical punch can produce different named shapes at different offsets — one tool, many shape rows.
- The same shape code can appear on several rows (even on different presses). Those are alternative ways to produce that shape; the solver picks whichever works for the part. For one shape name that means several holes punched together, use the shape alias table instead.
A shape's tool must exist on the same press, tool ids must be unique, and every shape needs a positive R — the editor validates as you go and lists problems under Errors.
The shape geometry library
The shape table says where a shape is punched. What the hole looks like is described
separately, in the shape geometry library: one table shared by every machine, on the
Shapes page (under Punch Patterns), on its Shapes tab. Shape codes are a site-wide
convention — RND250 is the same die wherever it appears — so the geometry is defined once, not
per machine.
Each row describes one machine shape code:
| Field | Meaning |
|---|---|
| Shape Code | The machine shape code this geometry describes — the code as it appears in a machine's shape table, not an alias name (aliases resolve to real codes first, and the code is what gets drawn). One row per code. |
| Kind | Round, Rounded slot, Square, Square slot, or Triangle. |
| X | Extent along the strip: the diameter of a round, the side of a square, the base width of a triangle, the X extent of a slot. |
| Y | Extent across the strip — slots and triangles only (a round or square uses X for both). A slot's orientation falls out of the two extents: 1.5 × 0.5 runs along the strip, 0.5 × 1.5 across it, with the rounded ends always capping the long axis. |
| Direction | Triangles only: which way the apex points across the strip, with the die as it is physically mounted. A tooling code's Flip Y flips the apex along with the hole's position. |
| Description | A note for operators; not used for anything else. |
A thumbnail on each row previews the shape as entered. Eclipse flags a duplicate shape code, and warns about a code that doesn't exist in any machine shape table (harmless — usually a typo or a machine not configured yet).
Nothing in this table changes what is punched: it is not read when a pattern is solved, and saving it does not re-solve anything. It exists so the flat view, the 3D formed view, and the machine layout visualizer can draw and cut true hole outlines instead of a generic dot. A code with no entry still draws — as a fixed-size dashed marker, which is the drawing's way of saying it doesn't know the real size.
The shape alias table
Machine shape tables describe what one machine punches. The Shape Alias Table — a single table shared by all machines, on the Shape Aliases tab of the same Shapes page — adds a layer of naming on top: an alias is a shape code that patterns can use, standing for one or more real shapes.
Each row maps an Alias Name to one Shape Name, plus an X Offset / Y Offset. An alias means all of its rows: to make one name punch several hits, repeat the alias name on several rows. A pattern punch using the alias expands at solve time into one punch per row, each row's offsets added on top of wherever the punch itself lands — in the punch's own X/Y reference frame, so a cluster keeps its arrangement whether the punch is edge-, center-, or segment-referenced.
Points worth knowing:
- Patterns keep the alias name. Expansion happens when the pattern is solved, not when it
is written — correcting an alias row fixes every pattern that uses it, and edits re-solve
affected patterns automatically. The punch editor shows what an alias resolves to right on
the row ("This alias resolves to: …", with repeats shown as
RD500 (x3)). - Matching is by whole name — case-insensitive, like shape codes everywhere else. There are no wildcards.
- The resolved shape names still have to exist on the target machine's shape table — a machine missing one fails with the usual missing-shape alert, same as any shape it doesn't have.
- If a name is both an alias and a machine shape code, the alias wins. Avoid overlapping the two namespaces.
- Per-tooling-code flips match the code the pattern wrote — the alias name — so all of an alias's hits flip together as a unit.
This is a different table from Segment Aliases,
which is per machine and maps a design system's segment names (Flange Left, …) onto profile
segments. The shape alias table is global and maps shape codes onto shapes.
Axes
The Axes tab describes the machine's positioning axes: Axis Id, Type (Auto — positioned by the solve — or Manual — sits at a fixed Manual Pos), the travel limits Max Y / Min Y, the Opposing Axis if it works against another, and its Crash Surface.
The machine layout visualizer
The eye icon in the tab header ("Visualize machine layout") opens the Machine Layout view: a true-scale plan drawing of every press, axis travel envelope, tool, and shape at real machine coordinates — X measured from the shear, Y from the machine centerline. A mis-entered offset (a shape sitting on top of its tool, a tool outside its axis's travel) is immediately visible, and hovering anything shows its numbers.
Shapes are drawn at their true outline where the shape geometry library knows the code, and as a plain dot where it doesn't — so the drawing shows how much room a slot or a triangle really takes on the strip.
The toolbar pans and zooms, and Stretch X / Stretch Y let you widen a long, thin machine without losing true scale (Fit to view restores it). The same view is available from the machine's Tools and Axes tabs, where it draws the live controller configuration (without shapes).
Machine orientation
The Flow and + side toggles on the Machine Layout and Flat View toolbars record how the machine physically sits: which way the part travels as seen from the operator side, and whether machine + is the far side or the near side. It is a per-machine setting shared by everyone — set it once and every drawing (machine layout, flat view, 3D formed view) is oriented the way people actually see the machine. It affects drawings only; it never moves a punch.
Tooling Code Options
The Tooling Code Options tab configures behavior per tooling code — the profile being
run. Each entry has a Tooling Code Pattern with wildcards (ABC exact, ABC* starts
with, *ABC ends with, *ABC* contains); when a job's tooling code matches several entries,
the most specific one wins. An entry carries:
- Manual Axis Positions — where each Manual-type axis should sit when this tooling is loaded. Only axes whose Type is Manual can be listed here.
- Strip Offset — this tooling runs with the strip shifted this far toward machine +. The controller stays unaware of the shift: Eclipse solves against the shifted strip and adds the offset back onto every position it sends. When it's nonzero, the flat view annotates the drawing with a Strip offset chip and a Machine center guide showing where machine Y 0 falls on the strip.
- Shape-Specific Flip Options — see below.
Shape flips and offsets
Design software draws a part in its assumed orientation; the machine may run the profile the other way around. The Shape-Specific Flip Options rows absorb that difference per shape code, per tooling code:
| Field | Effect |
|---|---|
| Shape Code | Which shapes the row applies to — wildcards as above, case-insensitive, * for all. Matched against the shape code as the pattern wrote it. |
| Flip X | Mirrors the punch's position end-for-end (leading ↔ trailing). |
| Flip Y | Mirrors the punch's position across the strip center (machine + ↔ −). |
| X Offset / Y Offset | Added after the flip. |
Rows are checked top to bottom and the first matching row wins — order matters, which is
what the Move up / Move down buttons are for. Put specific shape codes above a *
catch-all.
Flips are configured per shape name, so a shape name implicitly carries the drawing orientation of the software that sends it. If a second design system draws the same hole in a different orientation, give it a different shape code rather than sharing one.
Tooling code patterns
Some punches belong to a profile rather than to the part being ordered — a pair of triangles on a ZEE whose positions follow the leg heights, for instance. Putting them in every order's pattern is error-prone; the Tooling Code Patterns tab attaches them to the tooling code instead.
Each rule is a Tooling Code wildcard (Z8X14 exact, Z8*, *14, * for every code — the
same dialect as the Tooling Code Options tab) and an Added Pattern: an existing permanent,
non-macro pattern whose punches ride along with every job whose tooling code matches. A
Description documents why the rule exists.
- Only one rule applies — the most specific match wins, and the others are ignored. Rules do
not stack, so a
*catch-all under aZ6*rule can't quietly double up holes. - Shape punches in the added pattern are solved with the rest of the pattern. Eclipse picks the press and tool, checks clearances against every other hole, and positions them in the tooling code's own frame. Because the solver orders the operations, adding a shape rule can renumber the operations already there.
- Tool and macro punches are added after the solved punches, exactly as entered, in machine coordinates. Existing sequence numbers hold, but nothing is checked for you — including the tooling code's strip offset, which is not applied to them.
- Where the feature exists as a shape code on the machine's shape table, author it as a shape punch: the solver then owns the tooling, the clearance checking, and the frame.
- Only permanent, non-macro patterns can be chosen, and the choice is validated when you
save. If the pattern is deleted later, matching jobs fail to solve with
ToolingCodePatternNotFoundrather than silently losing punches the profile needs.
Saving the tab re-solves that machine's cached solutions, and so does editing a pattern any rule points at. Rules travel with the Shape Table option of a machine configuration backup; on restore, a rule naming a pattern the target server doesn't have is skipped with a warning rather than restored broken.
Part Printing — on its own tab in the same editor — does the same thing keyed on part length instead of tooling code. The two are independent and both still apply.
Tooling dimensions
The dimensions that describe the profile a tooling code forms — Fin Width, Leg Height, and Leg Height 2 — live on the Tooling page, per machine entry, not on the shape table. They're what segment references resolve against, and what the flat view, the 3D formed view, and the commissioning worksheet read. A blank or zero Leg Height 2 means a symmetric profile (both flanges use Leg Height). The tooling page highlights these values when machines disagree about the same tooling code.
The Segments tab
The shape table editor's Segments tab holds the segment configuration — the Segment Aliases table, the Segment Geometry Corrections table, and the Commissioning Worksheet. Those have their own pages; note that saves on the Segments tab are independent of the shape table's own save button.
Saving and re-solving
Saving the shape table re-solves the machine's affected cached solutions automatically — the same behavior as edits to the segment tables. There is no separate "recalculate" step.