Cobot Programming: Methods, Languages, and PLC Cell Integration

What You Need to Know Before Programming a Cobot

Collaborative robots — cobots — are designed to be programmed by the people who use them, not just by robotics specialists. That design philosophy shapes everything about how cobot programming works: the methods are more accessible, the languages are higher-level, and the tools assume less prior robotics knowledge than a traditional six-axis industrial robot requires.

But "more accessible" does not mean "push a button and walk away." A cobot still needs a well-defined job — waypoints, speeds, I/O triggers, and safety boundaries — before it can run reliably in production. And when that cobot lives inside a PLC-controlled cell, the controls engineer needs to understand how the robot program and the PLC program talk to each other.

This guide covers every major cobot programming method, the languages and tools behind them, and — critically — the electrical and communications handshake that ties a cobot into a PLC-managed production cell.

---

What Is Cobot Programming?

Cobot programming is the process of defining the motion paths, I/O logic, speed profiles, and safety behaviors that a collaborative robot executes during a task. Unlike traditional industrial robot programming — which typically requires offline simulation, vendor-specific high-level languages, and a dedicated robotics programmer — cobot programming is built around methods that a maintenance technician or controls engineer can use directly on the shop floor.

The three practical outcomes of any cobot program are:

1. Waypoints — the Cartesian or joint-space positions the robot moves through
2. Actions — gripper open/close, camera trigger, conveyor signal, tool change
3. Logic — conditionals, loops, error handling, and communication with external equipment

How you define those three things depends on which programming method you use.

---

The Main Cobot Programming Methods

Lead-Through / Hand-Guiding

Lead-through programming (also called hand-guiding or teach-by-demonstration) lets the operator physically move the robot arm to each target position and record it. Most cobots have a dedicated button or handle on the end-effector or wrist that puts the arm into a compliant, gravity-compensated mode. The operator guides the arm, presses "record waypoint," and repeats until the path is complete.

When it works well:

• Pick-and-place tasks with a small number of fixed positions
• Tasks where the path is easier to show than to describe numerically
• Rapid reteaching after a fixture changes

Limitations:

• Not practical for paths with dozens of fine waypoints
• Positioning repeatability depends on the operator's steadiness
• Complex conditional logic still needs the pendant or a script

Visual / Block-Based Teach Pendant Programming

Every major cobot vendor ships a tablet-style teach pendant with a drag-and-drop block interface that represents program steps as graphical tiles. Universal Robots calls its system PolyScope; FANUC CRX uses the TP with collaborative extensions; Doosan has the DART platform; Techman uses TMflow.

A typical block-based program looks like this (using UR PolyScope logic as an example):

[MoveJ → Home]
[Wait → digital_in[0] == True]   // Part present signal from PLC
[MoveL → Pick Position]
[Set → digital_out[1] = True]    // Gripper close
[Wait → 0.5 s]
[MoveL → Approach]
[MoveJ → Place Position]
[Set → digital_out[1] = False]   // Gripper open
[Set → digital_out[2] = True]    // Cycle complete to PLC
[MoveJ → Home]

This style of programming feels familiar to anyone who has written function block diagrams or sequential function charts in a PLC. The structure is explicit, the I/O references are visible, and the flow is linear until you add branches.

When it works well:

• Standard pick-and-place, assembly, screw-driving, and palletizing tasks
• Multi-step processes where visibility into the sequence matters
• Sites where operators need to modify programs without writing code

Scripting: URScript, Python, and Vendor APIs

When a task outgrows what block programming handles cleanly — complex math, dynamic path generation, vision-guided adjustment, or tight real-time control — you reach for a scripting language.

URScript is Universal Robots' native scripting language. It is a Python-flavored procedural language that runs directly on the controller. URScript gives you access to every robot function: motion commands, I/O, force control, tool center point definitions, and socket communication.

A minimal URScript cycle looks like this:

