FANUC PROG-040 Already Locked by Other Task: Why Two Programs Cannot Own the Same Motion Group

The cycle was running fine. You added a quick subprogram to manage the gripper, hit RUN, and the controller posts INTP-105 followed by PROG-040 Already locked by other task. Nothing moves. The fix is one line of TP code, but only if you understand who currently owns motion control and why the controller will not hand it to two tasks at once. At Probot Systems we see this every time a customer tries to add a parallel program without using Background Logic.

This post is written for technicians and integrators writing TP programs on R-30iB, R-30iB Plus, and R-30iA Mate controllers. The same alarm appears on LR Mate cells with the standard motion configuration. If you have multiple motion groups, the rules tighten further, this post covers the single-group case which is by far the most common.

What this error actually means

Every TP program that wants to move the robot has to reserve the motion control for the motion group it uses. Per the FANUC error code manual: “PROG-040 Already locked by other task. Cause: 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 companion alarm INTP-105 is documented next to it: “Run request failed. Cause: Program cannot be started. Remedy: Refer to the error cause code.” INTP-105 is the outer alarm (the run request was denied), PROG-040 is the cause code (denied because the group was already locked).

In plain terms: two programs cannot move the robot at the same time. If program A is running motion and program B tries to start with motion access, program B is blocked with PROG-040 until A releases the group or finishes. This is the controller protecting you from two pieces of code fighting over the same joints, which is exactly what a single motion CPU should do.

Most common causes, in order of probability

1. Two motion programs called in parallel. The most frequent case. Operator selects MAIN, MAIN calls SUB which has motion instructions, and somewhere SUB is also called from a macro or a UI button. The second call fails with PROG-040 (reference thread on the same INTP-105 / PROG-040 combination).
2. Gripper subprogram still set to motion group. A program that only changes a digital output should be configured with no motion group (group mask *,*,*,*,* or similar). Leave it on group 1 and the controller treats it as a motion task that wants the same group as the main program.
3. TP editor or WinTPE holding the program. A program open for edit in WinTPE keeps a soft lock. Run requests for the same program fail until the edit session ends.
4. Background Logic mis-configured as a motion task. Beginners sometimes try to drive a BG Logic program with motion lines. BG Logic does not own motion control, so when the line tries to run it fails the same way.
5. FCTN > END EDIT not done after teaching. Pendant left mid-edit holds the program. Operator hits RUN from a remote terminal and the controller refuses.

How to diagnose in under 10 minutes

Step 1. Read both alarms in the log. INTP-105 should sit above PROG-040. The order tells you it was a run request that failed, not motion already in progress.

Step 2. Open the running task list under MENU > SELECT > F1 [TYPE] > Status. Look for any program in PAUSED or RUNNING state. The one that holds motion control is the one with a motion group in its header and a non-completed status.

Step 3. Press FCTN > 4 ABORT (ALL) to stop everything cleanly. If PROG-040 disappears after that, you had a lingering paused task holding the group.

Step 4. Check the offending program’s group mask. MENU > SELECT, highlight the program, press DETAIL, look at the Group Mask line. If a gripper-only program shows 1,*,*,*,* instead of *,*,*,*,*, that is your problem (DIY Robotics community thread documenting the gripper-as-no-motion fix).

Step 5. Confirm no WinTPE or ROBOGUIDE backplane session is connected. Open the network status menu, or simply close any PC tool talking to the cabinet.

How to fix it

For the most common case (gripper or IO subprogram defined as a motion task):

1. MENU > SELECT, navigate to the offending program.
2. Press DETAIL.
3. Change Group Mask from 1,*,*,*,* to *,*,*,*,* (no motion group required).
4. Save and re-run.

That makes the program a pure logic task and the controller will let it run in parallel with the motion program without contesting the group.

For two motion programs that genuinely both need to move the robot:

You need to serialize them. Use a single main program that calls each motion subroutine in order, instead of trying to launch them from two run requests. The TP language supports CALL chains exactly for this. If you need parallel behaviour with IO, use Background Logic. If you need parallel motion (impossible on a single motion group), you need a dual-arm configuration or a second robot.

For a stuck WinTPE / ROBOGUIDE lock:

Disconnect the PC tool. If the lock persists, do a Controlled Start (boot with PREV+NEXT held). That wipes in-memory state without losing programs. Cold Start is overkill in this scenario and risks more than it fixes.

For an UNLOCK_GROUP issue in KAREL or advanced TP:

PROG-040 has cousins (PROG-041 through PROG-043) that fire when the group state machine is misused. If a KAREL program calls LOCK_GROUP and then exits without UNLOCK_GROUP, the group stays locked until power cycle. This is rare in straight TP code but common when KAREL is added later. The robot-forum and DIY Robotics threads above cover the right pattern.

When to call a specialist

Two situations are worth a call:

The alarm appears intermittently and you cannot identify which program holds the lock. That usually means a Macro or Background task is calling something at the wrong time, and tracing it requires reading the call tree, the BG Logic config, and the macro table together. We do this routinely as part of a programming audit.

You are commissioning a cell with multiple motion groups (robot plus servo positioner, robot plus rail), and motion is being requested from PLC-driven sequences in ways that produce intermittent PROG-040. Multi-group motion control wants a clear ownership model documented up front, and most cells we visit do not have one.

contact us for a programming review, or set up a maintenance preventive contract so the group masks and BG Logic configuration are checked alongside mechanical maintenance.

Related errors to check

• INTP-105 Run request failed: the outer alarm. Always read it with the cause code that follows.
• PROG-039 Could not get mctl: the request was made but motion control was not available. Same family, slightly different wording.
• PROG-041 mctl denied because released: motion control is held by the teach pendant. Disable the TP enable and retry.
• PROG-042 Already released: trying to release motion control that was never owned. Usually a coding bug.
• PROG-043 Already released by you: the program already released the group earlier and is releasing again. Logic error.

Probot Systems is a FANUC integrator based in Lévis, Quebec serving Canada and the US. Multi-program TP architecture, BG Logic, and KAREL integration are part of every cell we deliver. If PROG-040 keeps showing up in your line and you cannot trace which task is locking the group, that is a contact us conversation.