Machine Control and Motion System
1.1
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing motion control systems in real machines
- coordinating software with physical movement
- handling timing, accuracy, and real-world motion constraints
- debugging motion-related issues in production environments
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand motion control from a SOFTWARE PERSPECTIVE in real industrial systems.
=== TOPIC === Motion Control Fundamentals
=== GOAL ===
Help me understand motion control as a software problem.
Focus on:
- how software commands physical movement
- why motion is inherently asynchronous and stateful
- how motion differs fundamentally from typical software operations
- how real-world constraints affect software design
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Motion Control Fundamentals"
- asynchronous behavior
- command → execution → completion model
- difference between software calls and physical actions
Do NOT introduce concepts from other topics unless necessary for context.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- control theory math
- hardware deep dive (covered later)
- generic explanations
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Sequence diagrams → motion command lifecycle
- State diagrams → motion states
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images (not needed for this topic).
=== SCOPE CONTROL ===
Stay strictly within:
- motion as a software interaction problem
- command lifecycle
- asynchronous execution
- statefulness of motion
Do NOT deep dive into:
- servo/encoder details (Topic 1.2)
- coordinate systems (Topic 1.3)
- limits/homing (Topic 1.5)
- workflows or state machines (later topics)
=== STRUCTURE ===
=== PART 1 — WHAT MOTION CONTROL MEANS IN SOFTWARE ===
Explain:
- what motion control means from a software perspective
- difference between:
- calling a method in software
- commanding physical movement
Explain:
- why motion cannot be treated as an instant operation
- why software must think differently when dealing with physical systems
Use real examples:
- moving a wafer stage
- moving a robot arm
=== PART 2 — THE MOTION COMMAND LIFECYCLE ===
Explain the lifecycle:
- command issued
- motion starts
- motion progresses over time
- motion completes (or fails)
Explain:
- why motion is inherently asynchronous
- how software tracks motion progress
- how completion is detected
Include ASCII sequence diagram:
Software → Motion System → Feedback → Completion
=== PART 3 — MOTION AS A STATEFUL PROCESS ===
Explain:
- motion is not stateless
- system must track:
- current status
- target state
- progress
Explain:
- difference between:
- command sent
- motion actually completed
Include ASCII state diagram: Idle → Moving → Completed / Error
=== PART 4 — REAL-WORLD BEHAVIOR VS SOFTWARE EXPECTATION ===
Explain mismatch:
- software expects deterministic behavior
- hardware introduces:
- delay
- jitter
- uncertainty
Explain:
- latency between command and action
- delay in feedback signals
- timing variability
=== PART 5 — FAILURE SCENARIOS ===
Explain real problems:
- motion never completes
- motion completes late
- feedback is incorrect or delayed
- command is accepted but not executed
For each:
- what it looks like in production
- why it happens
- how engineers detect it
=== PART 6 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why motion must be handled asynchronously
- why blocking design is dangerous
- need for:
- timeouts
- completion checks
- explicit state tracking
Explain:
- why "call → done" mindset fails
=== PART 7 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain motion control clearly
- key mental models:
- command vs execution
- async physical process
- stateful operation
Explain:
- common mistakes engineers make when entering this domain
=== OUTPUT ===
- structured explanation
- deep but clear reasoning
- real-world examples
- ASCII UML-style diagrams
1.2
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- working with servo and stepper systems in real machines
- integrating encoders and position feedback mechanisms
- dealing with hardware limitations that directly impact software behavior
- debugging motion issues caused by hardware characteristics
I am a senior .NET engineer transitioning into this domain.
I want to understand motion hardware concepts at a PRACTICAL LEVEL for software engineers.
=== TOPIC === Motion Hardware Basics
=== GOAL ===
Help me understand the key motion hardware concepts that influence software design.
Focus on:
- servo motors vs stepper motors
- encoders and position feedback
- how hardware characteristics affect software behavior
- what software engineers must know (without going deep into electrical/control theory)
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Motion Hardware Basics"
- servo vs stepper motors
- encoders and position feedback
- how hardware capabilities affect software design
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Focus on:
- practical understanding
- software implications
- real-world behavior
Avoid:
- electrical engineering deep dive
- control theory math
- unnecessary physics
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Component diagrams → motion system structure
- Signal/feedback diagrams → command vs feedback loop
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Include images ONLY if they help visualize:
- servo motor
- linear stage with encoder
Keep minimal and explain relevance.
=== SCOPE CONTROL ===
Stay within:
- motors
- encoders
- feedback concepts
- software implications
Do NOT deep dive into:
- trajectory math
- coordinate systems
- workflows
=== STRUCTURE ===
=== PART 1 — BIG PICTURE: WHAT SOFTWARE IS CONTROLLING ===
Explain:
- what a motion system physically consists of:
- motor
- driver/controller
- encoder (feedback)
- mechanical system (stage, robot, gantry)
Explain:
- software does NOT control motion directly
- software sends commands to a motion controller
Include ASCII component diagram
=== PART 2 — SERVO VS STEPPER MOTORS ===
Explain:
Stepper:
- open-loop behavior (usually)
- simpler control
- risk of lost steps
Servo:
- closed-loop with feedback
- higher accuracy and reliability
- more complex
Compare:
- behavior
- reliability
- software implications
=== PART 3 — ENCODERS & POSITION FEEDBACK ===
Explain:
- what an encoder does
- how position is measured
- difference between:
- commanded position
- actual position
Explain:
- why feedback is critical
- how software depends on it
Include ASCII diagram: Command → Motor → Encoder → Feedback → Controller
=== PART 4 — COMMAND VS ACTUAL BEHAVIOR ===
Explain:
- commanded position ≠ actual position
- motion errors can occur:
- lag
- overshoot
- drift
Explain:
- how software must not assume perfect execution
=== PART 5 — REAL-WORLD HARDWARE LIMITATIONS ===
Explain:
- speed limits
- acceleration constraints
- mechanical inertia
- vibration and settling time
Explain:
- why motion is not instant
- why software must wait and validate
=== PART 6 — FAILURE SCENARIOS ===
Explain:
- lost steps (stepper)
- encoder failure
- feedback mismatch
- motor stalls
- overheating / protection shutdown
For each:
- what happens in software
- how it is detected
=== PART 7 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why feedback must be validated
- why software must:
- check completion
- not trust commands blindly
- importance of:
- status monitoring
- fault detection
=== PART 8 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain servo vs stepper clearly
- why feedback matters
- what software engineers must understand
=== OUTPUT ===
- structured explanation
- practical understanding
- real-world insights
- ASCII diagrams
1.3
1.4
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing motion command flows in real machines
- coordinating motion execution with sensors and devices
- handling asynchronous motion completion and feedback
- debugging timing-related motion issues in production
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how motion actually executes over time and how software interacts with it.
=== TOPIC === Motion Execution & Behavior
=== GOAL ===
Help me understand how motion behaves during execution from a software perspective.
Focus on:
- motion command model
- feedback and monitoring
- point-to-point vs continuous motion
- real-world execution characteristics
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Motion Execution & Behavior"
- motion command model
- feedback and monitoring
- point-to-point vs continuous motion
- real-world execution characteristics
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Focus on:
- execution behavior over time
- interaction between command and feedback
- real-world imperfections
Avoid:
- control theory math
- hardware deep dive
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Sequence diagrams → motion lifecycle
- Timeline diagrams → motion progression over time
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images (not needed).
=== SCOPE CONTROL ===
Stay within:
- motion execution lifecycle
- feedback loop
- motion types
Do NOT deep dive into:
- coordinate systems
- homing/limits
- workflow orchestration
=== STRUCTURE ===
=== PART 1 — MOTION COMMAND MODEL ===
Explain:
- how software issues a motion command
- command lifecycle:
- issued → accepted → executing → completed
Explain:
- command acknowledgment vs actual execution
- why command success ≠ motion success
Include ASCII sequence diagram
=== PART 2 — ASYNCHRONOUS EXECUTION ===
Explain:
- motion executes over time
- software must not block blindly
Explain:
- polling vs event-driven completion
- completion signals
=== PART 3 — FEEDBACK & MONITORING ===
Explain:
- position feedback
- motion status (moving, done, error)
Explain:
- why feedback is essential
- how software tracks motion progress
Include ASCII feedback loop diagram
=== PART 4 — POINT-TO-POINT VS CONTINUOUS MOTION ===
Explain:
Point-to-point:
- move → stop → settle
Continuous:
- move while performing action (e.g., scanning)
Explain:
- different software handling
- timing implications
=== PART 5 — TIME-BASED BEHAVIOR ===
Explain:
- motion duration
- settling time
- delays between command and physical movement
Explain:
- why timing matters
- how software must wait correctly
=== PART 6 — REAL-WORLD EXECUTION ISSUES ===
Explain:
- motion slower than expected
- overshoot and settling delay
- feedback delay
- command queueing
For each:
- real-world example
- software impact
=== PART 7 — FAILURE SCENARIOS ===
Explain:
- motion never completes
- completion signal missing
- incorrect status reported
- race conditions between command and feedback
=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- need for:
- async design
- timeouts
- validation after motion
Explain:
- why naive synchronous design fails
=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain motion execution clearly
- differences between motion types
- key mental models
=== OUTPUT ===
- structured explanation
- real-world behavior insights
- ASCII UML-style diagrams
1.5
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing safe motion systems with homing and limit protection
- preventing mechanical crashes and overtravel conditions
- implementing motion permission logic and safety checks
- debugging real-world failures caused by incorrect limits or reference positions
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how machines enforce safe movement and prevent damage.
=== TOPIC === Motion Safety & Limits
=== GOAL ===
Help me understand how industrial machines ensure motion safety.
Focus on:
- homing and reference positions
- hard limits and soft limits
- safe travel zones
- how software prevents unsafe motion
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Motion Safety & Limits"
- homing and reference positions
- hard limits and soft limits
- safe travel zones
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Focus on:
- safety from a software perspective
- real-world consequences
- system-level thinking
Avoid:
- electrical safety certification details
- deep control theory
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- State diagrams → homing and limit states
- Constraint diagrams → motion boundaries
- Flow diagrams → motion permission checks
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Include images ONLY if helpful:
- linear stage with limit switches
- travel range visualization
Keep minimal.
=== SCOPE CONTROL ===
Stay within:
- homing
- limits
- motion safety
Do NOT deep dive into:
- workflows
- UI behavior
- fault handling (covered later)
=== STRUCTURE ===
=== PART 1 — WHY MOTION SAFETY IS CRITICAL ===
Explain:
- machines can damage themselves if movement is wrong
- software must enforce safe behavior before motion occurs
Examples:
- stage hitting mechanical stop
- robot colliding with structure
=== PART 2 — HOMING & REFERENCE POSITION ===
Explain:
- what homing is
- why machine must establish a trusted reference
- difference between:
- powered-on
- homed (referenced)
Explain:
- typical homing sequence
Include ASCII sequence diagram
=== PART 3 — HARD LIMITS VS SOFT LIMITS ===
Explain:
Hard limits:
- physical switches
- last line of protection
Soft limits:
- software-defined boundaries
- prevent reaching hard limits
Explain:
- how they work together
Include ASCII diagram: safe range vs hard stops
=== PART 4 — SAFE TRAVEL ZONES ===
Explain:
- allowed movement region
- restricted zones (keep-out areas)
Explain:
- why different zones exist
- how software enforces them
=== PART 5 — MOTION PERMISSION CHECKS ===
Explain:
Before motion:
- is axis homed?
- is target within limits?
- are interlocks satisfied?
Explain:
- command validation vs execution
Include ASCII flow diagram
=== PART 6 — STATE MODEL FOR SAFETY ===
Explain:
States:
- Not Homed
- Homing
- Ready
- Limit Hit
- Error
Explain:
- allowed transitions
- recovery paths
Include ASCII state diagram
=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- incorrect homing
- false limit trigger
- soft limits misconfigured
- motion allowed before homing
- stale position after restart
For each:
- what happens in real machines
- why it is dangerous
=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why safety must be centralized
- why checks must be enforced before motion
Explain:
- bad patterns:
- direct movement without validation
- good patterns:
- motion guard layer
=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain motion safety clearly
- importance of homing and limits
- common mistakes
=== OUTPUT ===
- structured explanation
- real-world safety insights
- ASCII UML-style diagrams
1.6
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- coordinating multiple axes in precision machines
- synchronizing motion across stages, robots, gantries, and subsystems
- handling timing-sensitive interactions between motion, sensors, and process actions
- debugging multi-axis behavior in production environments
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how multiple axes are coordinated in real industrial systems from a SOFTWARE PERSPECTIVE.
=== TOPIC === Multi-Axis Coordination
=== GOAL ===
Help me understand how industrial machines coordinate movement across multiple axes.
Focus on:
- synchronization across axes
- coordinated motion behavior
- interaction with sensors and timing
- software implications of multi-axis systems
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Multi-Axis Coordination"
- synchronization across axes
- coordinated motion behavior
- interaction with sensors and timing
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- heavy kinematics math
- robotics theory deep dive
- generic motion descriptions without software implications
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Sequence diagrams → coordinated motion flow
- Timeline diagrams → synchronized axis behavior over time
- Component diagrams → controllers, sensors, and coordinated subsystems
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Include images ONLY if helpful:
- XY stage
- gantry system
- robot with coordinated joints
Keep minimal and explain relevance.
=== SCOPE CONTROL ===
Stay within:
- multi-axis coordination
- synchronization
- timing interaction with sensors/process
Do NOT deep dive into:
- low-level servo tuning
- advanced robot kinematics
- full workflow design
=== STRUCTURE ===
=== PART 1 — WHY MULTI-AXIS COORDINATION MATTERS ===
Explain:
- many industrial motions involve more than one axis
- software often must coordinate axes as a single logical action
- single-axis thinking is insufficient for real machines
Use examples:
- XY wafer stage
- XYZ gantry
- robot pick-and-place motion
=== PART 2 — WHAT “COORDINATED MOTION” MEANS ===
Explain:
- multiple axes moving as part of one operation
- difference between:
- independent parallel motion
- coordinated motion toward a shared outcome
Explain:
- why timing relationships matter, not just destination
=== PART 3 — SYNCHRONIZATION BETWEEN AXES ===
Explain:
- synchronized start
- synchronized arrival
- maintaining path relationship during motion
Explain:
- why simply issuing two move commands is often not enough
Include ASCII timeline or sequence diagram
=== PART 4 — INTERACTION WITH SENSORS & PROCESS TIMING ===
Explain:
- motion often must align with:
- sensor triggers
- image capture
- process actions
Examples:
- move stage to position, then trigger camera
- continuous scan while acquiring data
Explain:
- timing windows
- coordination between motion and external events
=== PART 5 — REAL-WORLD COORDINATION BEHAVIOR ===
Explain:
- some axes move together, others wait
- one slow axis can affect the whole operation
- timing drift can break process behavior
Explain:
- why coordinated behavior must be designed, not assumed
=== PART 6 — FAILURE SCENARIOS ===
Explain:
- axes start at different times
- one axis arrives late
- sensor trigger happens before motion settles
- path relationship breaks during scan
- independent completion causes inconsistent behavior
For each:
- what it looks like in production
- why it happens
- software impact
=== PART 7 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why multi-axis actions need explicit coordination logic
- why “fire commands separately and hope” fails
- importance of:
- synchronization model
- timing validation
- coordinated completion checks
Explain good vs bad approaches.
=== PART 8 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain multi-axis coordination clearly
- difference between parallel movement and coordinated movement
- common mistakes engineers make
=== OUTPUT ===
- structured explanation
- real-world coordination insights
- ASCII UML-style diagrams
1.7
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing machine workflows and sequence logic in production systems
- coordinating motion, devices, sensors, and process steps
- handling long-running operations with interruptions and failures
- debugging sequencing issues in real industrial machines
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how industrial machines execute workflows from a SOFTWARE PERSPECTIVE.
=== TOPIC === Machine Workflow & Sequencing
=== GOAL ===
Help me understand how industrial machines execute operations step by step.
Focus on:
- step-by-step sequencing
- synchronization between subsystems
- deterministic workflow execution
- real-world issues that make workflow control difficult
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Machine Workflow & Sequencing"
- step-by-step sequencing
- synchronization between subsystems
- deterministic workflow execution
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- generic workflow engine discussion without machine context
- shallow descriptions
- purely academic treatment
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Sequence diagrams → workflow step execution
- State/flow diagrams → workflow progress and transitions
- Timing diagrams → waiting, synchronization, and completion points
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images unless absolutely necessary.
=== SCOPE CONTROL ===
Stay within:
- sequence logic
- step execution
- synchronization between subsystems
- deterministic machine behavior
Do NOT deep dive into:
- detailed motion hardware theory
- detailed UI design
- full state-machine theory (covered in next topic)
=== STRUCTURE ===
=== PART 1 — WHAT A MACHINE WORKFLOW REALLY IS ===
Explain:
- what a machine workflow means in industrial software
- why machines execute work as controlled sequences of steps
- difference between:
- business workflow
- machine workflow
Use real examples:
- wafer inspection: load → align → scan → inspect → unload
- robotic station: pick → move → place → verify
Explain:
- why order matters
- why many steps depend on physical completion, not just logical completion
=== PART 2 — STEP-BY-STEP SEQUENCING ===
Explain:
- what a “step” is in machine software
- how steps are typically defined
- step transitions based on:
- completion
- conditions
- timing
- failure
Explain:
- why machine sequencing is usually strict and deterministic
- why “continue when method returns” is often wrong
Include ASCII flow or sequence diagram
=== PART 3 — SYNCHRONIZATION BETWEEN SUBSYSTEMS ===
Explain:
- workflow often coordinates:
- motion
- sensors
- camera / device actions
- safety checks
Examples:
- wait for stage to reach position before image capture
- wait for vacuum confirmation before robot move
- wait for door-safe condition before continuing
Explain:
- synchronization points
- waiting for conditions
- dependency between subsystems
=== PART 4 — DETERMINISTIC EXECUTION ===
Explain:
- what deterministic execution means in machine workflows
- why reproducible order and behavior matter
- difference between:
- predictable step logic
- uncontrolled asynchronous behavior
Explain:
- how engineers design workflows to be repeatable
- why hidden side effects break determinism
=== PART 5 — WAITING, TIMEOUTS, AND CONDITIONAL PROGRESS ===
Explain:
- waiting for motion complete
- waiting for device ready
- waiting for sensor input
- waiting with timeout
Explain:
- why waiting is central in machine sequencing
- what happens when timeout logic is missing or weak
Include ASCII timing diagram if useful
=== PART 6 — INTERRUPTION & PARTIAL COMPLETION ===
Explain:
- workflow may be interrupted by:
- stop
- pause
- alarm
- operator action
- hardware fault
Explain:
- why a machine can stop mid-sequence in an unsafe or incomplete state
- why partial completion handling is critical
Examples:
- robot picked part but did not place it
- stage moved but image capture failed
- clamp engaged but process aborted
=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- sequence proceeds before subsystem is truly ready
- missed trigger or missed sensor event
- step stuck forever waiting
- wrong step order due to race condition
- repeated retries create inconsistent machine state
For each:
- what it looks like in production
- why it happens
- how experienced engineers diagnose and handle it
=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why workflow logic must be explicit
- why sequencing should not be scattered across UI handlers or device callbacks
- importance of:
- central orchestration
- clear step ownership
- explicit wait conditions
- timeout handling
- fault-aware transitions
Explain good vs bad approaches:
- bad: ad hoc flags, nested callbacks, hidden sequencing in UI code
- good: explicit sequence model, centralized orchestration, traceable step transitions
Include ASCII component or control-flow diagram if useful
=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain machine workflow sequencing clearly
- why machine workflows are different from business workflows
- common mistakes software engineers make when entering machine software
- what strong engineers understand about deterministic sequencing
=== OUTPUT ===
- structured explanation
- real-world workflow insights
- ASCII UML-style diagrams
- practical language suitable for real work and interviews
1.8
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing machine state models for production systems
- handling complex transitions between idle, running, paused, faulted, and recovery conditions
- coordinating workflow state, device state, and machine-wide state
- debugging real machines where weak state modeling caused unsafe or inconsistent behavior
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how state machines are used in industrial machine software from a SOFTWARE PERSPECTIVE.
=== TOPIC === State Machines for Machine Control
=== GOAL ===
Help me understand how industrial machines use state machines to model and control behavior.
Focus on:
- machine states vs workflow steps
- state transitions
- hierarchical state design
- why explicit state modeling is critical in real machine software
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"State Machines for Machine Control"
- machine states vs workflow steps
- state transitions
- hierarchical state design
Stay aligned with the Domain 1 source of truth. oai_citation:0‡Domain 1 — Machine Control and Motion Systems.md
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- academic automata theory
- generic state-machine examples unrelated to machines
- shallow descriptions
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- State diagrams → machine states and transitions
- Hierarchy diagrams → machine vs module vs device state levels
- Sequence diagrams → events causing state transitions
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images unless absolutely necessary.
=== SCOPE CONTROL ===
Stay within:
- machine states
- workflow step vs state distinction
- state transitions
- hierarchical state design
Do NOT deep dive into:
- detailed UI behavior
- detailed workflow engine implementation
- detailed alarm catalog design
=== STRUCTURE ===
=== PART 1 — WHY MACHINE SOFTWARE NEEDS EXPLICIT STATES ===
Explain:
- why industrial machines must always have a well-defined current state
- why “just using flags and booleans” breaks down quickly
- why machine control is fundamentally stateful
Use real examples:
- Idle → Starting → Running → Paused → Faulted → Recovering
- wafer inspection system waiting for safe conditions before starting scan
Explain:
- why ambiguous state leads to unsafe or inconsistent behavior
=== PART 2 — MACHINE STATE VS WORKFLOW STEP ===
Explain clearly the difference between:
- machine state
- workflow step
Examples:
- machine state = Running
- workflow step = Move stage to scan start position
Explain:
- why teams often confuse these concepts
- why mixing them creates fragile logic
Include ASCII diagram showing:
- machine state layer
- workflow step layer
=== PART 3 — STATE TRANSITIONS ===
Explain:
- what a transition is
- what should trigger transitions:
- commands
- events
- completion conditions
- faults
- operator actions
Explain:
- allowed vs invalid transitions
- why transition rules must be explicit
Include ASCII state diagram for a realistic machine
=== PART 4 — HIERARCHICAL STATE DESIGN ===
Explain:
- machine-level state
- subsystem/module state
- device-level state
Examples:
- machine = Running
- motion subsystem = Busy
- camera subsystem = Waiting
- one device = Faulted
Explain:
- why real machines often need multiple state layers
- how hierarchical state models help manage complexity
Include ASCII hierarchy diagram
=== PART 5 — EVENTS, COMMANDS, AND STATE CHANGES ===
Explain:
- how state changes are caused
- difference between:
- operator command
- hardware event
- internal completion event
- fault event
Explain:
- why state must not change silently
- why event-driven transitions are common in machine software
Include ASCII sequence diagram if useful
=== PART 6 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- UI shows machine as Running but subsystem is actually Faulted
- machine accepts Start while still recovering
- state transition occurs too early before physical completion
- multiple flags imply contradictory states
- subsystem state and machine state drift apart
For each:
- what it looks like in production
- why it happens
- how experienced engineers diagnose and handle it
=== PART 7 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why state ownership must be clear
- why explicit state machines are often better than scattered flags
- importance of:
- centralized transition rules
- observable state changes
- separation between state and action
- recovery-aware state modeling
Explain good vs bad approaches:
- bad: boolean explosion, hidden state changes, UI-driven state logic
- good: explicit state model, controlled transitions, traceable events
Include ASCII component or control-flow diagram if useful
=== PART 8 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain state machines clearly in industrial software interviews
- why machine state is different from workflow step
- common mistakes software engineers make when entering machine software
- what strong engineers understand about hierarchical state design
=== OUTPUT ===
- structured explanation
- real-world state-modeling insights
- ASCII UML-style diagrams
- practical language suitable for real work and interviews
1.9
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing operator control flows for real machines
- implementing start/stop/pause/resume/abort behavior safely
- handling different operating modes (auto, manual, maintenance)
- debugging issues caused by incorrect mode handling or unsafe operator actions
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how machines are controlled by operators and how operating modes affect behavior.
=== TOPIC === Operational Modes & Control
=== GOAL ===
Help me understand how industrial machines expose control to operators and manage different operating modes.
Focus on:
- start / stop / pause / resume / abort semantics
- auto vs manual vs maintenance modes
- how modes affect system behavior and safety
- how software enforces correct control behavior
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Operational Modes & Control"
- start / stop / pause / resume / abort
- auto vs manual vs maintenance modes
Stay aligned with the Domain 1 source of truth. oai_citation:0‡Domain 1 — Machine Control and Motion Systems.md
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
Avoid:
- UI design details
- generic descriptions without machine context
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- State diagrams → control states and transitions
- Sequence diagrams → operator command handling
- Mode diagrams → behavior differences per mode
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images.
=== SCOPE CONTROL ===
Stay within:
- operator commands
- mode behavior
- control semantics
Do NOT deep dive into:
- detailed UI layout
- workflow engine internals
- hardware communication specifics
=== STRUCTURE ===
=== PART 1 — WHAT OPERATOR CONTROL REALLY MEANS ===
Explain:
- industrial machines are controlled by humans through defined commands
- control is NOT arbitrary; it is constrained by state, mode, and safety
Examples:
- pressing Start does not always start
- Stop does not always mean immediate halt
Explain:
- difference between command intent and actual system behavior
=== PART 2 — CORE CONTROL COMMANDS ===
Explain semantics of:
- Start
- Stop (graceful)
- Pause
- Resume
- Abort (immediate / emergency-like behavior)
For each:
- what it means in real machines
- how it affects workflow and motion
- typical implementation behavior
=== PART 3 — CONTROL VS STATE INTERACTION ===
Explain:
- commands depend on current state
- not all commands are valid at all times
Examples:
- cannot Start if already Running
- cannot Resume if not Paused
Explain:
- command validation
- state-dependent behavior
Include ASCII state/command diagram
=== PART 4 — OPERATING MODES ===
Explain:
- Auto mode → full workflow execution
- Manual mode → operator-controlled actions
- Maintenance / service mode → diagnostic and unsafe-capable actions
Explain:
- why modes exist
- how they change allowed behavior
=== PART 5 — MODE-DEPENDENT BEHAVIOR ===
Explain:
- same command behaves differently in different modes
- restrictions applied based on mode
Examples:
- motion allowed in manual mode but restricted in auto
- safety checks stricter in production mode
Include ASCII mode-behavior diagram
=== PART 6 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- operator presses Start but system ignores it (missing condition)
- Stop leaves machine in unsafe intermediate state
- Resume continues from inconsistent state
- manual mode allows unsafe operation
- mode switch mid-operation causes undefined behavior
For each:
- what it looks like in production
- why it happens
- how engineers handle it
=== PART 7 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why control logic must be centralized
- why command handling must validate:
- state
- mode
- safety conditions
Explain good vs bad approaches:
- bad: UI directly calling device actions
- good: command → validation → controlled execution
=== PART 8 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain machine control semantics clearly
- differences between Stop, Pause, Abort
- importance of modes in industrial systems
- common mistakes engineers make
=== OUTPUT ===
- structured explanation
- real-world control insights
- ASCII UML-style diagrams
- practical language for real systems and interviews
1.10
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing interlock systems and fault handling logic for real machines
- preventing unsafe actions through permissives and inhibits
- handling motion-level faults, subsystem faults, and machine-wide alarms
- debugging machines where weak interlock or fault logic caused unsafe or inconsistent behavior
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how industrial machines prevent unsafe actions and handle failures predictably.
=== TOPIC === Interlocks & Fault Handling
=== GOAL ===
Help me understand how industrial machines enforce safe behavior and react to abnormal conditions.
Focus on:
- interlocks and permissives
- motion-level errors
- alarm handling and recovery
- how software blocks unsafe actions and guides recovery
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Interlocks & Fault Handling"
- interlocks and permissives
- motion-level errors
- alarm handling and recovery
Stay aligned with the Domain 1 source of truth. oai_citation:0‡Domain 1 — Machine Control and Motion Systems.md
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- generic exception-handling discussions
- purely UI-focused alarm treatment
- shallow descriptions
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Logic/flow diagrams → interlock checks and permissive logic
- State diagrams → fault / recovery states
- Sequence diagrams → fault detection and response flow
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images unless absolutely necessary.
=== SCOPE CONTROL ===
Stay within:
- interlocks
- permissives
- motion-level faults
- alarm handling and recovery
Do NOT deep dive into:
- formal functional safety standards
- full UI/HMI design
- full workflow engine design
=== STRUCTURE ===
=== PART 1 — WHY INTERLOCKS & FAULT HANDLING ARE CENTRAL ===
Explain:
- machine software must assume unsafe conditions and failures will happen
- safe machine behavior depends on preventing bad actions before they happen
- when prevention fails, the system must detect faults, contain them, and recover safely
Use examples:
- cannot move stage when guard is open
- cannot start scan if stage not homed
- axis following error during motion
- camera not ready when process expects capture
=== PART 2 — WHAT INTERLOCKS & PERMISSIVES MEAN ===
Explain clearly:
- interlock
- permissive
- inhibit
- motion-level fault
- machine-level alarm
Explain:
- how these concepts differ
- how they work together in real machines
- why teams often confuse them
Examples:
- permissive: vacuum present before lift
- interlock: door open blocks motion
- inhibit: maintenance mode disables auto-start
=== PART 3 — HOW SOFTWARE EVALUATES INTERLOCKS ===
Explain:
- checks before accepting a command
- checks during operation
- dependencies between state, mode, hardware conditions, and safety signals
Explain:
- why interlock logic should be explicit and centralized
- why scattered checks create unsafe gaps
Include ASCII logic flow diagram: command → validate permissives/interlocks → allow / reject / alarm
=== PART 4 — MOTION-LEVEL ERRORS ===
Explain practical motion-related faults such as:
- motion timeout
- following / position error
- unexpected stop
- homing failure
- limit hit
- feedback mismatch
For each:
- what it means physically
- what it looks like in software
- what machine behavior should follow
Explain:
- why motion faults are special because physical movement may already be in progress
=== PART 5 — ALARM HANDLING & OPERATOR FEEDBACK ===
Explain:
- what an alarm should communicate
- difference between:
- warning
- recoverable alarm
- blocking fault
Explain:
- why alarm handling is more than showing a message
- operator guidance vs engineering diagnostics
- need for:
- fault code
- context
- timestamp
- subsystem ownership
=== PART 6 — RECOVERY & RESET ===
Explain:
- what recovery means in machine software
- when reset is allowed
- why some faults can auto-recover and others require operator/service action
- why resetting a fault does NOT always mean machine is safe to continue
Examples:
- re-home after reference loss
- retry after transient device timeout
- operator intervention after physical obstruction
Include ASCII state diagram: Ready → Running → Faulted → Safe/Reset → Ready
=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- interlock logic missing in one code path
- same action checked in UI but not in service layer
- alarm cleared but subsystem still unhealthy
- operator retries without real recovery
- repeated transient faults hide deeper root cause
- race condition allows move before inhibit becomes active
For each:
- what it looks like in production
- why it happens
- how experienced engineers diagnose and handle it
=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why interlocks and faults need explicit architecture
- importance of:
- centralized validation
- explicit fault model
- consistent command gating
- traceable recovery rules
Explain good vs bad approaches:
- bad: ad hoc boolean checks, exceptions scattered everywhere, vague alarm text
- good: centralized motion guard/interlock layer, structured fault manager, clear reset semantics
Include ASCII component diagram if useful: UI / workflow → command validator → interlock/fault manager → subsystem controllers
=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain interlocks and fault handling clearly
- why interlocks are different from alarms
- common mistakes software engineers make when entering machine software
- what strong engineers understand about safe command gating and recovery
=== OUTPUT ===
- structured explanation
- real-world safety and fault-handling insights
- ASCII UML-style diagrams
- practical language suitable for real work and interviews
1.11
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing recipe and parameter systems for production machines
- handling machine configuration across products, processes, and environments
- debugging production issues caused by incorrect settings or recipe drift
- building safe validation, activation, and audit mechanisms for machine parameters
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how industrial machines use recipes and configuration to control behavior safely and predictably.
=== TOPIC === Recipes & Configuration
=== GOAL ===
Help me understand how industrial machines use recipes and configuration to adapt behavior.
Focus on:
- recipe-driven operation
- parameter management
- configuration safety and validation
- how poor recipe/config design causes real production problems
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Recipes & Configuration"
- recipe-driven operation
- parameter management
- configuration safety and validation
Stay aligned with the Domain 1 source of truth. oai_citation:0‡Domain 1 — Machine Control and Motion Systems.md
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- generic “app settings” explanations
- shallow descriptions
- purely UI-focused discussion
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Component diagrams → recipe/config ownership and flow
- State diagrams → recipe lifecycle (draft, validated, active, invalid)
- Sequence diagrams → load, validate, activate, and apply flow
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Do NOT include images unless absolutely necessary.
=== SCOPE CONTROL ===
Stay within:
- recipe-driven behavior
- machine parameters
- configuration validation
- activation and usage of settings
Do NOT deep dive into:
- MES integration
- database schema design
- calibration math (covered later)
=== STRUCTURE ===
=== PART 1 — WHAT RECIPES & CONFIGURATION MEAN IN MACHINE SOFTWARE ===
Explain:
- what a recipe is in industrial machine software
- how recipe differs from machine configuration
- why industrial machines need controlled parameterization
Explain clearly the difference between:
- recipe data
- machine configuration
- runtime state
- operator preference/UI settings
Use real examples:
- wafer inspection mode with specific scan and imaging parameters
- pick-and-place product setup with positions, timings, and thresholds
=== PART 2 — RECIPE-DRIVEN OPERATION ===
Explain:
- machine behavior changes based on selected recipe
- the same machine can run different products/processes using different settings
- workflows, motion, thresholds, and device behavior may all depend on recipe values
Explain:
- why recipe is part of machine logic, not just stored data
- why “wrong recipe” can create quality problems or hardware risk
=== PART 3 — PARAMETER CATEGORIES ===
Explain practical categories such as:
- motion positions and speeds
- timing and delay values
- vision/camera settings
- thresholds and tolerances
- product-specific rules
- subsystem enable/disable settings
- safety-sensitive operating limits
For each:
- what it controls
- how it affects machine behavior
- typical risks if wrong
=== PART 4 — CONFIGURATION SAFETY & VALIDATION ===
Explain:
- range validation
- dependency validation
- unit consistency
- hardware capability checks
- compatibility checks between recipe and machine state
Explain:
- why “value is in range” is not enough
- why validation should happen before activation, not only at edit time
Use examples:
- motion target outside safe travel range
- camera exposure incompatible with scan speed
- recipe created for older hardware revision
Include ASCII validation flow diagram if useful
=== PART 5 — RECIPE LIFECYCLE ===
Explain a realistic lifecycle:
- create
- edit
- validate
- approve
- activate
- run
- revise
- archive
Explain:
- draft vs active recipe
- offline editing vs online activation
- why activation needs control and traceability
Include ASCII state diagram
=== PART 6 — APPLYING RECIPES TO THE MACHINE ===
Explain:
- load vs validate vs apply vs activate
- how different subsystems consume parameters
- why partial application is dangerous
- why “UI shows new value” does not always mean machine is truly running with it
Explain:
- stale cached values
- inconsistent subsystem state
- need for acknowledgment and readiness checks
Include ASCII sequence diagram: operator selects recipe → validation → subsystem apply → machine ready
=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- wrong recipe selected for the product
- hidden dependency between parameters
- operator changes parameter that should be locked
- outdated recipe after hardware change
- recipe says one thing, machine still uses old cached values
- gradual recipe drift causes unstable production behavior
For each:
- what it looks like in production
- why it is difficult
- how experienced engineers prevent or investigate it
=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why recipe/configuration needs explicit architecture
- importance of:
- typed models
- clear ownership
- validation rules
- versioning
- audit trail
- change control
- permissions
Explain good vs bad approaches:
- bad: loose dictionaries, magic strings, hidden defaults, silent fallback behavior
- good: explicit schema, validated activation flow, traceable changes, subsystem-level acknowledgment
Include ASCII component diagram if useful: UI/editor → validator → recipe manager → subsystem adapters → active machine state
=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain recipe-driven operation clearly
- why recipes are central to industrial machines
- common mistakes software engineers make when entering machine software
- what strong engineers understand about safe parameter management
=== OUTPUT ===
- structured explanation
- real-world recipe/configuration insights
- ASCII UML-style diagrams
- practical language suitable for real work and interviews
1.12
You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).
You have real production experience, including:
- designing calibration and alignment flows for real machines
- dealing with offsets, drift, coordinate mismatches, and mechanical tolerances
- integrating motion, sensors, cameras, and reference measurements
- debugging production issues caused by incorrect calibration or alignment assumptions
I am a senior .NET engineer transitioning into this domain.
I want to deeply understand how industrial machines establish and maintain accuracy from a SOFTWARE PERSPECTIVE.
=== TOPIC === Calibration & Alignment
=== GOAL ===
Help me understand how industrial machines establish and maintain accurate spatial relationships.
Focus on:
- coordinate correction
- offsets and transforms
- alignment flows
- drift and re-calibration
=== ALIGNMENT WITH SOURCE OF TRUTH ===
This topic corresponds to:
"Calibration & Alignment"
- coordinate correction
- offsets and transforms
- alignment flows
- drift and re-calibration
Stay aligned with the Domain 1 source of truth. oai_citation:0‡Domain 1 — Machine Control and Motion Systems.md
Do NOT introduce unrelated topics.
=== STYLE & DEPTH ===
Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.
Combine:
- clear explanation
- deep technical reasoning
- system-level thinking
- real-world production insight
For important concepts:
- explain the idea
- explain how it behaves in real systems
- explain what can go wrong
- explain how experienced engineers handle it
Avoid:
- heavy math derivations
- abstract metrology discussion without machine context
- shallow descriptions
=== DIAGRAM STYLE ===
Use UML-style ASCII diagrams:
- Coordinate/transform diagrams → machine, tool, camera, and work coordinates
- Sequence diagrams → calibration/alignment flow
- Component diagrams → calibration data flow and ownership
Rules:
- ASCII only
- simple and readable
- clearly explain each diagram
=== REAL-WORLD IMAGES ===
Include images ONLY if they truly help explain:
- wafer alignment marks
- stage and camera relationship
- calibration target / fiducial usage
Keep usage minimal and explain why the image matters.
=== SCOPE CONTROL ===
Stay within:
- coordinate correction
- offsets and transforms
- alignment flows
- drift and re-calibration
Do NOT deep dive into:
- advanced computer vision algorithms
- low-level servo tuning
- full recipe/configuration architecture except where needed for context
=== STRUCTURE ===
=== PART 1 — WHY CALIBRATION & ALIGNMENT EXIST ===
Explain:
- why machines cannot rely only on nominal mechanical positions
- why software needs trusted relationships between:
- axes
- camera / sensor
- tooling / end effector
- workpiece / wafer / product
Use real examples:
- wafer stage under inspection optics
- camera-guided pick-and-place
- robot tool center point setup
Explain:
- why even mechanically precise machines still need calibration and alignment
=== PART 2 — CALIBRATION VS ALIGNMENT VS HOMING ===
Explain clearly the difference between:
- calibration
- alignment
- homing / referencing
- recipe positions
- runtime correction / compensation
For each:
- what it means in real systems
- what problem it solves
- how teams often confuse them
Explain:
- why mixing these concepts creates fragile software and wrong operator expectations
=== PART 3 — COORDINATE CORRECTION, OFFSETS & TRANSFORMS ===
Explain:
- machine coordinates
- work coordinates
- camera/image coordinates
- tool coordinates
- offsets
- transforms between coordinate systems
Explain:
- how software maps physical reality into usable coordinates
- why corrected position is not always the same as nominal position
Keep it practical:
- no matrix derivation
- focus on intuition and software meaning
Include ASCII transform/coordinate diagram
=== PART 4 — CALIBRATION FLOWS ===
Explain realistic calibration flows such as:
- axis-to-camera calibration
- pixel-to-world calibration
- tool offset calibration
- focus/reference calibration
- sensor threshold/reference calibration
For each:
- what is being calibrated
- how the machine performs the process
- what data is produced
- how software stores and applies the result
Include ASCII sequence diagram for a calibration flow
=== PART 5 — ALIGNMENT FLOWS ===
Explain realistic alignment flows such as:
- fiducial-based alignment
- wafer alignment
- part origin finding
- rotational correction
- runtime re-alignment before process execution
Explain:
- how measurement is taken
- how offsets are computed conceptually
- how motion or process coordinates are corrected
=== PART 6 — DRIFT & RE-CALIBRATION ===
Explain why calibration is not “done once forever.”
Cover issues such as:
- thermal drift
- mechanical wear
- camera mounting shift
- tooling replacement
- maintenance changes
- sensor aging
For each:
- what it looks like in production
- how it affects quality or positioning
- how engineers monitor or re-validate it
=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===
Explain:
- wrong calibration data loaded
- coordinate frame mismatch
- stale offsets after maintenance
- alignment succeeds but target is still missed
- operator skips required re-calibration
- software silently mixes nominal and corrected positions
For each:
- what it looks like in production
- why it is difficult
- how experienced engineers diagnose and handle it
=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===
Explain:
- why calibration/alignment must be first-class concepts in architecture
- why offsets and transforms should not be hidden in random code
- importance of:
- explicit coordinate models
- calibration data ownership
- versioning and traceability
- validation before activation
- clear distinction between nominal value and corrected value
Explain good vs bad approaches:
- bad: magic offsets in code, hidden manual corrections, unclear coordinate ownership
- good: explicit models, controlled activation, visible correction pipeline, traceable records
Include ASCII component diagram if useful: service tool / UI → calibration manager → transform model → motion / vision subsystems
=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===
Give:
- how to explain calibration and alignment clearly
- why offsets and transforms matter in machine software
- common mistakes software engineers make when entering machine software
- what strong engineers understand about coordinate integrity and drift
=== OUTPUT ===
- structured explanation
- real-world calibration/alignment insights
- ASCII UML-style diagrams
- practical language suitable for real work and interviews