Below is the topic write-up for Axis & Coordinate Systems, aligned with your Domain 1 source of truth, where Topic 3 is defined as axes (X, Y, Z, rotation), coordinate systems, and absolute vs relative positioning.
Axis & Coordinate Systems
This topic looks simple on the surface. Everybody sees X, Y, Z and thinks, “That is just position.”
But in real industrial machine software, this is one of the places where software stops being abstract and starts touching physical reality in a very unforgiving way.
A bad business system might show the wrong number in a report. A bad coordinate model can move a stage to the wrong place, crash a tool into a fixture, inspect the wrong wafer location, or quietly produce bad data for hours.
So the right mental model is this:
An axis is not just motion hardware.A position is not just a number.A coordinate is only meaningful inside a named reference frame.
That is the heart of this topic.
PART 1 — WHAT IS AN AXIS IN SOFTWARE
At the software level, an axis is a controllable degree of movement.
That movement may be:
- linear, like X / Y / Z
- rotational, like Theta
- sometimes virtual, derived, or mapped from multiple physical components
So when software says “Axis X,” it is not really talking about a motor. It is talking about a motion capability with a defined meaning.
1.1 Axis as an abstraction
A software axis usually represents:
- a name
- a motion direction or meaning
- a unit
- limits
- a current position
- a target position
- a coordinate role in the machine
That means the software concept of axis is already one level above raw hardware.
For example:
- a servo motor drives a stage
- an encoder reports feedback
- a motion controller closes the loop
- software exposes that as StageX
From software’s perspective, the important thing is often not the motor identity. The important thing is:
- what this axis means physically
- where it can go
- what units it uses
- what subsystem owns it
- how it participates in machine-level positioning
1.2 A logical axis is not always a single motor
This is where new engineers often oversimplify.
A logical axis may map to:
- one motor
- one motor plus encoder feedback
- multiple motors mechanically linked
- a robot controller joint
- a calculated axis exposed by another subsystem
So software should not assume:
one axis = one motor object
That assumption becomes a design trap.
In a wafer stage system, “X” may indeed feel like one clean physical stage axis. In a more complex machine, one logical motion may depend on:
- gantry compensation
- master/slave mechanics
- transformed coordinates
- tool center point logic
Software still wants a stable abstraction.
1.3 Two practical examples
Example A — Wafer stage X/Y
A wafer inspection machine often has a stage that moves the wafer under optics.
Software thinks in terms like:
- StageX
- StageY
- maybe StageTheta
- maybe FocusZ
It does not want every workflow to care about motor channels, encoder registers, or low-level controller naming.
It wants to say:
- move to inspection point
- align to feature position
- step to next die
- return to load position
That only works when axes are modeled as meaningful machine abstractions.
Example B — Robot joint
A robot arm may expose:
- Joint1
- Joint2
- Joint3
- WristTheta
But at the application layer, engineers often care more about:
- pick position
- place position
- safe transfer pose
- tool pose
So the low-level axis abstraction is necessary, but not sufficient. You need it as a building block for higher-level positional reasoning.
1.4 Axis layout diagram
+Z
^
|
|
|
O --------> +X
/
/
v
+Y
O = machine reference origin
X, Y, Z = linear axes
Theta = rotation around an axis (often around Z in 2D stage systems)What this diagram means
This is the simplest mental model: the machine defines directions of motion relative to a chosen origin.
But the important software lesson is this:
- the machine must define what X means
- the machine must define what positive direction means
- the machine must define where zero is
- all subsystems must agree
If one subsystem thinks +X is right and another thinks +X is left, you do not have a math problem. You have a machine problem.
PART 2 — COORDINATE SYSTEMS
An axis defines movement directions. A coordinate system defines how positions are expressed relative to a reference.
This is where many bugs begin.
Because a number like:
- X = 125.4
means nothing by itself.
You must also ask:
- 125.4 in which frame?
- measured from which origin?
- using which orientation?
- in what unit?
2.1 Machine coordinate system
The machine coordinate system is the global reference frame used by the machine.
This is often tied to:
- home positions
- base mechanical structure
- stage reference origin
- controller-level axis coordinates
It is the frame that gives the machine a stable global sense of space.
For example:
- X = 0, Y = 0 may be near home
- or at a machine-defined mechanical reference point
- or at a calibrated production origin
The exact choice varies, but the key idea is consistency.
2.2 Local coordinate system
A local coordinate system is a reference frame defined relative to something else.
Examples:
- camera image coordinates
- workpiece coordinates
- wafer coordinates
- tool coordinates
- fixture coordinates
Why do these exist?
Because different subsystems naturally “see” the world differently.
A camera may detect a feature in its own field-of-view coordinates. A wafer map may define die positions relative to wafer center. A tool head may have an offset from the stage center. A recipe may specify motion targets relative to a fixture origin.
All of those are valid. But they are not the same frame.
2.3 Machine vs local coordinates diagram
+------------------------------------------------------+
| MACHINE COORDINATE SYSTEM |
| |
| Origin M(0,0) |
| O---------------------------------------> +X |
| | |
| | |
| | [ Workpiece ] |
| | L(0,0) |
| | o-----> +Lx |
| | | |
| | | |
| v v +Ly |
| +Y |
| |
+------------------------------------------------------+What this diagram means
The machine has a global frame. Inside that machine, a workpiece or local subsystem may define its own origin and directions.
So a point may be:
(X=300, Y=120)in machine coordinates(Lx=12, Ly=8)in workpiece coordinates
Both may refer to the same physical location.
This is why industrial software must manage coordinate systems explicitly instead of passing around raw tuples.
2.4 Why multiple coordinate systems are necessary
Because real machines are composed of subsystems.
A few examples:
- motion controller thinks in axis coordinates
- vision system thinks in image or calibrated stage coordinates
- recipe thinks in process coordinates
- tooling thinks in tool-relative offsets
- operator may think in product-relative coordinates
If the software forces everything into one hidden implicit frame, the code becomes fragile. It may work for one machine configuration, then fail when:
- camera is replaced
- fixture changes
- recipe origin changes
- stage is recalibrated
- product size changes
- axis direction is configured differently
The professional approach is not to avoid multiple frames. It is to model them clearly.
2.5 Coordinate transformation diagram
[ Camera Coordinates ]
|
| transform: camera -> stage
v
[ Stage / Machine Coordinates ]
|
| transform: machine -> workpiece
v
[ Workpiece Coordinates ]What this diagram means
Subsystems often communicate through transformations.
For example:
- Camera finds a feature at pixel-relative or camera-relative location
- Software converts that into stage coordinates
- Workflow converts that into workpiece-relative action
Even when the math is simple, the architecture matters. A hidden transform buried in random code is a future production bug.
PART 3 — ABSOLUTE VS RELATIVE POSITIONING
This is one of the most important operational distinctions in motion software.
3.1 Absolute positioning
Absolute move means:
go to a named target position in a known coordinate frame
Examples:
- move X to 100 mm
- move stage to
(250, 80) - move Theta to 0 degrees
This is stable and predictable if the current reference frame is valid.
Absolute moves are often used when:
- going to taught positions
- moving to recipe-defined locations
- aligning to machine-defined stations
- returning to safe or home-related positions
3.2 Relative positioning
Relative move means:
move by an offset from the current position
Examples:
- move X by +10 mm
- move Y by -2 mm
- jog Theta by +1 degree
Relative moves are useful when:
- nudging position
- manual jogging
- small correction steps
- iterative search or alignment loops
- stepping through repeated patterns
3.3 Why the distinction matters
Because absolute moves assume the reference is trustworthy. Relative moves assume the current position is trustworthy.
That sounds subtle, but in real systems it matters a lot.
If homing is invalid, an absolute move may go to the wrong real-world location. If current position is stale or drifted, a relative move may compound the error.
3.4 Absolute vs relative diagram
Axis X
---------------------------------------------------------------->
0 50 100 150 200
Current position: 90
Absolute move to 150:
90 ------------------------------------> 150
Relative move +10:
90 ---------> 100What this diagram means
The command syntax may look small, but the operational meaning is very different.
A common production failure is that an engineer assumes:
- “move to 10” and
- “move by 10”
are interchangeable in some context.
They are not.
3.5 Typical misuse patterns
Misuse 1 — Relative move in a loop with bad reset assumptions
A workflow intends to inspect points spaced 5 mm apart.
Instead of computing each target from a known reference, it does repeated relative moves:
- +5
- +5
- +5
- +5
If one step is skipped, retried, or interrupted, the accumulated position can drift from the intended inspection pattern.
Misuse 2 — Absolute move using wrong coordinate frame
A vision module reports a local offset, but the motion command interprets it as machine coordinates.
Now the stage moves to a real absolute machine position that happens to match the local value numerically, but not physically.
That can be catastrophic.
Misuse 3 — Switching between operator jog and automatic positioning without state discipline
Manual relative jogs may leave the machine at unexpected locations. If auto mode assumes the machine is still at a known reference, the next absolute move may not do what the workflow designer expects.
PART 4 — POSITION REPRESENTATION
Position in machine software is usually represented as values such as:
- millimeters
- micrometers
- encoder counts
- degrees
But the key issue is not just storage. It is semantic correctness.
4.1 Position is not just a number
A usable position value really includes:
- magnitude
- unit
- axis or dimensions
- coordinate frame
- precision rules
- validity assumptions
A plain double is often not enough at architectural boundaries.
Because these are very different things:
12.5 mm in MachineFrame12.5 deg in ThetaAxis12.5 pixels in CameraFrame12.5 encoder counts in ControllerSpace
Numerically similar. Semantically completely different.
4.2 Units matter more than people expect
In machine systems, unit mistakes are not theoretical.
Real examples of things that go wrong:
- recipe stores millimeters, controller expects micrometers
- vision reports pixels, motion expects millimeters
- rotation uses degrees in one layer, radians in another
- legacy subsystem exposes counts, UI displays converted millimeters, logic accidentally mixes both
The system may still compile. It may even move. That is what makes these bugs dangerous.
4.3 Precision and rounding
Industrial positioning often relies on repeated calculations and conversions.
That introduces practical issues such as:
- floating-point rounding
- repeated unit conversion loss
- formatting precision hiding actual state
- controller resolution not matching software resolution
Example:
- UI shows
10.000 mm - controller can only reach
10.002 mm - workflow repeatedly compares exact values
- software decides axis “has not reached target” or keeps correcting unnecessarily
So software engineers need to think carefully about:
- tolerance
- representation precision
- display precision vs control precision
4.4 Position value model example
A healthier design is something conceptually like this:
Position2D
- X = 125.300
- Y = 48.700
- Unit = mm
- Frame = WaferFrameThis is much safer than passing raw tuples everywhere.
Because once the frame and unit are attached, many classes of bugs become harder to create silently.
PART 5 — MULTI-AXIS POSITIONING
Single-axis thinking is useful for learning, but real machines often position in combinations:
(X, Y)(X, Y, Z)(X, Y, Theta)- or more complex sets
5.1 A position is often a vector of coordinated axes
From software’s perspective, a machine position is often a structured object rather than a collection of independent commands.
For example:
- wafer inspection point =
(X, Y, Theta) - focus position =
Z - transfer pose =
(X, Y, Z, Theta)
The reason is simple:
the machine usually cares about where the mechanism is as a whole, not just each axis separately.
5.2 Why axes cannot always be treated independently
Because real-world behavior is coupled.
Examples:
- moving X may only be safe when Z is raised
- rotating Theta may require X/Y to be inside a safe zone
- stage positioning for imaging may require X and Y to settle together
- one axis may be mechanically or procedurally constrained by another
So even when the controller exposes independent axis channels, the application often must reason about combined poses.
5.3 Multi-axis positioning diagram
Top View of Stage
+Y
^
|
|
| Target P2 (120, 80)
| *
|
|
| Current P1 (40, 30)
| *
|
+---------------------------------> +XWhat this diagram means
At the application layer, the important object is often not “X then Y.”
It is:
move from pose P1 to pose P2
That may still be implemented internally through separate axis commands, but the software model should preserve the combined intent.
5.4 Coordinated movement as a software concept
Even without going deep into motion execution details, one key architectural idea matters:
multi-axis target definition and multi-axis safety validation should be centralized
Why?
Because if every subsystem independently manipulates X, Y, Z without a shared positional model, you get:
- hidden assumptions
- inconsistent safety checks
- impossible-to-debug coordinate bugs
- race conditions between subsystems
A mature machine codebase usually has explicit concepts such as:
- machine pose
- target pose
- frame-aware positions
- safe move validation
- ownership of coordinate conversions
PART 6 — REAL-WORLD PROBLEMS
This is where coordinate systems stop being theory and become production pain.
6.1 Coordinate mismatch between subsystems
What happens
A vision subsystem returns a detected position in camera-local coordinates. The motion subsystem interprets it as machine coordinates.
The numbers may look reasonable. The move may even complete successfully. But the stage goes to the wrong physical place.
Why it is dangerous
Because this bug often does not look dramatic at first.
Instead you see:
- feature missed by a small amount
- repeated alignment retries
- inspection shifted from expected region
- “sometimes works, sometimes does not”
This is worse than a clean crash because it can produce silent bad output.
6.2 Incorrect origin
What happens
Software assumes zero is one physical reference point, but after maintenance, calibration change, or configuration update, zero is now somewhere else.
Absolute positions still look valid numerically, but they map to different physical locations.
Why it is dangerous
Because absolute positioning becomes false-confidence positioning.
The system thinks:
- “I am at X=100”
But that only matters if X=100 still means what everyone thinks it means.
6.3 Wrong axis mapping
What happens
Configuration or code maps:
- logical X to physical Y
- positive direction reversed
- theta sign flipped
- stage axis names swapped
This can happen during machine variant setup, controller mapping changes, or refactoring.
Why it is dangerous
Because the machine still moves. Just incorrectly.
And once motion is physically plausible but semantically wrong, debugging becomes much harder.
Common symptoms:
- jog right moves forward
- scan pattern mirrored
- camera correction makes error worse
- alignment diverges instead of converging
6.4 Relative move applied incorrectly
What happens
A relative correction is applied twice, or applied after the system state changed but before the assumption was refreshed.
For example:
- operator jogs axis
- workflow resumes
- old relative offset is applied again
- now position is shifted unexpectedly
Why it is dangerous
Relative moves compound with state drift.
They are convenient, but they rely heavily on correct current-state knowledge.
6.5 Unit conversion errors
What happens
One layer uses mm, another uses µm, another uses counts.
A conversion is missing, duplicated, or inverted.
Examples:
- 10 mm becomes 10 µm
- 10,000 µm becomes 10,000 mm
- counts are displayed as engineering units without scaling
Why it is dangerous
Because the result may be:
- tiny move when large move expected
- huge move when tiny correction expected
- false position display
- limits violated unexpectedly
This is one of the classic “simple bug, expensive consequence” categories.
PART 7 — SOFTWARE DESIGN IMPLICATIONS
This topic has major architectural consequences.
7.1 Coordinate ownership must be explicit
Every important position should have a clear owner for:
- frame definition
- origin meaning
- unit definition
- conversion responsibility
- validity conditions
Do not let coordinate meaning float across the codebase.
For example:
- vision module may own camera-frame outputs
- motion service may own machine-frame commands
- alignment service may own conversion between them
That separation is healthy.
7.2 Hidden transformations cause bugs
One of the worst design patterns is silent transformation inside convenience methods.
For example:
- caller passes local coordinates
- helper silently converts to machine coordinates
- another helper silently applies tool offset
- motion layer silently applies calibration offset
Now nobody knows what frame the number is in anymore.
This creates exactly the kind of bugs that waste days on real machines.
Better approach:
- name frames explicitly
- convert at clear boundaries
- keep transformation paths visible in code and logs
7.3 Units should be consistent and boring
You want the system to be very boring about units.
That means:
- define canonical engineering units
- convert at boundaries, not everywhere
- avoid raw numeric ambiguity
- include units in logs, models, and APIs where practical
If the system uses mm internally, that should be a deliberate standard, not an accident.
7.4 Position types should carry meaning
Good machine software often benefits from domain-specific types such as:
AxisPositionStagePosition2DPose3DMachineCoordinateWaferCoordinateCameraCoordinate
Even if these are lightweight, they communicate meaning.
A raw tuple like (double, double) is cheap in code, but expensive in debugging.
7.5 Logging must include frame context
When diagnosing motion issues, logs like this are weak:
Move to X=125 Y=80Logs like this are far better:
Move to StagePosition(X=125.000, Y=80.000, Unit=mm, Frame=MachineFrame)Because real debugging is often about semantic mismatch, not syntax mismatch.
7.6 Validation should happen before move submission
Before issuing a move, software should be able to answer:
- which frame is this target in?
- is conversion required?
- is the frame valid right now?
- are units correct?
- is the resulting target inside allowed travel?
- is this pose safe with current subsystem state?
That is how software prevents coordinate bugs from becoming hardware incidents.
PART 8 — INTERVIEW / REAL-WORLD TALKING POINTS
Here is a clean way to explain this topic in an interview or architecture discussion.
8.1 How to explain coordinate systems clearly
You can say:
In machine software, position is never just a number. It only has meaning inside a coordinate frame. Different subsystems such as motion, vision, tooling, and recipes often use different frames, so the software must model those frames explicitly and control how transformations happen between them.
That is simple, practical, and strong.
8.2 Why axis abstraction matters
You can say:
An axis in software is a logical movement capability, not just a motor. Good software abstracts motion in terms the machine workflow understands, while still preserving the underlying constraints, units, and safety semantics.
That shows architectural maturity.
8.3 Common mistakes engineers make
A strong list is:
- passing raw numeric positions without frame context
- mixing units across layers
- hiding coordinate transforms in helper methods
- assuming one axis always maps cleanly to one hardware device
- using relative moves where absolute intent should be preserved
- logging target values without units or frame names
- letting multiple subsystems independently own coordinate interpretation
8.4 A concise real-world summary
You can say:
Coordinate bugs are dangerous because they often look like small numeric mistakes, but they create real physical misbehavior. The key defense is explicit modeling: name the axes clearly, define frames explicitly, standardize units, and make transformations visible at subsystem boundaries.
That is the right professional instinct.
Final Mental Model
If you remember only a few things, remember these:
1. An axis is a software abstraction of controllable movement
Not just a motor. Not just a register. A meaningful movement capability in the machine.
2. A position only makes sense inside a coordinate system
A raw number is incomplete.
3. Absolute and relative moves are operationally different
They rely on different assumptions and fail in different ways.
4. Multi-axis motion should be modeled as machine pose, not scattered axis values
That is how you preserve system meaning.
5. Most coordinate bugs come from hidden assumptions
Wrong frame, wrong origin, wrong axis mapping, wrong unit, wrong transform boundary.
6. Good machine software makes coordinate meaning explicit
Explicit frames. Explicit units. Explicit ownership. Visible transformations.
That is what keeps positioning software understandable, testable, and safe.
If you want, I can continue with the next topic in the same style: 4. Motion Execution & Behavior.