FANUC User Frame and Tool Frame Setup: Teaching UTOOL and UFRAME Without Losing Your TCP Accuracy

You move a finished offline program from RoboGuide to the real robot, run a slow test, and the TCP lands two centimeters off the part. Or the cell has been running fine for a year, the EOAT gets replaced, and suddenly every taught position is wrong. Or you wrote a clean program that uses a PR[] for a pick offset, and the robot ignores the frame you thought you were in. These are all the same root cause: the cascade of UTOOL and UFRAME is built on shaky math somewhere. At Probot Systems we see this every week, and the fix is almost always to redo the cascade in the right order.

This post is for programmers and integrators setting up tool frames (UTOOL) and user frames (UFRAME) on R-30iB and R-30iB Plus controllers across the FANUC range, from LR Mate and CRX through M-900iB and R-2000iC. The same logic applies across model sizes.

How UTOOL and UFRAME actually work together

UTOOL describes where the TCP is, relative to the wrist faceplate (Joint 6). It is a small transformation (X, Y, Z, W, P, R) that the controller adds to every motion command to figure out where the real working point of the tool is.

UFRAME describes where the work coordinate system is, relative to the robot base (the World frame). When a TP program issues a Cartesian move, the robot computes: World position = UFRAME[active] applied to the program’s XYZ, with UTOOL[active] applied at the wrist.

This cascade means that an error in UTOOL propagates into every UFRAME taught while that UTOOL was active. A 3mm UTOOL error becomes a 3mm UFRAME error becomes a 3mm offset on every point in your program. Worse, the error is rigid-body: the offset rotates as the tool orientation changes, so it does not look like a constant offset on a Cartesian path.

The FANUC alarm code manual entry for SYST-212 is worth quoting: “Mastering data or robot parameters are changed, but they are not applied to the DCS parameter. Remedy: Press F3(APPLY) in the DCS menu.” That alarm is the controller telling you that the mastering values it just received do not match the safety system’s last-known frame, which is what happens when you re-master without re-applying DCS. Until you press APPLY in MENU > SYSTEM > DCS, every frame in the cell is suspect.

Most common pitfalls

1. TCP taught with a different tool than the one currently mounted. Most common. Operator changes the EOAT to a smaller gripper, forgets that UTOOL[1] was taught against the old one, runs the program. Every point lands off. The Beginner-friendly tips from 10 years in automation thread points this out as a top-five mistake.
2. UFRAME taught with Three Point on a non-flat surface. Three Point method assumes the Z axis is vertical. If the fixture is tilted by even 2 degrees, Three Point will produce a frame that is wrong in Z and rotated.
3. Frame numbers reused or swapped between programs. Program A uses UF[1] for the part, Program B uses UF[1] for the fixture. When you copy code between programs, the wrong frame becomes active. Discipline matters: pick a convention (UF[1] = part, UF[2] = fixture, UF[3] = pallet) and document it in a comment file the team can read.
4. Cell moved or robot remounted, no re-teach. UFRAMEs are robot-base relative. Move the robot 5mm or re-shim it after a service event, and every UFRAME you trained before is now off by that same 5mm. The Incorrect robot movement after battery replacement thread shows the same pattern after mastering loss.
5. PR[] used without setting the right UFRAME. Position registers store coordinates without a frame. If you move a PR[] from one UF to another, the values do not transform. The Beginner-friendly tips thread captures this: “PRs don’t care which Tool or User Frame is selected and will attempt to” go where the raw XYZ says.
6. Mastering recently restored without DCS APPLY. SYST-212 is the giveaway. The frame math is using new mastering but DCS is using old mastering, and motion guards may stop the robot inside what should be valid envelope.

How to set this up correctly

Step 1. Teach UTOOL first, always. Mount the actual tool you will use in production. In MENU > SETUP > Frames > UTOOL, choose a 6-point or Three Point + XY + Z method, and use the tip-touch technique against a sharp fixed point (a precision pin works). The How to become an expert in one day thread lists this as the bedrock of any cell setup.

Step 2. Verify UTOOL. Switch to World jog, rotate the wrist around the TCP. The taught point should stay within a millimeter of the original position throughout the rotation. If it walks, your tip-touch was sloppy and UTOOL is wrong. Redo it.

Step 3. Teach UFRAME with the right method for the fixture geometry. Three Point assumes Z is vertical and only orients the XY plane. Six Point lets you define an arbitrary Z direction. For machine tending into a horizontal lathe, Three Point is fine; for welding a tilted fixture, use Six Point.

Step 4. Document UTOOL and UFRAME numbers and where they were taught. In the program comment header or in a maintenance binder. The TCP Reteaching thread is a recurring case where someone reteaches the TCP for a new EOAT, then sees old points land wrong, because the program was written against the previous UTOOL definition.

Step 5. Verify with a slow test program. Drive the robot to a known UFRAME position (typically 0,0,0 of the UFRAME) with the right UTOOL active. The TCP should land on the fixture scribe mark. If it does not, do not start tweaking PRs. Redo the cascade.

Step 6. If you recently mastered or restored mastering, go to MENU > SYSTEM > DCS and press F3 APPLY before clearing SYST-212. The motion envelope and any DCS zones reference mastering, and they need the new values.

How to do it right when things are already wrong

Mounted a new EOAT and points are off. Reteach UTOOL with the new tool. Then check whether your UFRAME was taught with the old UTOOL: if yes, reteach UFRAME too. If you taught UFRAME with a calibration pin (independent of the tool), UFRAME survives the EOAT swap.

Cell moved physically. Reteach every UFRAME against the fixtures in their new positions. UTOOLs do not need to be redone because they are wrist-relative.

Program references the wrong UF. Add an explicit UFRAME_NUM = 1 at the top of every program. Do not rely on the last-active frame surviving program calls. Same for UTOOL.

PR[] is misbehaving across frames. The Modifiying UFRAME through Position register thread covers a common confusion: a PR[] holds raw values, not “values in UFRAME[x]”. If you change UFRAME[1] in software via PR[], every program using UFRAME[1] sees the new definition. That can be powerful or disastrous, depending on whether you intended it.

SYST-212 after mastering work. MENU > SYSTEM > DCS, press F3 APPLY, reset the alarm.

Robot Offset PR[] error is worth reading as a case where the operator moved the robot in joint mode (only J2 and J3) to identify which UFRAME axis the offset was on. Useful debugging trick.

When to call a specialist

If you have redone UTOOL and UFRAME three times and the TCP still lands off the target by an unexplained amount, the next suspect is mastering. A robot that has lost some encoder counts (without throwing a BZAL) will produce frame errors that look like UTOOL or UFRAME errors but are actually deeper in the math. That is a mastering verification job.

For cells where the frame discipline matters for safety zones (a DCS area defined against UFRAME[2] needs UFRAME[2] to be exactly right), a specialist should verify the cascade before sign-off. contact us for a cell calibration audit, or set up a maintenance preventive contract that includes annual frame and TCP verification.

Related errors to check

• SYST-212 Need to apply to DCS param: mastering or parameter change not pushed to DCS. Press F3 APPLY in the DCS menu.
• MOTN-017 Limit error: appears when a position taught against a now-stale UFRAME ends up outside the robot’s reach.
• INTP-251 Vision frame error: vision process references a frame that was redefined.
• SRVO-062 BZAL: mastering loss after a battery event. Reteach mastering, then re-apply DCS, then verify frames.

Probot Systems is a FANUC integrator based in Lévis, Quebec. We commission and re-master FANUC cells across Canada and the US, and frame discipline is what separates a clean handover from one that comes back six months later. If your cell has drifted out of calibration, that is a contact us conversation.