def pick_and_place():
  set_digital_out(0, False)       # Gripper open
  movej([0, -1.57, 1.57, -1.57, -1.57, 0], a=1.2, v=0.5)  # Home (joint angles, rad)
  movel(p[0.400, -0.200, 0.150, 0, 3.14, 0], a=0.5, v=0.1) # Pick approach
  movel(p[0.400, -0.200, 0.050, 0, 3.14, 0], a=0.3, v=0.05) # Pick point
  set_digital_out(0, True)        # Gripper close
  sleep(0.3)
  movel(p[0.400, -0.200, 0.150, 0, 3.14, 0], a=0.5, v=0.1) # Retract
  movej([0, -1.57, 0.5, -1.0, -1.57, 0], a=1.2, v=0.5)    # Place position
  set_digital_out(0, False)       # Gripper open
  sleep(0.3)
end

Python via RTDE or URCap SDK extends UR cobots further. Universal Robots' Real-Time Data Exchange (RTDE) interface lets an external PC or controller send setpoints, read joint states, and trigger events at 500 Hz — useful for vision-guided correction or force-torque feedback loops.

Other vendors offer equivalent APIs: Doosan DRL (Python-based), FANUC Karel (Pascal-like) with collaborative-mode extensions, and ABB RAPID for the CRB/GoFa range. See the ABB robot programming tutorial and FANUC robot programming tutorial for vendor-specific scripting details.

Offline Programming and Simulation

Offline programming (OLP) tools — RoboDK, Octopuz, or vendor simulators like UR Sim — let you program the cobot entirely in a 3D model of the cell before the physical hardware is installed. You import CAD models, define waypoints on the part geometry, simulate the motion, and export the program to the real controller.

OLP pays off on:

• Spray, welding, or sanding paths with hundreds of waypoints
• Programs that need to be verified for reach and collision before the cell is built
• Multi-robot cells where sequencing must be proven offline

---

Step-by-Step: Programming Your First Cobot Job

The following procedure uses a UR cobot with PolyScope as the reference, but the logic applies to any platform.

Step 1 — Risk assessment first. Before touching the teach pendant, complete a collaborative risk assessment per ISO/TS 15066. Identify the tool, the task, and the force/speed limits that keep the application within Power and Force Limiting (PFL) mode. The program you write will be wrong if the safety configuration is wrong.

Step 2 — Set the tool center point (TCP). Mount your end-effector and define its TCP in the robot's installation settings. A wrong TCP means all your taught positions are offset.

Step 3 — Define waypoints with hand-guiding or jog. Use the pendant's jog function (or hand-guide mode) to move the robot to each key position — home, approach, pick, retract, place. Record each as a waypoint. Always include an approach position above the pick/place point so the robot doesn't drag through the part.

Step 4 — Build the sequence in the block editor. Assemble Move, Wait, Set I/O, and Gripper commands into a program. Add the I/O wait conditions that synchronize the cobot with your PLC (more on this below).

Step 5 — Set motion parameters. Assign acceleration and velocity to each move. Slower on approach, faster on transit moves. Blend radius (blending) keeps the robot from dwelling at each intermediate waypoint.

Step 6 — Simulate in reduced-speed mode. Run the program at 25% speed in manual mode. Watch for unexpected joint configurations, cable snag risks, and timing issues.

Step 7 — Integrate I/O and test the full cell cycle. Enable the PLC and run the complete cell cycle. Verify interlocks fire in the correct order. Log any cycle-time discrepancies.

Step 8 — Document and protect the program. Save a backup of the program file off the robot. Set a password or lock the installation settings to prevent accidental modification.

---

Cobot Programming Languages Compared

Vendor	Language / IDE	Style	External API
Universal Robots	URScript / PolyScope	Python-like script + graphical blocks	RTDE, Dashboard Server, URCap SDK
FANUC CRX	TP Language / iHMI	Pendant blocks + TP text	KAREL, PCDK
ABB CRB / GoFa	RAPID / Wizard Easy Programming	Procedural text + graphical	RWS (Robot Web Services), EGM
Doosan	DRL / DART Platform	Python-based + graphical	DRFL (C++)
Techman	TMflow	Node-based visual + script nodes	TM ROS2, Modbus TCP
Kawasaki duAro	AS Language	Text-based	Ethernet socket
Omron TM (same as Techman)	TMflow	Node-based visual	TM ROS2

