FANUC INTP-105 Run Request Failed: Cause Codes and Fixes
What INTP-105 Means
On FANUC R-30iA, R-30iB, and R-30iB Plus controllers, INTP-105 displays as “Run request failed.” The OEM cause text is “Program cannot be started.” This is an umbrella alarm: the controller has rejected an attempt to run, resume, or remote-start a TP program, but INTP-105 alone does not say why. The refusal can come from the teach pendant, a PNS/RSR/PROD_START remote request, or an attempt to resume a program that was temporarily stopped. When INTP-105 posts, the controller leaves the requested program in its prior state — not running, not advanced — and the motion group stays wherever it was when the request was rejected. The controller does not fault a servo axis or trip a safety input by itself; if one of those conditions exists, it shows as its own alarm alongside INTP-105. Always read the accompanying cause code and any companion alarm before taking further action.
Common Causes Of A Failed Run Request
The most common cause is that the selected TP program is already running, held, or locked by another task — a second run request on a program that is mid-execution will be rejected until the first execution is aborted. Remote-start attempts fail when the controller is not configured for the requested method (PNS, RSR, or PROD_START) or when the PNS program-number pattern and strobe timing do not match what the PLC sent. UOP/SOP start inputs can be disabled entirely if the system-speed signal *SFSPD is off, which is common during a safety-speed or override condition. A teach-pendant or LOCAL operating state blocks any external run request regardless of PLC signals. Finally, the requested program may not exist, may be disabled or write-protected, or may not match the motion group being started.
- Active servo alarms — point to a drive, amplifier, motor, or pulsecoder fault that blocks motion and any program start.
- Active safety alarms — indicate an open safety-chain input, e-stop, or guard condition holding *SFSPD off.
- Active system alarms — indicate a controller-level fault (software, memory, or configuration) preventing execution.
- Active application alarms — indicate a process-specific fault (weld, dispense, vision, etc.) that the application logic requires cleared before a program can run.
Troubleshooting Steps In Order
- Record the exact INTP-105 text, task/program identifiers, and cause-code value before doing anything else.
- Open MENU > Alarm Log and find the companion alarm posted with INTP-105; that alarm usually names the real fault.
- Check the teach pendant mode; a remote or PLC run request will not execute while the pendant is in LOCAL or TEACH.
- Confirm the target program is not already running, paused, or held by another task; abort or reset it before retrying.
- For remote starts, verify the controller is set for the intended method — PNS, RSR, or PROD_START — and that PLC wiring matches the UOP assignment.
- For PNS, confirm the program-number pattern is stable before the strobe is pulsed; check PLC timing if the pattern is correct but the start still fails.
- Check MENU > TEST CYCLE; if the controller is in STEP mode, switch to CONTINUOUS and abort the prior execution before resending the PNS request.
- Confirm the requested program exists, is enabled, is not write-protected, and matches the motion group being started.
- If a servo, safety, or power alarm is active, follow lockout/tagout before opening any cabinet, and resolve that alarm first.
Clearing And Resetting INTP-105 Correctly
Clear INTP-105 by resolving the condition named in the cause code or companion alarm first — INTP-105 itself will not reset while the underlying alarm is still active. Once the cause is corrected, reset the alarm from the teach pendant or remote reset input per your normal procedure, then reissue the run request. After reset, confirm the operating mode (LOCAL/REMOTE) matches what the request source expects, and confirm UOP signals such as *SFSPD are in the state the controller requires for a start. After recovery, run a known-good TP program through a full cycle in the mode that failed before returning the cell to production.
When The Cause Is Hardware
INTP-105 does not by itself identify a failed pulsecoder, cable, amplifier, motor, or board — the OEM text only says the program could not be started. Hardware becomes relevant when it generates the companion alarm that is blocking the request: a servo alarm pointing to a pulsecoder fault, a broken or intermittent motor cable, a failed amplifier, or a main or axis control board issue will each show as its own alarm entry, not as part of INTP-105. Signs pointing to hardware rather than a mode or configuration issue include a servo alarm that returns immediately after reset, an axis that will not hold position or trips on motion, intermittent faults tied to cable flexing or connector movement, or a board that fails power-on diagnostics. Confirm the companion alarm and cause code first; do not replace a pulsecoder, cable, amplifier, motor, or board based on INTP-105 alone. Start component-level repair with fault-log review, visual inspection, power-rail checks, and connector inspection.
How Robotics Integration Helps
Robotics Integration works INTP-105 cases on FANUC R-30iA, R-30iB, and R-30iB Plus controllers by phone and remote session, walking your technician through the alarm log, cause-code readout, UOP and PNS checks, and operating-mode verification before any component is pulled. If the companion alarm points to a servo drive, amplifier, motor, pulsecoder, or control board, we repair that component at the board and drive level rather than defaulting to a full assembly swap, and we test the repaired unit before it goes back into your cell. When remote diagnosis is not enough, we send a technician on-site to check wiring, PLC timing, safety-chain status, and controller configuration against the documented behavior for your specific controller family. The focus on every call is finding the actual cause code or hardware fault behind INTP-105, not just resetting the alarm.
Looking up a different code? See the full FANUC and robot alarm code list, or read about our FANUC robot repair.
What To Send Before You Call
Before you call, pull the exact INTP-105 display text, the cause-code value, and any companion alarm from the Alarm Log, along with the controller model (R-30iA, R-30iB, or R-30iB Plus) and software version. Note which axis or motion group was involved, what the robot was doing when the run request was sent — teach-pendant start, PNS, RSR, or PROD_START — and whether the failure is repeatable or intermittent. Include recent alarm history, since INTP-105 is often secondary to a servo, safety, or system alarm that occurred just before or after it. Call Robotics Integration at 1-602-449-1556 with that information ready and we will work through the cause code, active alarms, and mode/UOP configuration with you to get the program running again.
Talk A Robotics Integrator
By submitting this form, you agree to receive communications via phone, text message, and email. Message and data rates may apply. Your information may be shared with trusted third-party service providers solely for the purpose of helping you explore Section Robotic Intergration options. You also agree to our Privacy Policy and Terms of Service.
+1 602-449-1556
Success Stories: See What Business Have To Say About Robotics Integration
4.7 Customer Reviews
