A robot is the easy part. The cell around it - tooling, safety, PLC handshake, part presentation - is where the schedule goes. Here is what FANUC programming work actually involves on an industrial cell, and what to have ready before the integrator shows up.

Start with reach, payload and cycle - not the program

Before a single line of TP code matters, three numbers decide whether the cell works: the reach envelope at the wrist, the payload at the tool flange including the gripper and cable, and the cycle time at the real travel distance. A robot rated for 20 kg at the flange is not a 20 kg robot once a 6 kg end effector, 2 kg of cabling and a part with a high centre of gravity are hanging off it.

FANUC publishes load curves, not a single number. Check the curve at the actual moment arm, not at zero offset. We regularly see cells quoted at 90% of rated payload where the acceleration curve at full extension tells a different story - the robot runs, but it runs slower than the cycle time assumed in the business case.

Tool frames and user frames do the heavy lifting

Most programming problems that look like robot problems are frame problems. A TCP set by eye is worth a few millimetres at best, and on a welding or dispensing cell that is a rejected part. Define the tool frame with a proper six-point or three-point method, verify with a pointer, and re-verify after any tooling change.

User frames are the other half. If the part sits on a fixture, define the fixture as a frame and program in that frame. Then a fixture that shifts 10 mm after a crash can be re-taught by re-defining one frame instead of re-teaching every point in the program. This is the single cheapest habit to build into a cell.

Safety configuration is not a jumper

Modern FANUC controllers - R-30iB and R-30iB Plus - have dual-channel safety inputs tied to DCS (Dual Check Safety) zones, joint position limits and Cartesian speed limits. These are configured in software and must be validated, not assumed. A cell that relies on a fence gate switch and a single e-stop string is not a compliant cell in Ontario; CSA Z434:26 - the 2026 fourth edition, which adopts ISO 10218-1:2025 and ISO 10218-2:2025 with Canadian deviations - and the risk assessment drive what the safety circuit actually has to do.

Practically: the safety configuration has to be locked with a password nobody shares casually, the validation has to be documented with the speeds and zones tested, and any change after commissioning needs a re-validation. Auditors ask for it. Insurers ask for it after an incident.

Offline programming vs the teach pendant

Offline programming - ROBOGUIDE or a third-party package - pays for itself when the part geometry exists as CAD, the fixture is designed, and the cell is repeatable. It saves floor time during commissioning and lets you prove reach and collision before steel is cut. It does not remove the need for on-site touch-up: real parts, real fixtures and real tolerances always shift a few millimetres.

For low-volume or one-off cells, teaching on the pendant is faster and honest. The rule of thumb: if the same motion repeats across more than a handful of variants, build the offline model; if the cell runs three parts a year, teach it and document it.

The PLC handshake

The robot does not run the cell - the PLC does. The handshake between them carries the part-present signal, program number selection, cycle start permissive, in-cycle, fault and reset. Get this documented as an I/O map before programming: which bits, which direction, what the PLC does if the robot faults mid-cycle, and how the operator recovers without a maintenance call.

Most "robot faults" we get called to are handshake or permissive problems. Logging the handshake bits in the PLC makes them diagnosable in minutes instead of hours.

What to have ready before we start

  • Robot model, controller version and any option packages already licensed (DCS, vision, force sensing).
  • Fixture and gripper drawings, or the physical tooling on site.
  • The safety risk assessment, or the requirement to produce one.
  • PLC platform and the existing I/O standard on that line.
  • The parts, or at minimum representative parts with the real tolerance range.
  • Cycle time target - not "as fast as possible".

If you are planning a robot cell or inheriting one that has never been properly documented, our robotics and automation work covers programming, safety validation and the PLC side together - which is usually where the delay hides.