Learn Universal Robots Programming & URScript — Free, in Your Browser
Universal Robots (UR) cobots are programmed two ways: the PolyScope teach pendant and the URScript text language. This guide explains both accurately — movej vs movel, waypoints and blends, gripper I/O, TCP and payload — then lets you write real URScript on a simulated UR5e arm. No robot. No install. No vendor license.
The two ways
How you actually program a Universal Robot
Every UR arm — the UR3e, UR5e, UR10e, UR16e and the larger models — ships with the same software, so the programming approach is identical across the range. There are two ways in, and experienced programmers move between them constantly.
1. PolyScope (graphical teach pendant)
PolyScope is the touchscreen interface on the UR teach pendant. You build a program tree by adding nodes — Waypoints, Move blocks (MoveJ / MoveL), I/O actions, and If / Loop logic. Crucially, you teach poses by physically jogging the arm to a position by hand and saving it as a waypoint, rather than typing coordinates. It is the fastest way to get a working program and the way most operators start. Under the hood, PolyScope generates URScript for everything you build.
2. URScript (text programming)
URScript is UR’s text-based language, with a Python-like syntax. You write commands directly — movej, movel, set_digital_out, set_tcp — either inside a Script node in a PolyScope program, sent over a socket from a PC, or as a complete .script file. Text gives you full control: real variables, math, loops, functions, and threads that are awkward to express in the graphical tree. It is the same language whether you are on a UR3e or a UR16e.
The takeaway: PolyScope and URScript are not rival products — they are two views of the same robot. PolyScope is generated URScript with a friendly front end. Learning URScript is what makes you fluent, because it is what the controller actually runs.
How PolyScope nodes map to URScript
Every graphical node you add on the teach pendant compiles to a URScript line. Once you can read that mapping, the two ways stop feeling separate.
PolyScope node
Generated URScript
MoveJ waypoint
movej(pose, a=1.4, v=1.0)
MoveL waypoint
movel(pose, a=1.2, v=0.25)
Set DO action
set_digital_out(0, True)
Wait DI
while not get_digital_in(2): sync()
Set TCP / Payload
set_tcp(...) / set_payload(...)
Loop / If node
while ... : / if ... :
A UR arm has six rotary joints (J1–J6); both PolyScope and URScript ultimately move this TCP.
URScript essentials
The URScript commands that matter most
You can program a working UR cell with a small core of URScript. Here is the essential vocabulary, used correctly.
Motion: movej vs movel vs movep
movej — moves in joint space. Each joint interpolates from its current angle to the target angle. Fast and efficient, but the tool follows a curved path. Best for free-air moves between stations.
movel — moves the tool in a straight Cartesian line at a controlled tool speed. Use it for approach, insertion, and any move where the tool’s path matters.
movep — moves the tool linearly at a constant speed with circular blends, for process paths like dispensing or gluing where steady tool velocity is required.
Waypoints & blend radius
A waypoint is a taught target pose. By default the arm stops at each one. Add a blend radius and the arm rounds the corner — it never fully stops, so a chain of moves flows smoothly and the cycle time drops. Bigger blend = smoother and faster, but the path cuts the corner more, so blends are a trade-off you tune per move.
I/O & gripper control
set_digital_out(n, True/False) sets a digital output — the usual way to fire a 2-finger gripper or signal a conveyor. get_digital_in(n) reads an input, for example a part-present sensor. Picking something up is just: move to the part, set the gripper output to close, lift.
set_tcp & set_payload
set_tcp(pose) tells the robot where the working point of the tool is relative to the flange, so movel lines are straight at the tool tip, not the wrist. set_payload(mass) tells the robot how heavy the tool-plus-part is so it controls motion accurately and its safety/force monitoring stays correct. Getting both right is essential for accuracy and safe cobot operation.
movej vs movelWaypoints & blendsGripper & I/OTCP & payload
# A first URScript pick-and-place on a UR5e
set_tcp(p[0, 0, 0.15, 0, 0, 0]) # tool point: 150 mm gripper
set_payload(0.8) # 0.8 kg tool + part
movej(home_q, a=1.4, v=1.0) # joint move to a safe home pose
movel(pick_approach, a=1.2, v=0.3) # straight line above the pick
movel(pick, a=0.5, v=0.1) # straight down onto the part
set_digital_out(0, True) # close the gripper
sleep(0.4)
movel(pick_approach, a=1.2, v=0.3) # lift straight up
movel(place, a=1.2, v=0.25) # straight line to place B
set_digital_out(0, False) # open the gripper
movej(home_q, a=1.4, v=1.0) # return home
That is real URScript — the exact same commands run on a physical UR controller. In the simulator you write this, the arm solves the inverse kinematics for each pose, and you watch it run under physics.
Each URScript move is parsed, solved with inverse kinematics, planned, and run on the arm.
Learn UR programming
A step-by-step path from zero to a graded cell
You do not learn robot programming by reading — you learn it by writing code and watching the arm move. This is the order that works, and it is the order the lessons follow. Every step runs against a simulated UR arm and is graded against a real goal.
1 · Jog the arm
Move the UR in joint space and Cartesian space; understand base vs tool frames and how the tool center point (TCP) is defined before you write any code.
2 · Your first moves
Write movej and movel to send the arm between poses; see how acceleration (a) and velocity (v) change the motion, and when each move type is right.
3 · Digital I/O & gripper
Use set_digital_out and read inputs with get_digital_in; open and close a gripper so the arm can actually pick something up.
4 · Pick-and-place A→B
Combine approach, grasp, lift, traverse, place, and release into the core cobot skill — a complete pick-and-place cycle.
5 · Waypoints & blends
Chain waypoints and add a blend radius so the arm flows smoothly through points instead of stopping at each one, for faster cycle times.
6 · Payload & TCP
Configure set_payload and set_tcp correctly and see how they change reach, accuracy, and the safe speed of the arm.
7 · Protective stop & safety
Trigger and avoid a protective stop; understand cobot force limits and safety planes so your program stays within safe limits.
8 · Graded capstone
Program a complete cell — palletise parts into a pattern with no collision, under a cycle-time budget, and within force limits — and earn the pass.
Cobot safety
Protective stops and force limits
Universal Robots are collaborative robots — designed, with a proper risk assessment, to work near people. They achieve that mainly through force and power limiting: the controller monitors joint forces, and if it detects an unexpected contact or exceeds a configured force threshold, it triggers a protective stop — the arm halts immediately. You also define safety planes, speed limits, and reduced-speed zones in the safety configuration.
For a programmer this means two habits: keep the set_payload value accurate so force monitoring works correctly, and design moves that respect the cell’s safety limits. A simulator is the right place to learn this — you can deliberately trigger a protective stop and learn to avoid it without ever damaging a real arm or risking a person. A collaborative rating is never a substitute for a real safety assessment on a deployed cell.
A UR cobot force-limits its motion and protective-stops on unexpected contact.
Why a simulator
Practice the real language, with no robot and no risk
vs a real UR arm
A UR arm costs tens of thousands and one bad move can damage tooling. The simulator lets you fail safely and repeat a task endlessly — the only way to actually build skill — at zero cost and zero risk.
vs URSim
UR’s official URSim is the real controller software but ships as a Linux virtual machine that beginners find heavy to install. Ours opens in a browser tab on any computer, with lessons that teach from zero.
Real URScript
You write the same movej, movel, set_digital_out, set_tcp and set_payload you would type into a real UR — so the language and habits transfer straight onto PolyScope and a physical controller.
There are two ways, and most programmers use both. The first is PolyScope, the graphical interface on the UR teach pendant: you build a program tree by adding nodes (Waypoints, MoveJ/MoveL blocks, I/O actions, If/Loop logic) and you teach poses by physically jogging the arm to a position and saving it as a waypoint. The second is URScript, UR’s text-based programming language: you write commands like movej and movel directly, either inside a Script node in PolyScope or as a complete .script program sent to the controller. PolyScope is faster to start with; URScript gives you full control for complex logic, math, and reuse.
Universal Robots use URScript, UR’s own scripting language, as the underlying programming language. Every PolyScope program ultimately compiles down to URScript commands. URScript has a Python-like syntax with functions, variables, loops, and built-in motion commands (movej, movel, movep), I/O commands (set_digital_out, get_digital_in), and configuration commands (set_tcp, set_payload). You can write it directly or let PolyScope generate it from the graphical program tree.
URScript is the text-based robot programming language built into every Universal Robots controller. It looks similar to Python and gives you direct control of the arm: motion (movej, movel, movep, servoj, speedl), digital and analog I/O (set_digital_out, get_digital_in), tool configuration (set_tcp, set_payload), and program flow (functions, while/if, variables, threads). You can run URScript as a Script node inside a PolyScope program, send it over a socket from a PC, or load a complete .script file. The same URScript you practice in a simulator runs unchanged on a real UR controller.
Both move the arm to a target pose, but they interpolate differently. movej moves in joint space: each joint goes from its current angle to its target angle, so the motion is fast and energy-efficient but the tool follows a curved, hard-to-predict path through space — ideal for free-air moves between stations. movel moves in a straight Cartesian line: the tool center point travels in a literal straight line at a controlled tool speed, which is what you want for approaching a part, inserting, or following an edge. The rule of thumb: movej to get there fast, movel when the path of the tool matters.
Yes. You can learn the fundamentals of Universal Robots programming free in your browser — no robot, no install, no vendor license. Our simulator lets you write real URScript and run it on a simulated UR arm with the first lessons free, so you can practice movej, movel, waypoints, I/O, and a gripper before you ever touch hardware. UR also publishes free PolyScope documentation and an Academy, and the official URSim offline simulator is free but runs as a heavier Linux virtual machine.
No. The whole point of a simulator is to build real programming skill before you touch a physical arm — which is the safest and cheapest way to learn. You write the same URScript, the simulator solves the kinematics and runs the motion under physics, and you can repeat a task a hundred times at zero cost or risk. When you do reach a real UR arm or PolyScope, the language, the motion model, and the habits transfer directly because you practiced the real thing.
Start programming a UR arm today.
Write real URScript on a simulated UR5e in your browser. No robot, no install, no vendor license — the first lessons are free.
Independent vendor-platform field guide
Universal Robots programming: transfer checklist
Direct answer
The learner can design and test a transferable sequence while separating browser evidence from URSim, controller and cell validation.
Written for robot learners planning a bounded Universal Robots task with frames, waypoints, motion, payload, I/O and recovery.
System map / 02
NODE 01observable
01
Platform context
Robot model, software version, base and tool frames, TCP, payload, waypoints, motion type, I/O, cell state and recovery.
NODE 02observable
02
Tags and addressing
Program node or script statement through path generation, controller output, robot motion and independent process feedback.
NODE 03observable
03
Reference pattern
Home, approach, process, depart and return behavior executed at deliberate training settings.
NODE 04observable
04
Timing and limits
Reach, singularity, blend, TCP, payload, lost part, delayed I/O, interruption and restart.
NODE 05observable
05
Diagnostics
A frame, pose, path, motion, payload, handshake, process or recovery mismatch.
NODE 06observable
06
Official-tool transfer
The task recreated in current official tools and validated in the safeguarded target cell.
