An industrial robot arm without a program is an expensive, inert piece of hardware. Everything that makes it useful — the sequence of pick points, the weld path, the exact moment a gripper closes — comes from the program loaded into its controller, and that program is almost always built using the same core set of concepts regardless of which manufacturer built the robot. FANUC, ABB, KUKA, and Yaskawa each ship a different programming language with its own syntax and menu structure — TP, RAPID, KRL, and INFORM respectively — which can make robot programming look like it needs to be relearned from scratch for every vendor. It doesn't. Underneath the differing keywords, every industrial robot programming environment expresses the same handful of ideas: teaching physical points, choosing how the robot moves between them, reading and reacting to inputs and outputs, organizing logic into reusable subroutines, and controlling speed and acceleration. Learn those concepts once, generically, and picking up any specific vendor's syntax becomes a matter of days, not a fresh start.
The Teach Pendant: How Robots Are Actually Taught
The teach pendant is the handheld controller — a screen, a set of jog buttons or a joystick, and physical hardware safety controls including an emergency stop and a deadman's switch — that an operator or programmer uses to directly control and program the robot up close. Before a robot can execute any automated program, most of its motion points originate from an operator physically jogging the arm, axis by axis or in a chosen coordinate frame, to the exact physical position needed and recording that position into the program. This process, called teaching, is why teach-pendant programming is sometimes described as programming by demonstration: rather than typing exact X-Y-Z-orientation coordinates from a drawing, the programmer moves the real (or simulated) robot to the real location and tells the controller "remember this point."
A teach pendant's jog controls typically offer more than one coordinate frame to move in. Joint jogging moves one axis at a time, which is the most direct way to understand and troubleshoot how each joint is positioned, but it's a clumsy way to get the tool to a specific physical location. World or Cartesian jogging instead moves the tool in a straight line along the cell's fixed X, Y, or Z axes regardless of how many joints have to cooperate to make that happen, which is far more intuitive for positioning the tool relative to a part or fixture. Tool jogging moves relative to the end effector's own orientation — useful for backing the tool straight off a part it just approached. Every major vendor's pendant offers some version of all three, because each suits a different moment in the teaching process.
Because the teach pendant puts an operator in close physical proximity to a powered robot, it carries hardware safety features that are not optional extras: the emergency stop cuts power to the drives immediately, and the deadman's switch (also called an enabling device) is a three-position grip switch that must be held in its middle position for the robot to move at all under pendant control — release it, or squeeze it too hard into the third position, and motion stops. These are the physical safety mechanisms behind the "hand-guiding" and manual teaching modes referenced in ISO/TS 15066 collaborative robot safety standards.
Waypoints and Motion Types
A robot program, stripped to its essentials, is a sequence of waypoints — taught or calculated positions — plus an instruction for how to move between each pair of them. That "how" is the motion type, and the choice of motion type has real consequences for path shape, speed, and predictability.
Joint Move (Point-to-Point)
A joint move, often labeled PTP (point-to-point), commands every axis to reach the target angle at the same moment, with each joint free to move at whatever speed profile gets it there simultaneously with the others. Because the joints aren't coordinated to produce any particular shape of end-effector path, the tool's actual trajectory between the start and end pose is a curve that isn't precisely predictable without running the calculation — it is whatever shape results from all axes arriving together. What a joint move reliably delivers is speed: since no axis is artificially held back to keep the tool on a straight line, joint moves are typically the fastest way to relocate the arm from one pose to another, and they're the default choice whenever the path in between doesn't matter — moving from a home position to an approach point above a part, for instance.
Linear Move
A linear move (often labeled LIN) instead commands the tool center point to travel in a straight line through 3D space from the start point to the end point, which means the controller is continuously solving inverse kinematics at each instant along that line to figure out what every joint angle must be to keep the tool on the straight path. This is essential whenever the path itself is part of the job requirement — following a weld seam, moving a dispensing nozzle along a bead of adhesive, or lowering a part straight down into a fixture without swinging sideways into a neighboring part. The tradeoff is that linear moves are generally slower than joint moves over the same start and end points, and because the controller is constrained to a specific path rather than free to choose the fastest joint trajectory, a linear move is more likely to run the arm through a singularity (a configuration where the inverse kinematics solution becomes unstable, covered in depth in our kinematics guide) if the straight-line path happens to pass near one.
Circular Move
Most industrial languages also support a circular move (CIRC), which defines an arc by three points — start, an intermediate point on the arc, and the end point — and moves the tool along that curved path. This shows up most often in arc welding and dispensing applications where the actual seam or bead being followed is curved rather than straight.
| Motion Type | Tool Path Shape | Relative Speed | Use When |
|---|---|---|---|
| Joint move (PTP) | Curved, not precisely predictable | Fastest | The path in between doesn't matter — repositioning, approach moves |
| Linear move (LIN) | Straight line | Slower | The path itself matters — welding, dispensing, controlled insertion |
| Circular move (CIRC) | Arc through 3 defined points | Moderate | Following a curved seam or bead |
Concepts Shared Across Vendor Languages
Whether the program is written in RAPID, KRL, TP, or another vendor's language, it is built from the same conceptual building blocks.
I/O Handling
Robots interact with the rest of the work cell through digital and analog inputs and outputs: a digital output closes a gripper or fires a paint gun; a digital input reads a part-present sensor, a safety gate switch, or a "ready" signal from a neighboring machine. Programs routinely wait on an input before proceeding ("wait until part-present sensor is true before moving in to pick") and set outputs as part of a motion sequence ("close gripper, wait 200 milliseconds for it to seat, then retract"). This I/O layer is what actually ties the robot's motion program into the rest of the automated cell — the conveyor, the PLC-controlled fixtures, the safety system — and it's conceptually the same mechanism described from the PLC side in our ladder logic guide.
Subroutines and Structured Programs
Just as in general-purpose programming, industrial robot languages support breaking a large program into named, reusable subroutines (sometimes called procedures or user routines): a "PickPart" routine, a "PlaceOnConveyor" routine, a "HomePosition" routine, each called from a higher-level main program that sequences them. This isn't a stylistic nicety — a monolithic, unstructured program of hundreds of taught points and moves becomes extremely difficult to modify or debug, while a program built from small, well-named subroutines lets a technician isolate and fix one step (say, a gripper timing issue in "PickPart") without touching the rest of the sequence.
Speed and Acceleration Overrides
Every programmed move carries a target speed and, often, acceleration and blending parameters, but the pendant also exposes a global speed override — a percentage scaling factor applied on top of whatever the program specifies. This override is central to safe commissioning: a newly written or edited program is nearly always first run at a low override, commonly 10-25%, so an operator standing at the pendant can watch the robot's actual motion closely and hit the emergency stop the instant something looks wrong, well before a mistake at full speed could damage the part, the tooling, or the robot itself. Only after a program has been verified safe and correct at reduced speed is the override progressively raised toward 100% for production. Acceleration and deceleration parameters, and path "blending" or "zone" settings that round off the transition between consecutive moves rather than coming to a full stop at each waypoint, further shape how smoothly and quickly the arm actually executes the taught sequence.
Offline Programming and Simulation
Teaching every point directly on the physical robot has an obvious cost: the robot has to sit idle, out of production, for however long the teaching and testing takes, which on an active line can be extremely expensive downtime. Offline programming (OLP) addresses this by letting an engineer build and largely validate a robot program in simulation software, using a 3D virtual model of the robot, its end effector, and the surrounding work cell, without touching the physical hardware at all. The engineer can place virtual waypoints, sequence motion and I/O logic, and — critically — run automated collision checks between the simulated robot and the cell's fixtures, safety fencing, and other equipment, catching many programming errors before the robot is ever brought online. Reach and cycle-time studies can also be run virtually, letting an engineer confirm a proposed cell layout can actually achieve its target cycle time before it's built.
Offline programming rarely eliminates the need to touch the real robot entirely — actual sensor tolerances, fixture positioning, and part variation almost always require some on-robot fine-tuning of the taught points before a program is production-ready — but it dramatically shrinks how much of that expensive downtime is needed, by resolving the bulk of the sequencing, logic, and gross collision-avoidance work in simulation first. This same simulation and virtual-model foundation is also the starting point for digital twins, which extend the concept further by keeping the virtual model continuously synchronized with the running physical robot rather than using it only as an offline planning tool.
Putting It Together
A working industrial robot program, in any vendor's language, is fundamentally the same story: a set of taught or calculated waypoints, a chosen motion type between each pair of them, I/O calls that synchronize the robot with the rest of the cell, structured into subroutines for maintainability, and run at a speed override that starts low and rises only once the program has been proven safe. An engineer who understands that structure conceptually — independent of whether the specific keyword is MoveL, LIN, or a TP linear-motion instruction — already understands the program; only the exact syntax remains to be looked up in the vendor's manual.