Below is a deep dive on Motion Safety & Limits, aligned to your Domain 1 source of truth: this topic covers homing and reference positions, hard limits, soft limits, and safe travel zones, and sits inside the broader principle that machine software must respect physical constraints and validate all motion before execution.

---

PART 1 — WHY MOTION SAFETY IS CRITICAL

In business software, a bad command usually throws an exception, corrupts data, or causes a failed workflow.

In machine software, a bad motion command can bend hardware, crack tooling, destroy a part, break calibration, or create a collision that takes hours or days to recover from.

Trong phần mềm điều khiển máy, một lệnh chuyển động sai có thể làm cong vênh phần cứng, nứt vỡ dụng cụ, phá hỏng sản phẩm, làm mất hiệu chuẩn, hoặc gây ra va chạm mà phải mất hàng giờ hoặc thậm chí vài ngày mới có thể khắc phục.

That is the first mental shift.

Motion safety exists because software is commanding mass through space. The machine has real geometry, real inertia, real hard stops, real cable travel, real fixtures, and real zones where movement is unsafe. The software must act as if every motion command is potentially dangerous until proven otherwise.

A few classic examples:

• A linear stage moves beyond its intended range and slams into a mechanical stop.
• A Z-axis descends before the chuck is clear and hits the workpiece.
• A robot arm rotates while another axis is in the wrong position and collides with the frame.
• A gantry believes it is at X = 120.000, but after restart its true physical position is unknown, so the next “safe” move is actually unsafe.

The important architect-level point is this:

Unsafe motion is usually not caused by one single mistake. It often comes from a chain of assumptions:

• position was trusted when it should not have been
• homing was skipped or incomplete
• limits were misconfigured
• a permissive check happened in one code path but not another
• a manual command bypassed central validation
• a stale state snapshot was treated as truth

So from a software perspective, motion safety is not “just add limit switches.”

It is a system-level discipline:

• establish a trusted reference
• define allowed travel boundaries
• validate every target
• continuously monitor execution
• centralize permission logic
• fail conservatively when position trust is lost

---

PART 2 — HOMING & REFERENCE POSITION

What homing is

Homing is the process of making an axis establish a trusted positional reference.

When the machine first powers on, the controller may know:

• the drive is alive
• the encoder is responding
• the motor can be enabled

But it still may not know where the axis physically is.

That distinction is critical.

An axis can be:

• Powered on: electronics active, servo enabled, drive ready
• Position-valid / homed / referenced: software trusts the coordinate system origin or reference point

Those are not the same thing.

A powered axis without a trusted reference is like having a GPS that is on but has not locked onto location yet. Motion may be physically possible, but safe absolute positioning is not yet valid.

Why homing is required

Software needs a known relationship between:

• physical machine location
• controller position counter
• machine coordinate system

Without that relationship:

• soft limits are meaningless
• absolute moves are unsafe
• keep-out zones cannot be trusted
• recipes using saved positions are dangerous

In practice, homing tells the system:

“This physical point corresponds to this logical reference. From here onward, absolute position can be trusted.”

Typical homing sequence

The exact method varies by hardware, but the common pattern is:

1. move slowly toward a known reference direction
2. detect a home sensor or reference marker
3. optionally continue to find encoder index
4. back off and re-approach for repeatability
5. set logical position value
6. mark axis as homed / referenced

Here is a simple UML-style ASCII sequence.

Homing sequence diagram

Operator        Machine SW        Motion Controller        Axis / Sensors
   |                 |                    |                      |
   |  Home Axis      |                    |                      |
   |---------------->|                    |                      |
   |                 | Check preconditions|                      |
   |                 |------------------->|                      |
   |                 |<-------------------| Ready                |
   |                 |                    |                      |
   |                 | Start homing       |                      |
   |                 |------------------->| Move toward home     |
   |                 |                    |--------------------->|
   |                 |                    |                      |
   |                 |                    |<---------------------|
   |                 |                    | Home sensor seen     |
   |                 |                    |                      |
   |                 |                    | Find index / settle  |
   |                 |                    |--------------------->|
   |                 |                    |<---------------------|
   |                 |                    | Reference locked     |
   |                 |                    |                      |
   |                 | Read result        |                      |
   |                 |<-------------------| Homed, position = 0  |
   |                 | Mark axis homed    |                      |
   |<----------------| Homing complete    |                      |