For controls engineers already fluent in industrial robot programming, the transition to cobot scripting is incremental. The motion model is the same (joint-space vs. Cartesian moves, blending, singularity avoidance); what changes is that the language is higher-level and the safety functions are built into the controller firmware rather than managed externally.

---

How Long Does Cobot Programming Take? Is It Hard?

For a simple pick-and-place with 4–6 waypoints and basic I/O: an operator with no prior robot experience typically needs 2–4 hours to complete the first program using lead-through + block pendant, including calibration. An experienced controls engineer can do the same task in under 30 minutes.

For a vision-guided or force-controlled application: budget a full day for the robot program alone, plus integration and tuning time.

Is cobot programming hard? Compared to traditional industrial robots, no — the tools are designed to lower the barrier. Compared to writing PLC ladder logic, it is roughly equivalent in complexity for simple tasks. The conceptual leap for a PLC programmer is shifting from scan-cycle event logic to a sequential motion program that blocks while executing moves.

The concepts that trip up PLC programmers most often:

• Blocking vs. non-blocking motion — robot moves block execution until complete; you cannot run motion and I/O logic in parallel without threading or event nodes
• TCP and coordinate frames — the robot moves relative to a reference frame; getting this wrong shifts every position
• Force and speed limits in collaborative mode — reducing speed to stay within ISO/TS 15066 contact force limits costs cycle time; this is a design parameter, not a setting to minimize blindly

---

The PLC-Integrated Cobot Cell

This is where cobot programming intersects most directly with controls engineering work. A standalone cobot running in free-standing demo mode is very different from a cobot embedded in a PLC-controlled production cell with conveyors, fixtures, vision, and safety guarding.

Digital I/O Handshake: The Foundation

The simplest and most reliable integration method is hardwired digital I/O. The cobot controller exposes configurable digital inputs and outputs (typically 8–16 channels on a standard UR controller). The PLC uses its own digital I/O to communicate with those channels.

A basic three-signal handshake covers most applications:

Signal	Direction	Meaning
Robot Ready	Cobot → PLC (output)	Robot is at home, waiting for cycle start
Part Present / Cycle Start	PLC → Cobot (input)	Fixture is loaded, safe to proceed
Cycle Complete	Cobot → PLC (output)	Robot has finished, PLC can unload/advance

In the cobot program, this translates to:

# URScript example — PLC handshake loop
while True:
  set_digital_out(0, True)         # Robot Ready signal to PLC
  wait_for_tool_contact()          # Or: while not get_digital_in(0): sleep(0.05)
  # PLC raised Part Present (digital_in[0])
  set_digital_out(0, False)        # Clear Robot Ready
  pick_and_place()                 # Execute the task
  set_digital_out(1, True)         # Cycle Complete to PLC
  sleep(0.2)
  set_digital_out(1, False)        # Pulse, not latched
end

On the PLC side (ladder logic or structured text), the mirror logic holds the conveyor stopped until Cycle Complete goes high, then indexes the next part.

Register and Protocol-Based Communication

For more data-rich integration — passing part type, recipe number, reject reason, or position offsets — use a fieldbus protocol. Most cobot controllers support one or more of the following:

Modbus TCP is the lowest-friction option. UR controllers run a native Modbus TCP server. The PLC (acting as Modbus TCP client) reads and writes holding registers directly to the cobot. Register 128 on a UR controller maps to digital output 0; the register map is published in the UR support documentation.

PROFINET and EtherNet/IP require a URCap (UR) or vendor-specific option package. With PROFINET active, the cobot appears on the network as a standard PROFINET device with a configurable GSD file, and the PLC controls it through the standard process image. This approach is common in Siemens TIA Portal environments.

EtherNet/IP is the preferred route for Allen-Bradley / Rockwell cells. The cobot controller maps its I/O and status registers into EtherNet/IP assembly objects, and the CompactLogix or ControlLogix controller reads them via an implicit (Class 1) connection. The material handling PLC programming guide covers the Rockwell side of this integration in detail.

