FANUC TP Program Structure: When to Use CALL, When to Use JMP LBL, and When to Move to BG Logic

You inherited a TP program that started life as 80 lines and is now 600. The robot does its job, but adding a single new gripper sequence breaks behaviour in three other places and the alarm log fills with INTP-105 and PROG-040. The fix is not “more JMP LBL”, it is a different choice of control structure. At Probot Systems we refactor TP programs like this on commissioning all the time, and the same three rules apply on R-30iB, R-30iB Plus, CRX, and LR Mate cells.

This post is written for technicians and integrators writing or maintaining TP programs that have outgrown a single linear script. If you are debugging an alarm tied to motion ownership specifically, the PROG-040 post covers that mechanism in detail.

What this error actually means

There is no single FANUC alarm code for “your TP program is structured badly”. What you get instead is downstream symptoms: INTP-105 when a run request fails, PROG-040 when two tasks fight for motion control, and runtime behaviour that does not match the program as written because a JMP LBL jumped out of an IF block and skipped the cleanup code.

Per the FANUC error code manual on INTP-105: “Run request failed. Cause: Program cannot be started. Remedy: Refer to the error cause code. Use MENU to display the Alarm Log screen.” That is the controller telling you the run request was denied for a reason you have to read the next alarm to discover. On PROG-040 the manual is more explicit: “Motion control for the specified group was already reserved by another program. Remedy: Check the other running programs to determine who has motion control.”

The shop floor translation: TP has perfectly good control structures (CALL, IF/ELSE, SELECT, FOR/ENDFOR on newer versions, plus Background Logic and Condition Monitor). When code is forced through JMP LBL because nobody decomposed it into subprograms, you end up with bugs the language was designed to prevent.

Most common causes, in order of probability

1. JMP LBL crossing a structured block. Jumping out of an IF block into a label past the ENDIF leaves the stack in a state TP did not expect. Newer firmware tolerates it, older revs do not, and either way the program is hard to read.
2. CALL without a clean RETURN path. A subprogram that “ends” by falling through into another program or hitting the END of the file instead of returning. The TP editor does not warn you (reference Reddit thread on TP code structure).
3. Implementing parallelism with overlapping CALLs. Trying to run motion and IO logic “at the same time” by calling them from different programs. You get PROG-040 the second one of them needs the motion group.
4. One huge sequential script. 600 lines of motion with the gripper, vision triggers, and conveyor handshake all inlined. Every change risks every other behaviour (Robot Crash thread on subprogram decomposition).
5. Macros calling long motion sequences. Macros are designed for HMI panel buttons (one-shot, fast). When a macro launches a 60-second motion sequence, you get UI-thread weirdness and unexpected pauses.

How to diagnose in under 10 minutes

Step 1. Print or screenshot the call tree. Open MAIN, list every CALL and every JMP LBL target. If you cannot fit it on a single page, the program needs to be split.

Step 2. Look at INTP-105 in the alarm log and read the cause code that follows. If the cause is PROG-040, you have a motion ownership problem (see that post). If the cause is something else, it tells you exactly which line failed.

Step 3. Check the group mask on every program. MENU > SELECT > DETAIL. Programs that only touch IO should have group mask *,*,*,*,* (no motion). Programs that drive motion should have their motion group set explicitly.

Step 4. Look for JMP LBL inside IF/ENDIF, SELECT/ENDSELECT, or FOR/ENDFOR blocks. Those are the bug-friendly cases. The intended exit is an explicit ELSE or break, not a jump out.

Step 5. Confirm BG Logic configuration if anything is supposed to run in parallel. MENU > SETUP > BG Logic. The task list there is what the controller will execute alongside the main program (Reddit on BG Logic for parallel behaviour).

How to fix it

For a JMP LBL jumping out of a block:

Replace with structured TP. The patterns that work:

• One-of-many decision: SELECT/ENDSELECT with explicit cases.
• Two-way branch: IF cond THEN / ELSE / ENDIF.
• Early exit from a CALLed subprogram: explicit END instruction at the exit point.

JMP LBL is fine inside a single short sequential section. It is not fine for control flow across the whole program.

For a CALL without RETURN:

Every called subprogram should end with END (which returns to the caller). Falling off the bottom of the file does the same on modern firmware, but explicit is better than implicit. Older firmware has been known to skip the next intended caller and run something unrelated when the END is missing.

For parallelism (motion plus IO):

Move the IO into Background Logic. BG Logic runs independently of the motion thread and does not need motion control. It is the correct tool for conveyor monitoring, alarm flag setting, panel button watching, and PLC handshake bookkeeping. A robot-forum thread on the same pattern documents exactly the case where someone tried BG Logic and discovered which instructions are not allowed there (reference).

For one huge script:

Refactor in passes. Pick a logical chunk (gripper open/close, pick from station A, place at station B). Move it into a named subprogram with a short clear name (TP names are limited to 36 characters, design for it). Replace the inline code with a CALL. Test one chunk at a time. Repeat. After three to five passes, the main program reads as a sequence of named operations and the bugs in the middle disappear.

For macros driving motion sequences:

Macros should fire a CALL to a TP program and return immediately. They should not contain the motion themselves. That keeps the macro fast (it is on the UI thread) and the motion lives where it belongs (a regular TP program with motion ownership).

For a CRX with the tablet block-programming view:

The block-style interface compiles down to TP under the hood. The same structure rules apply. You can drop into the legacy pendant view via Settings to read and edit the underlying TP if a block needs surgery the tablet view does not expose (CRX tablet pendant Reddit thread).

When to call a specialist

Two situations are worth a service call:

You have a TP program that has grown beyond what one person can hold in their head, and changes to it keep causing regressions. A programming audit with a documented call tree and a refactored main is a one-day engagement that pays back over the life of the cell.

You need to add genuinely parallel behaviour (vision triggers during motion, conveyor tracking with concurrent gripper control), and you are not sure whether BG Logic, Condition Monitor, or a KAREL helper is the right tool. The choice matters for performance and safety, and getting it right the first time avoids the PROG-040 / INTP-105 chain.

contact us for a programming review, or set up a maintenance preventive contract so the TP architecture is checked alongside the mechanical maintenance.

Related errors to check

• PROG-040 Already locked by other task: two motion programs fighting for the same group. The most common downstream of bad parallel design.
• INTP-105 Run request failed: outer alarm. Always read with the cause code in the next line.
• SRVO-050 Collision Detect: not directly caused by program structure, but a poorly decomposed program that re-teaches points without re-checking payload can trigger it. The Reddit “Srvo-050” thread documents exactly this scenario (reference).
• SYST-212 Need to apply to DCS param: appears after mastering or backup changes. Not structural, but often part of a broader refactoring effort.
• INTP-254 Parameter not found: indicates a parameter referenced in the TP code does not exist. Often a copy-paste leftover from refactoring.

Probot Systems is a FANUC integrator based in Lévis, Quebec serving Canada and the US. TP refactoring, BG Logic design, and KAREL integration are part of every cell we deliver. If your inherited TP program is fighting back every time you touch it, that is a contact us conversation worth having.