Six-axis arm: poses, moves and cell I/O
Robot arm simulator: six-axis URScript motion, poses and gripper I/O
Direct answer
A robot arm simulator lets you program a six-axis arm without hardware and watch what each instruction does. This one runs a UR-style arm in the browser: you jog joints and the tool center point, write URScript such as movej, movel and set_digital_out, then run it under kinematics and physics and get graded on placement, collisions, cycle time and contact force.
This guide is written for automation students, PLC technicians moving into robot cells and instructors who want learners to reason about poses, move types, gripper I/O and protective stops before anyone stands at a teach pendant. The intended result is specific: the learner can write a pick-and-place program with deliberate approach and retreat poses, justify every joint or linear move, and diagnose an unreachable target, a collision or a protective stop from the program text and the graded result.
Base frame and pose vectors
URScript writes a pose as p[x, y, z, rx, ry, rz]: position in metres and orientation as a rotation vector in radians, measured from the robot base. Watching the pose readout while you jog shows which way +X and +Y actually point in the cell, which is the only reliable way to sanity-check a typed coordinate before the arm moves to it.
Tool center point
set_tcp tells the controller where the working point sits relative to the tool flange. With a 150 mm gripper and no TCP offset, every target is reached by the flange instead of the fingertips, so the part is missed by roughly the tool length. Define the TCP at the top of the program, then teach or type every pose against it.
Joint versus linear motion
movej interpolates each joint angle from start to finish. It is fast and tolerant of awkward wrist positions, but the tool follows an arc you did not specify. movel holds the TCP on a straight line, which approach, insertion and retreat moves need, at the cost of more joint travel and sensitivity to singular configurations along the path.
Singularities and reach
A six-axis arm loses a usable degree of freedom when joint axes line up: at a wrist singularity the fifth joint is near zero, at an elbow singularity the arm is fully stretched, and at a shoulder singularity the wrist passes near the base axis. Close to these, a short straight move demands very large joint speeds. A target beyond the envelope has no solution at all.
Payload and tracking
set_payload declares the mass the arm is carrying. A real controller uses it in its dynamic model and collision detection, and a wrong value is a common cause of nuisance protective stops. In the simulator the declared mass is applied to the dynamic arm model, so a heavier part visibly changes how closely the arm follows its planned trajectory.
Digital I/O as the cell contract
An arm rarely works alone. Digital outputs close the gripper and report cycle done or a fault to a PLC; digital inputs bring cycle start, part present and a safety-clear permissive back. The simulator I/O panel lets you toggle those inputs and keeps a trace of every output change, so a get_digital_in wait and its acknowledgement become visible events.
- 01
Jog before you code
Rotate each joint, then drive the TCP in X, Y and Z while watching the pose readout.
Evidence: You can predict the axis and sign of a Cartesian jog before pressing the button.
Avoid: Copying pose values from an example without knowing which frame they were taught in.
- 02
Declare tool and load
Open the program with set_tcp and set_payload that match the gripper length and part mass.
Evidence: A reach task lands the fingertips, not the flange, inside the stated millimetre tolerance.
Avoid: Leaving the TCP at the flange and compensating by hand-editing every target height.
- 03
Lay out the path skeleton
Send the arm to a safe home with movej, then use movel to an approach pose above the pick, straight down, and straight back up to the same approach pose.
Evidence: Approach and retreat are vertical lines and the grader reports no collision.
Avoid: Using movej for the last few centimetres into a fixture, where its arc can sweep through the part.
- 04
Sequence the gripper
Close the gripper with set_digital_out only after the arm has arrived, dwell with sleep, then lift; open it at the place pose before retreating.
Evidence: The part travels with the gripper and is released at the target within tolerance.
Avoid: Switching the gripper during motion or lifting before the fingers have finished closing.
- 05
Tune for cycle time
Raise v and a on free-air joint moves while keeping the final linear approach slow.
Evidence: The graded run finishes inside the cycle-time budget without a protective stop.
Avoid: Scaling every speed uniformly, including the contact move, and trading cycle time for a force trip.
- 06
Break it deliberately
Push one target out of reach, route a move through a fixture and delete the payload line, one change per run.
Evidence: Each fault produces a specific failed check that you can explain and then reverse.
Avoid: Editing several poses at once and losing track of which change caused the failure.
| Observed symptom | Inspect | Interpretation | Next proving action |
|---|---|---|---|
| Program stops with a reachability error | The failing target pose, its distance from the base, its orientation values and the TCP offset in force at that line | No joint solution exists for that pose; a long tool offset or a steep tool angle can push an apparently nearby point outside the envelope. | Move the target closer or relax the orientation, then re-run that single move before restoring the rest. |
| Gripper closes on air beside or above the part | The set_tcp values, the pick pose height and the part position shown in the cell | The pose is being reached by the wrong point on the tool, usually because the TCP is missing or offset along the wrong axis. | Run a reach-only task and compare the reported millimetre error with the tool length. |
| Collision while travelling to the pick | Which move collided, its move type, and its start and end poses | movej fixes only the endpoints; the tool path between them is an arc that can dip into fixtures or the table. | Insert a clear approach pose above the obstacle and make the final descent a movel. |
| Short straight move produces a large wrist rotation | The fifth joint angle, how far the arm is extended and whether the path passes near the base axis | The linear path runs close to a singular configuration, where holding a straight TCP line needs disproportionate joint motion. | Change the tool orientation for that segment or reach it with movej between two clear poses. |
| Protective stop during the place move | Final approach speed, place height relative to the surface, the declared payload and where contact occurred | Contact force exceeded the task limit; driving a held part into the surface is the usual cause. | Stop the linear approach a few millimetres above the surface, slow it down and release there. |
| Arm waits indefinitely for the PLC | The input index polled by get_digital_in, its state in the I/O panel and the signal trace | The program is waiting on the wrong input, or the start request was removed before the robot sampled it. | Check the index against the signal list and hold the request until the robot answers with cycle done. |
Product evidence / 05
What the browser practice can actually demonstrate
The simulator parses URScript, solves inverse kinematics for each pose target, builds a timed joint trajectory and tracks it under rigid-body physics. Graded checks report whether the program runs, whether the tool or part reached its target within tolerance, whether anything collided, whether the cycle-time budget held and whether contact force tripped a protective stop.
When should I use movej and when movel?
movej moves every joint from its start angle to its end angle, so it is usually the quickest move and copes with awkward wrist positions, but the tool path between the endpoints is curved. movel keeps the tool center point on a straight line. Use movej for free-air travel and movel for approach, pick, place and retreat.
What is a TCP and why should it be set first?
The tool center point is the working point of the tool, such as the gap between gripper fingers, defined as an offset from the flange. Every pose target is reached by the TCP. If it is left at the flange, all taught positions are wrong by the tool length, and correcting them pose by pose hides the real mistake.
What causes a robot arm singularity?
A singularity occurs when two or more joint axes align and the arm can no longer move its tool freely in every direction. Typical cases on six-axis arms are a straight wrist, a fully stretched elbow and the wrist passing close to the base axis. Linear moves near these configurations need very high joint speeds, so choose poses that stay clear of them.
Why does my simulated arm trigger a protective stop?
In this simulator a protective stop means contact with an obstacle exceeded the task force limit. The usual causes are a place or pick pose set below the surface, a fast final approach or a joint move whose arc hits a fixture. Raise the target slightly, slow the last linear move and add a clear approach pose.
How do a PLC and a robot arm exchange signals in a cell?
Most cells use a handshake of discrete signals or fieldbus bits: the PLC reports ready and requests a cycle when a part is present, the robot answers ready, cycle done or fault. The arm program waits on inputs and sets outputs; the PLC program sequences the cell. The robot-handshake scenario practices the PLC side of that exchange.
Does simulated cycle time match a real robot?
No. The simulator times a planned trajectory from your speed and acceleration values on a teaching model. A real controller applies its own motion planner, payload limits, safety configuration and speed settings, so physical cycle time can differ. Use the simulated budget to compare your own program versions, then measure the real cell.
Can I practice robot types or languages other than a UR-style arm?
The lesson list also includes SCARA, Cartesian and delta robot exercises and pick-and-place lessons written in ABB RAPID, KUKA KRL and FANUC TP style, most of them in the Pro tier. They are learning subsets for comparing concepts, not vendor controllers, and should be verified in the manufacturer tools before real use.
What should I check before running a simulated program on a real arm?
Confirm the TCP, payload, frames and home position against the physical tool and cell, and review every pose because the real cell layout will differ. Run first at reduced speed under the site procedure, with guarding and safety configuration already validated by qualified people. A simulated pass is design evidence only, not a commissioning result.