What experienced engineers care about in homing

They do not just ask “did homing finish?”

They ask:

• was the correct homing method used for this axis?
• was the reference repeatable?
• did the home sensor chatter?
• was the encoder index found?
• do we trust the result after power recovery?
• can the axis be moved manually without invalidating home?
• does this axis require re-homing after drive fault or brake release?

That is the real-world view.

Homing is not a startup ritual. It is the act of establishing position trust.

---

PART 3 — HARD LIMITS VS SOFT LIMITS

Hard limits

Hard limits are physical end-of-travel protections, usually implemented with:

• hardware switches
• sensor inputs
• controller-level protection inputs
• physical stop geometry behind the switch

They are the last line of defense, not the normal operating boundary.

When a hard limit is hit, it usually means something has already gone wrong:

• commanded position exceeded allowed range
• soft limits were missing, wrong, or bypassed
• home reference was wrong
• operator jogged too far
• controller state and software state diverged

Hard limits are necessary because software can be wrong.

Soft limits

Soft limits are software-defined travel boundaries based on the trusted coordinate system.

Example:

• allowable axis range: X = 0.0 to 500.0 mm
• software refuses any command outside that range
• controller may also reject target positions outside configured limits

Soft limits are the normal operating protection.

They are intended to stop unsafe moves before motion begins, not after the machine is already in danger.

How they work together

The right mental model is:

• soft limits prevent bad commands during normal operation
• hard limits protect the machine when something abnormal still happens

You do not want normal operation to ever reach a hard limit.

Constraint diagram: safe range vs hard stops

Physical travel direction  --------------------------------------------->

   [Mechanical Stop] [Hard Limit] |----- Soft Limit Safe Range -----| [Hard Limit] [Mechanical Stop]
                                   ^                                 ^
                                   |                                 |
                                Min soft                          Max soft
                                boundary                          boundary

Example:
Mechanical range:   -5 mm ................................. 505 mm
Hard limit region:   0 mm ................................. 500 mm
Soft operating range: 10 mm ............................... 490 mm

Why leave margin between soft and hard limits?

Because real machines are not ideal.

You need margin for:

• deceleration distance
• servo following error
• overshoot
• calibration drift
• encoder quantization / noise
• mechanics settling
• parameter mistakes
• controller update timing

A well-designed machine does not set soft limits exactly at the hard limit sensor location.

It leaves room.

Architect-level rule

If your software relies on hard limit events as part of normal motion logic, the design is already unhealthy.

Hard limits should be treated as:

• abnormal
• safety-relevant
• requiring controlled recovery

not as:

• normal positioning references during production moves
• routine stop mechanisms
• acceptable end-state events

---

PART 4 — SAFE TRAVEL ZONES

Soft limits protect the outer travel range of an axis.

But real machines often need something more detailed: safe travel zones.

What a safe travel zone is

A safe travel zone is an allowed region of motion under specific conditions.

That region may depend on:

• current operating mode
• other axis positions
• fixture/tool presence
• whether clamps are open/closed
• whether a camera or probe is lowered
• whether the machine is in maintenance mode
• whether a robot arm is inside a shared space

So the real question is not always:

“Is X inside min/max?”

It is often:

“Is this target safe given the current machine geometry and context?”

Types of zones you see in real systems

1. Full allowed range

Normal travel area where the axis can move freely.

2. Reduced safe range

Allowed only when another subsystem is in a safe state.

Example:

• Z-axis may descend only if X/Y stage is parked
• robot may rotate only if door is closed and lift is up

3. Keep-out zone

A forbidden region.

Example:

• camera head must never enter chuck clearance area during manual jog
• robot wrist must not sweep through load port space unless transfer sequence owns that region

