FANUC MOTN-074 (G:1): Speed Out of Range, iRVision Calibration Failures, and Frame Mismatches

You are running 2D iRVision calibration on an LR Mate 200iD on an Education Cert Cart, the camera moves through the grid, and the program drops with MOTN-074 (G:1). Or you are running a freshly loaded offline program from RoboGuide and the same alarm pops on a linear move that simulated clean. Different cells, different programs, same code. MOTN-074 is the controller telling you a speed value is out of bounds, but the way it surfaces depends entirely on which speed value the program tried to set. At Probot Systems we see this most on iRVision setups and on offline programs being loaded onto a different cell variant than the one they were written for.

This post is written for technicians and integrators chasing MOTN-074 on R-30iB Plus cabinets running 2D iRVision, palletizing programs imported from RoboGuide, or any TP program using SPEED, SPEEDLIM, or ROTSPEED constructs.

What this error actually means

MOTN-074 is the speed-range alarm. The FANUC error code manual on page 873 is precise: “MOTN-074 Error in speed (G:%d^2) Cause: Speed is not within 0 to $speedlim Remedy: Set speed within 0 to $speedlim.” The next two entries on the same page (MOTN-075 for rotspeed and MOTN-076 for contaxisvel) round out the family. Each one points at a different variable, but the rule is the same: the program asked for a speed value the controller will not let it use.

In practical terms, the controller carries a $SPEEDLIM that caps the linear speed any program is allowed to request. iRVision calibration routines and offline-generated programs both sometimes write speed values directly. If those values exceed $SPEEDLIM, MOTN-074 fires before the move starts. Field techs often misread the alarm as a workspace-reach problem (because “G:1” sounds geometric), but the actual cause lives in the speed value, not in geometry. That distinction matters because every fifteen minutes you spend on frames and joint limits is fifteen minutes you have not spent on the line that wrote the bad speed.

Most common causes, in order of probability

In order of how often we land on each one:

1. iRVision camera calibration speed exceeds $SPEEDLIM. The default calibration motion writes speed values that are fine on a freshly commissioned cell, but on a cell where $SPEEDLIM has been tightened (often for collaborative or paint applications), the calibration trips with MOTN-074. The DIY Robotics thread on this exact failure flags it on an Education Cert Cart running 2D iRVision (reference thread). The Robot-Forum thread on the same failure points at the same line (robot-forum thread).
2. Offline program with hardcoded speed greater than $SPEEDLIM. RoboGuide cells often run with permissive $SPEEDLIM values. When the TP file is loaded onto a real cell with a tighter limit, the first speed-set instruction throws MOTN-074. This is the most common offline-to-real surprise we see on commissioning visits.
3. UFRAME or UTOOL mismatch making a linear move appear unreachable. Less directly tied to the speed text, but field operators often see MOTN-074 immediately after a frame mismatch corrupted the path. Worth double-checking when the alarm and a frame change are correlated.
4. Speed register set programmatically out of range. Programs that compute speed at runtime (R[n] = SOMETHING) can write values outside 0 to $SPEEDLIM if the math goes wrong. MOTN-074 fires when the controller next tries to use that value.
5. System variable corruption after a controlled start. Rare but real. A botched controlled start can leave $SPEEDLIM at zero, and any speed at all will trip MOTN-074. Worth checking if the alarm appears across multiple unrelated programs in the same day.

How to diagnose in under 10 minutes

Step 1. Note the group: MOTN-074 (G:1). Then go straight to the program line that fired the alarm. The alarm history will name the line if you check immediately.

Step 2. Read the speed value on that line. If it is a constant (e.g., 250mm/sec), check $SPEEDLIM. If it is a register (R[n]), display the register and check its current value.

Step 3. Open MENU > SYSTEM > Variables, find $SPEEDLIM, and read its current value. Compare against the speed the program is trying to set.

Step 4. On an iRVision calibration: the calibration program itself sets the speed. If $SPEEDLIM is tighter than the iRVision default, the calibration will fail every time. The DIY Robotics thread documents this trap on the Education Cert Cart (forum reference).

Step 5. On an offline-loaded program: confirm the running cell’s $SPEEDLIM matches what the RoboGuide cell was set to. Mismatched $SPEEDLIM between RoboGuide and the real controller is the dominant cause on commissioning visits.

Step 6. If $SPEEDLIM is showing zero or some absurd value: a controlled start went wrong somewhere. Restore from a known-good backup before continuing.

How to fix it

The fix depends on which path you came in on.

If iRVision calibration is failing: open $SPEEDLIM temporarily, run the calibration, then restore $SPEEDLIM to the production value. Or update the iRVision calibration motion to a speed within the cell’s $SPEEDLIM. The Robot-Forum thread on the Education Cert Cart calibration failure lands on the same approach (robot-forum thread).

If an offline program is asking for too much speed: lower the speed in the TP file to within $SPEEDLIM. Do not raise $SPEEDLIM on a production cell without engineering review. The limit exists for safety and for application-specific reasons (collaborative speed limits, paint application speed, conveyor synchronization).

If a programmatic speed register is computing out of range: clamp the value in code with a MIN check before assigning it to a SPEED instruction. R[n] = (R[m] > $SPEEDLIM) ? $SPEEDLIM : R[m] in TP-speak.

If $SPEEDLIM is corrupted: restore from backup. Do not edit $SPEEDLIM by hand without confirming the production value. The DIY Robotics thread on this alarm starts the conversation around speed values for exactly this reason (forum reference).

A note that catches techs out: MOTN-074 is sometimes informally described as a “position not reachable” alarm in forum chatter. The official manual on page 873 is clear that it is a speed-range alarm. If you treat it as a frame or workspace problem, you will burn an afternoon on the wrong diagnostic. Read the program’s speed values first.

When to call a specialist

Call us when $SPEEDLIM looks correct, the program speed values are within range, the iRVision calibration is configured per the FANUC procedure, and MOTN-074 still fires. At that point you are looking at system variable integrity, controller image health, or a deeper iRVision setup issue, all of which are easier to resolve with a backup-and-restore plan in place.

Same applies when you are commissioning a cell with an offline program from a previous integrator and the speed limits do not line up. We do the audit, document the production $SPEEDLIM, and update the offline source so the next regen comes through clean.

contact us for a commissioning or service call, or set up a maintenance preventive contract so $SPEEDLIM and iRVision setups are documented before a new program ships.

Related errors to check

• MOTN-075 Error in rotspeed: same family on rotational speed. Fires on programs setting wrist rotation speed above $ROTSPEEDLIM.
• MOTN-076 Error in contaxisvel: continuous-axis velocity out of range. Same family, different variable.
• MOTN-017 Limit error: actual workspace-limit alarm. If a forum thread suggests MOTN-074 is a position problem, MOTN-017 is the alarm they probably meant.

Probot Systems is a FANUC integrator based in Lévis, Quebec. We commission and maintain palletizers, welders, and vision cells across Canada and the US, and we know which MOTN-074 traps catch first-time iRVision users and which catch experienced techs loading offline programs. If your iRVision calibration keeps tripping MOTN-074, that is a contact us conversation.