ABB robot programming basics in RAPID

ABB robots are programmed in RAPID, and almost every beginner mistake comes from one of three places: the wrong coordinate system, the wrong motion type, or a missing wait.

This guide explains the structure of a RAPID program, what the main motion instructions actually do, how tool and work object frames change the numbers you see, and how to write a pick-and-place routine that a technician can read six months later. It is written for someone who has a teach pendant in hand or RobotStudio open on a laptop, not for someone choosing a brand.

The mental model: six numbers and three frames

Every robot position is stored as a robtarget, which contains four groups of data: the position in x, y, z in millimetres; the orientation as a quaternion; the configuration of the arm (which of the eight solutions the controller should use); and the external axes. Beginners copy targets from the pendant and never look inside, which is fine until a target fails to reach.

Three frames decide what those numbers mean:

• Base frame — the robot’s own origin, fixed to its mounting plate.
• Tool frame — where the tool centre point sits relative to the wrist flange. This is the frame the robot actually moves.
• Work object frame — the part or fixture you are working on. Define it once and every program position becomes relative to the part, not the robot.

Define the tool and the work object before writing a single motion. If the tool centre point is wrong, every programmed point is wrong by the same offset, and the robot will look like it is missing a calibration that does not exist. The TCP calibration guide covers the four-point method in detail.

Program structure

A RAPID program is a module containing routines. One routine is main, which the controller calls. Everything else is a routine you call from it. That is the whole structure, and keeping it small is the difference between a maintainable cell and a file nobody dares edit.

MODULE PickPlace
  ! tool and work object declared once
  PERS tooldata tGrip := [TRUE, [[0,0,120],[1,0,0,0]], [1,[0,0,60],[1,0,0,0],0,0,0]];
  PERS wobjdata wFixture := [FALSE, TRUE, "", [[0,0,0],[1,0,0,0]],
                             [[300,0,150],[1,0,0,0]]];

  CONST speeddata vFast := v500;
  CONST speeddata vSlow := v100;
  CONST zonedata zFine := fine;

  PROC main()
    WaitDI diCellReady, 1;          ! never start into an unsafe cell

    MoveJ pHome, vFast, zFine, tGrip;
    MoveJ pAbovePick, vFast, zFine, tGrip \WObj:=wFixture;
    MoveL pPick, vSlow, zFine, tGrip \WObj:=wFixture;

    SetDO doGrip, 1;                ! close gripper
    WaitDI diPartClamped, 1;        ! confirm before moving

    MoveL pAbovePick, vSlow, zFine, tGrip \WObj:=wFixture;
    MoveJ pAbovePlace, vFast, zFine, tGrip \WObj:=wFixture;
    MoveL pPlace, vSlow, zFine, tGrip \WObj:=wFixture;

    SetDO doGrip, 0;
    WaitTime 0.3;

    MoveL pAbovePlace, vSlow, zFine, tGrip \WObj:=wFixture;
    MoveJ pHome, vFast, zFine, tGrip;
  ENDPROC
ENDMODULE

Two habits in that example are worth copying. Every move above a fixture is a straight line approach, so the robot never swings through the fixture. And every gripper action is followed by a confirmation, either a digital input or a deliberate wait. A program that assumes the gripper closed is a program that will eventually drop a part on the floor.

MoveJ, MoveL and MoveC

Choosing the motion type is the decision that most affects cycle time and collision risk.

Use MoveJ for travel and MoveL for anything close to a part. A joint move that looks fine in simulation can sweep the tool through a fixture because the TCP takes the shortest joint path, not the shortest spatial path. This single rule prevents most first-week crashes.

Speed, zone and the fine point

Each motion instruction takes a speed and a zone. The zone decides whether the robot stops exactly at the point (fine) or rounds through it at a given radius (z10, z50). Rounding is faster and smoother, but it means the robot does not actually reach the programmed point.

• Use fine where precision matters: picking a part, inserting, any point where the tool must be exactly there.
• Use a zone for intermediate travel points. A 50 mm zone through an approach point can cut a second off a short cycle.
• Do not zone the last point before a grip. The robot will start blending into the next move while the gripper is still closing.
• Speed is in mm/s for linear moves and as a percentage of maximum for joint moves. They are not interchangeable.

Digital signals and the handshake

A robot cell is a conversation between the controller and the machines around it. In RAPID the verbs are SetDO, ResetDO, WaitDI, WaitDO and WaitTime. The discipline is to make every wait have a timeout, otherwise a missing signal stops the cell indefinitely with no clue why.

SetDO doRequestPart, 1;
WaitDI diPartPresent, 1 \MaxTime:=5 \TimeFlag:=bTimeout;
IF bTimeout THEN
  SetDO doRequestPart, 0;
  TPWrite "Part did not arrive within 5 s";
  EXIT;                       ! leave the routine instead of hanging
ENDIF
SetDO doRequestPart, 0;

This pattern, wait with a time flag and handle the failure, is what separates a demo program from something a production line can run. The cell handshake in a real installation is usually more elaborate, and the robot integration checklist lists the signals worth defining before commissioning.

Practising without a robot

RobotStudio lets you build a station, import a robot, write RAPID and run it in simulation with collision detection. For a student or a technician between jobs, this is the cheapest way to build real fluency. Program the same pick-and-place three ways, then measure the simulated cycle time and explain the difference.

If you are comparing simulation tools generally, the industrial robot simulation software guide covers the options available in India, and the industrial robot programming guide puts RAPID in context with other controllers.

Mistakes that cost the most time

Reading someone else’s program

When you inherit a cell, read it in this order: the module header for tool and work object declarations, then main for the sequence, then each routine for waits and branches. Ignore the motion lines on the first pass. The logic lives in the waits and the branches; the moves are just geometry.

Add comments in the same style as the original author, and put the reason for a wait next to the wait. “Wait for clamp” is useful. “Wait 0.5 s” with no explanation is a mystery that will survive three maintenance engineers.

Where to go next

Once the basics are comfortable, the teach pendant workflow becomes the bottleneck and the teach pendant programming guide covers the habits that make manual teaching faster and safer. Cycle time is the next thing a supervisor will ask about, and industrial robot cycle time calculation shows how to measure and improve it with arithmetic rather than guesswork.

If you are still comparing brands, the FANUC, KUKA, ABB and Yaskawa comparison covers programming environments and ecosystem differences. Programming skill transfers, but the pendant, the syntax and the simulation tool do not.

Sources and further reading

• ABB technical documentation library — RAPID manuals, controller manuals and data sheets.
• ABB RobotStudio — offline programming and simulation environment.
• ABB Robotics — controller and robot documentation.
• Robotics Stack Exchange — practical programming questions.