4. Maintenance-only zone

Area accessible only in service mode, at low speed, often with extra confirmation.

Constraint diagram: travel zones

Axis X travel
-------------------------------------------------------------------------------->

|-- Forbidden --|------ Allowed in Service Only ------|---- Normal Safe ----|-- Forbidden --|

0              40                                    100                   420            460

Rules:
- 0..40      : keep-out area
- 40..100    : accessible only in maintenance mode
- 100..420   : normal operating range
- 420..460   : keep-out area near structure / cable limit

Why zones exist

Because machine safety is rarely only about one axis.

It is about spatial relationships.

A stage may be safe at X = 450 only if:

• Z is retracted
• vacuum chuck is empty
• tool head is parked
• door is closed
• maintenance mode is off

This is why experienced engineers think in constraints, not isolated axis commands.

---

PART 5 — MOTION PERMISSION CHECKS

Before motion is issued, software should decide whether that motion is allowed.

This is one of the most important software responsibilities in motion systems.

Typical questions before motion

Before any commanded move, the system should evaluate things like:

• Is the axis controller connected?
• Is the drive enabled?
• Is the axis homed?
• Is position trust valid?
• Is target position inside soft limits?
• Does the motion cross a forbidden zone?
• Are dependent axes in safe positions?
• Are relevant interlocks satisfied?
• Is the machine in a mode that allows this move?
• Is another subsystem currently owning this axis?
• Is there an active stop, inhibit, or limit condition?

Command validation vs execution

This distinction matters a lot.

Command validation

This happens before the command is sent.

It answers:

• should we allow this move at all?

Execution monitoring

This happens after the move starts.

It answers:

• is the move behaving safely while in progress?

Both are required.

A move can be valid when issued and still become unsafe during execution because:

• a limit triggers
• a door opens
• another axis enters a conflicting state
• following error grows too large
• feedback goes invalid

But none of that removes the need for strong pre-checks.

Motion permission flow diagram

+------------------------+
| Motion Request Arrives |
+-----------+------------+
            |
            v
+------------------------+
| Axis/controller ready? |
+-----+------------------+
      |Yes
      |        No
      |------> Reject
      v
+------------------------+
| Axis homed / trusted?  |
+-----+------------------+
      |Yes
      |        No
      |------> Reject
      v
+------------------------+
| Target within limits?  |
+-----+------------------+
      |Yes
      |        No
      |------> Reject
      v
+------------------------+
| Zone/interlock valid?  |
+-----+------------------+
      |Yes
      |        No
      |------> Reject
      v
+------------------------+
| Mode permits motion?   |
+-----+------------------+
      |Yes
      |        No
      |------> Reject
      v
+------------------------+
| Issue motion command   |
+-----------+------------+
            |
            v
+------------------------+
| Monitor during motion  |
+------------------------+

Important software lesson

Do not scatter these checks across random UI buttons, workflow steps, and helper classes.

That is how unsafe bypasses happen.

The check must be centralized enough that every motion path goes through the same safety gate.

---

PART 6 — STATE MODEL FOR SAFETY

Motion safety is easier to reason about when represented explicitly in state.

A useful simplified state model is:

• Not Homed
• Homing
• Ready
• Limit Hit
• Error

What the states mean

Not Homed

• controller may be alive
• position may exist numerically
• position is not trusted for absolute motion

Allowed actions:

• home
• limited manual recovery, if specifically designed
• not normal absolute production motion

Homing

• axis is actively seeking reference
• normal commands should be blocked
• only homing-specific motion is allowed

Ready

• axis referenced
• no active limit/fault condition
• motion allowed subject to normal checks

Limit Hit

• limit condition detected
• motion must be restricted
• recovery path required
• trust in state may be degraded depending on event

Error

• position trust, controller state, or execution validity is compromised
• software must stop assuming normal behavior
• explicit recovery is required

ASCII state diagram

+-----------+
| Not Homed |
+-----------+
      |
      | Start homing
      v
