Robot Programming

Write the program in English first

The single best habit in robot programming has nothing to do with KRL or RAPID: write the sequence in numbered plain English before you open the pendant or an editor. Here is a genuine program specification from one of our cells — an unload robot picking product from a belt and stacking it, written before any code existed:

Notice what that document does. Every "wait for" is a PLC handshake from Part 5. Every position gets a letter before it has coordinates. The 50 mm clearance rule is written down before anyone teaches a point. Subroutines — place a separator sheet when told to, place an empty pallet when the stack is complete — get the same treatment. When the spec is finished, the programming is mostly translation, and anyone in the building can review the logic without reading a line of code. That review, before code exists, is where sequence mistakes are cheap.

Structure: main loop plus subroutines

Production robot programs share a shape regardless of brand. An initialisation section — check inputs are sane, confirm the gripper state, move to home from wherever the robot woke up. A main loop that runs the core cycle. Subroutines for the exceptions: separator sheets, pallet change, purge, go-home-on-demand. The PLC selects between them with the program number interface you configured in Part 6.

Keep the decision-making in the PLC and the motion in the robot. The robot should be told "place a separator sheet now" — it should not be counting layers and deciding for itself while the PLC also counts layers and disagrees. One brain per decision. When both controllers track the same state, they will eventually diverge, and that fault will appear once a week and never while you are watching.

Positions: teach few, calculate many

The defining difference between an amateur program and a maintainable one is how positions are handled. Teaching every position individually means a palletising program with 40 boxes per pallet needs hundreds of taught points — and re-teaching every one of them whenever the pallet position moves or a product changes.

The professional pattern is base-frame-relative offsets: define a base frame at a single reference point — the pallet corner — and calculate every place position as an offset within that frame from the row, column and layer geometry. Move the pallet station? Re-teach one point. New box size? Change three numbers. This is exactly how our palletising program generator structures its output, because it is the pattern that survives contact with production.

• Teach: home, pick position, the base frame reference, and any fixed stations (sheet magazine, empty pallet stack)
• Calculate: every place position, every approach and retract point above it
• Always approach and retract vertically above the place position with a defined clearance — never move horizontally at product height through a part-built stack

Searches: when the world isn't where you left it

Real products vary. Stack heights drift, pallet boards bow, incoming layers are not always exactly where the drawing says. The robust answer is a search routine: move toward the expected position at reduced speed and let a sensor input interrupt the motion when contact or detection occurs, then take the actual position as the reference. In the program spec above, "search down for top of stack" is doing exactly this — the robot finds the true stack height on every cycle rather than trusting a counter.

On a KUKA this is an interrupt declaration watching the sensor input, with the actual position captured when it fires; on ABB the equivalent is a search-style move terminated by the signal. Either way the rule is the same: search moves are slow, distances are bounded, and a failed search (no detection within the window) is a fault the PLC gets told about — not a reason to keep driving.

Speeds, modes and the path to full speed

Develop and touch up in T1 — reduced speed, hold-to-run, you in control. Prove the full cycle at low override before you ever run it fast. Then increase speed in stages while watching the whole cycle, not just the motion: vacuum grip at speed behaves differently to vacuum grip at 10%, and a program that places perfectly at 30% override can drop product at 100%. Program speeds belong on named variables or clearly grouped values, not scattered magic numbers — commissioning in Part 9 will tune them, and hunting for hard-coded velocities across a program at 2am is misery you can design out now.

KUKA and ABB: same ideas, different words

Everything above applies to both. KRL gives you SRC/DAT files, base frames, interrupts and $IN/$OUT; RAPID gives you modules and procedures, work objects, and its own signal instructions. If you learned the sequence-first, offset-based, search-hardened approach on one, you can read the other within a day. The expensive skill is the approach, not the syntax.

Or skip the blank editor entirely

If your cell is a palletising or depalletising application, be aware that this exact program — base-frame offsets from one taught reference, layer patterns, approach and retract clearances, search routine for variable stack height, separator sheet handling, PLC handshakes — is what the Path2 generator produces from a pallet configuration you type in. It is the same structure described on this page, generated in minutes, as KUKA .SRC/.DAT or ABB .MOD files, tested on a real KRC4. There is a free sample to run on your own controller before spending anything. Writing it yourself following this guide is a genuinely good way to learn; generating it is a genuinely fast way to be in production.

Common mistakes

• Coding before the sequence is written down. Logic errors found in a spec cost minutes; found on the robot they cost days
• Teaching every position individually instead of calculating from a base frame — hundreds of points, all wrong the day the pallet moves
• Horizontal moves at product height across the cell instead of up-over-down with clearances
• Two counters for the same thing — layer counting in both PLC and robot, guaranteed to diverge
• No fault path for a failed search or a missing vacuum confirmation — the program just waits forever and nobody knows why the cell has stopped
• Magic-number speeds sprinkled through the program instead of variables you can tune in one place

Next in the series

Testing & FAT — coming soon

→