Wiring Safety-Rated I/O Into the Cell Safety Circuit

A cobot running in collaborative mode (no guarding, reduced speed) and a cobot running as a standard industrial robot (full guarding, unrestricted speed) need different safety architectures. Most production cells land somewhere between the two extremes.

Safety-rated I/O (Cat 3 / PLd per ISO 13849, or SIL 2 per IEC 62061) is required for:

• Emergency stop loop integration
• Safety gate / interlocked guard monitoring
• Enabling device (3-position switch) on the teach pendant
• Muting of the collaborative safety functions when a human is not present

UR controllers include a dedicated Safety I/O terminal block (separate from the general-purpose I/O) with dual-channel inputs for E-stop, safeguard stop, and reduced-mode signals. These must be wired in series with the cell's E-stop relay chain — not through the PLC's standard I/O, which is not safety-rated.

Practically: the cell safety relay (or safety PLC like a Pilz PNOZmulti or Siemens F-CPU) monitors the guard interlocks and drives both the cobot safety input and the main machine E-stop loop simultaneously. The general-purpose PLC handles production sequencing; the safety circuit handles hazard response independently.

Teach vs. Code: A Decision Framework for Controls Engineers

If you know ladder logic but are new to cobots, use this decision tree:

• Task has fewer than 20 waypoints and straightforward I/O → Use the block pendant. It is faster and easier to hand off to operators.
• Task needs dynamic path adjustment (vision, force feedback) → Use script (URScript, DRL, RAPID). Write functions, not flat sequences.
• Cell has a Siemens PLC → Evaluate PROFINET integration with the cobot; it maps cleanly to TIA Portal's drive/axis model.
• Cell has a Rockwell PLC → Use EtherNet/IP or hardwired I/O. Modbus TCP is a fallback if the option package is not available.
• You need to reuse program logic across multiple robot types → Evaluate ROS 2 with MoveIt, or a vendor-agnostic OLP tool. This adds complexity; justify it carefully.

For a deeper look at the differences between cobots and traditional robots before committing to an architecture, see robot vs cobot and what is a cobot.

---

Frequently Asked Questions

How do you program a cobot?

You program a cobot by combining one or more of four methods: lead-through/hand-guiding (physically moving the arm to record positions), block-based teach pendant (drag-and-drop graphical programming on the vendor's tablet interface), scripting (URScript, Python, RAPID, or DRL for complex logic), and offline simulation (RoboDK or vendor simulators for path-intensive applications). Most real production programs use the pendant for the motion structure and add script nodes or external PLC I/O for logic.

What language do cobots use?

The language depends on the vendor. Universal Robots use URScript (Python-flavored) alongside the PolyScope graphical interface. FANUC CRX uses TP language with Karel for advanced functions. ABB CRB/GoFa uses RAPID. Doosan uses DRL, which is Python-based. Most vendors also expose fieldbus interfaces (Modbus TCP, PROFINET, EtherNet/IP) and REST or socket APIs for integration with external systems.

Is cobot programming hard?

For simple pick-and-place tasks, cobot programming is accessible to operators with no prior programming experience — vendor block-based UIs are designed for this. For controls engineers with PLC programming backgrounds, it is comparable in difficulty to sequential function chart programming. The main adjustment is learning the robot's coordinate frame model and the motion-blocking execution model. Complex tasks (vision guidance, force control, multi-robot coordination) require scripting skills and a solid understanding of the robot's kinematics.

Can a PLC control a cobot?

Yes, and this is the standard architecture in production environments. The PLC manages cell sequencing, conveyor control, fixture clamping, and safety logic. The cobot handles the manipulation task. Communication between them uses hardwired digital I/O for simple handshakes (robot ready, cycle start, cycle complete) or fieldbus protocols — PROFINET, EtherNet/IP, or Modbus TCP — for richer data exchange. The cobot's safety-rated I/O must be wired directly into the cell safety circuit, not routed through the standard PLC I/O.