+--------+
| Homing |
+--------+
      |
      | Success
      v
+-------+
| Ready |
+-------+
  |   |
  |   | Limit event / safety violation
  |   v
  | +-----------+
  | | Limit Hit |
  | +-----------+
  |      |
  |      | Controlled recovery / re-home
  |      v
  | +-----------+
  | | Not Homed |
  | +-----------+
  |
  | Fault / feedback invalid / controller error
  v
+-------+
| Error |
+-------+
   |
   | Reset + re-establish trust
   v
+-----------+
| Not Homed |
+-----------+

Why this matters

Without an explicit safety state model, teams often let motion permission depend on a pile of booleans:

• IsServoOn
• IsInitialized
• NoAlarm
• HomeDone
• HasPosition
• NotBusy
• SafeToMove

That becomes hard to reason about and easy to break.

A clear state model makes recovery and permission logic much safer.

---

PART 7 — REAL-WORLD FAILURE SCENARIOS

These are the cases that actually hurt machines and confuse teams.

1. Incorrect homing

What happens

The axis homes successfully from a software perspective, but the reference is wrong:

• wrong sensor selected
• home offset wrong
• index not found
• mechanical slip occurred
• homing direction configured incorrectly

Real-world consequence

Now every absolute move is systematically wrong.

The machine may appear normal for a while, but:

• pick/place misses target
• vision alignment drifts
• Z clearance is smaller than expected
• stage approaches hard stop during “valid” moves

Why it is dangerous

This is more dangerous than a simple fault because the system looks healthy while being spatially wrong.

That is the worst kind of failure: trusted but wrong.

---

2. False limit trigger

What happens

A hard or software limit is triggered unexpectedly because of:

• noisy input
• bad wiring
• switch bounce
• incorrect polarity mapping
• transient controller status glitch

Real-world consequence

Motion stops abruptly or becomes inhibited. Operators may think hardware is jammed when it is not.

Why it is dangerous

If teams get used to “just reset it,” they may start bypassing genuine protections. False trips erode trust in the safety system.

---

3. Soft limits misconfigured

What happens

Soft limits are too wide, too narrow, swapped, or based on the wrong coordinate frame.

Real-world consequence

• too wide: unsafe motion is allowed
• too narrow: valid production range becomes unreachable
• wrong frame: limits look correct numerically but protect the wrong physical area

Why it is dangerous

Because the software still appears disciplined. It is validating commands, but against the wrong truth.

---

4. Motion allowed before homing

What happens

A code path forgets to require homed state for absolute move commands.

This often happens through:

• manual jog screen
• service command
• recovery utility
• newly added API path
• “temporary bypass” left in production code

Real-world consequence

A move based on untrusted coordinates is issued. The axis may head in a completely unintended direction relative to actual machine geometry.

Why it is dangerous

Because the move may be logically correct in software and physically wrong in reality.

---

5. Stale position after restart

What happens

After controller restart or drive fault, software still displays previous known position and accidentally treats it as valid.

Real-world consequence

The machine resumes operation using stale coordinates.

Why it is dangerous

The UI may show a clean, believable number. But without fresh homing or position validation, that number is just historical data, not current truth.

This is a classic industrial software mistake: confusing displayed state with trusted state.

---

PART 8 — SOFTWARE DESIGN IMPLICATIONS

This topic has strong architectural consequences.

1. Safety must be centralized

Motion permission logic should not be spread across:

• UI button handlers
• workflow steps
• device wrappers
• custom scripts
• helper methods written by different developers

That leads to inconsistent enforcement.

Instead, you want a central motion guard or motion authorization layer.

Example responsibility:

• validate homed state
• validate target against limits
• validate zone constraints
• validate machine mode / interlocks
• issue motion only if permission passes

2. Checks must happen before motion

This sounds obvious, but teams often rely too much on execution-time fault handling.

That is not enough.

Good systems prevent bad motion early. Great systems make it hard to bypass prevention.

3. “Position trust” should be explicit

Do not infer trust from:

• controller connected
• encoder value present
• UI showing coordinates
• previous home flag stored somewhere

Have a clear concept like:

• PositionTrust = Unknown | Referenced | Degraded

That makes safety logic much stronger.

4. Motion APIs should be safe by default

Bad pattern:

MoveAbsolute(axis, target)

with each caller responsible for its own checks.

Better pattern:

RequestMove(axis, target, context)
 -> validated by motion guard
 -> rejected or executed

The point is not the exact method signature.

The point is architectural ownership.

5. Manual and service paths must still go through safety policy

A common failure pattern is:

• production sequence uses safe motion path
• manual/service tools directly call controller APIs
• crash happens during debug or maintenance

Experienced teams know that the dangerous moves often happen outside the normal automatic sequence.

So safety policy must cover:

• automatic commands
• manual jogs
• service tools
• recovery utilities
• scripting hooks

Bad pattern vs good pattern

Bad pattern

• UI calls controller directly
• each screen checks safety differently
• workflow logic duplicates limit checks
• special maintenance path bypasses homing requirement
• soft-limit logic lives in multiple classes

Good pattern

• one motion service owns command entry
• one guard layer evaluates safety conditions
• one state source defines homed / trust / limit status
• controller adapters stay low-level
• higher layers request motion, not raw actuation

Simple architecture sketch

UI / Workflow / Service Tools
           |
           v
+-------------------------+
|   Motion Guard Layer    |
|-------------------------|
| homed check             |
| limit check             |
| zone check              |
| interlock check         |
| mode check              |
+-----------+-------------+
            |
            v
+-------------------------+
|   Motion Service API    |
+-----------+-------------+
            |
            v
+-------------------------+
| Controller / Drive SDK  |
+-------------------------+

That pattern fits your source-of-truth principle that machine systems should be state-driven, not call-driven, and that motion must be validated before execution.

---

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS

Here are good ways to explain this clearly.

1. How to explain motion safety simply

“Motion safety starts with the fact that software is commanding physical movement, so a bad command can damage hardware. The system therefore has to establish a trusted reference by homing, define valid travel boundaries with soft limits, use hard limits as a last line of protection, and validate every move before execution.”

2. Why homing matters

“Homing is how the machine turns unknown physical position into trusted logical position. Without that, absolute coordinates, soft limits, and saved recipe positions are not safe to use.”

3. Hard limits vs soft limits

“Soft limits are the normal software protection that prevents unsafe targets from being commanded. Hard limits are the last physical protection when something still goes wrong. If a machine hits hard limits during normal operation, I treat that as a design or configuration problem.”

4. What safe travel zones mean

“Safety is usually more than min/max travel. Real machines have context-dependent safe zones based on axis combinations, tooling position, interlocks, and mode. So I think in terms of motion constraints, not isolated commands.”

5. Common mistakes

• trusting position after startup without re-establishing reference
• scattering safety checks across UI and workflow code
• letting maintenance paths bypass motion validation
• treating hard limits as normal operating boundaries
• not modeling position trust explicitly
• assuming a displayed coordinate is a trusted coordinate

6. Architect-level takeaway

“The key design principle is to centralize motion permission logic. I do not want raw motion commands being issued from arbitrary code paths. I want all motion requests to pass through a guard layer that evaluates homing state, limits, zones, and interlocks consistently.”

---

Final mental model

Think of motion safety as a layered defense:

1. Reference truth — homing establishes trusted coordinates
2. Normal boundaries — soft limits define allowed operating range
3. Context constraints — safe zones and interlocks constrain motion by situation
4. Last defense — hard limits protect against abnormal overtravel
5. Architectural enforcement — centralized software guard prevents unsafe commands

That is the software architect’s view.

Not “how do I move the axis?”

But:

“Under what conditions is motion trustworthy, permitted, and safe?”

If you want, I can turn this next into the same style of content for 1.6 Multi-Axis Coordination, so the flow continues naturally from safety on a single axis to safety and correctness across multiple axes.