Resolving MotoPlus Alarms 1020, 1050, 4207 on Yaskawa Robots

When a motoPlus application fails to start on a Yaskawa Motoman robot controller (DX100, DX200, FS100, YRC1000, YRC1000micro), the controller typically reports one of three alarm groups: 1020 (application load error), 1050-[1] (HMI/teach pendant communication loss), or 4207-[1101] (unresolved application symbol). This reference covers the most common boot-time failure mode reported in the field: a motoPlus application that compiles cleanly, produces a valid .OUT file, but stops at the boot screen with the teach pendant marked as disconnected. Three independent root causes are usually stacked in the same project: a function pointer cast to an undefined or wrongly-named function, a while(1) loop without mpTaskDelay, and a leftover .OUT file from a previous build. This article details each alarm, isolates the underlying defect, and provides a verified fix sequence.

Problem Summary

The defect reproduces deterministically when the developer creates three tasks in mpUsrRoot() with mpCreateTask(...), then enters a tight receive loop of the form:

void mpOnRecvData() {
    while (1) {
        RecvCount = mpRecv(SockHandle, RecvBuf, 100, 0);
    }
}

On first download the controller reports 1050-[1] and 4207-[1101] and stops at the boot screen. The teach pendant shows loss-of-communication with the Dx-class CPU. If the developer comments the mpRecv call but leaves the while(1) empty, the controller still fails. Only when the offending task is removed entirely does the application run. Inserting a single mpTaskDelay(1) inside the loop is sufficient to recover full operation. A separate but related fault, alarm 1020-[1], appears when more than one .OUT file is present on the controller at boot time. DX100 systems additionally exhibit sub-code 1020-[5] when the MotoPlus License Manager (MPLM) is not loaded before any other application.

Affected Controllers, Firmware, and Toolchain

All Yaskawa Motoman controllers that ship the motoPlus runtime are susceptible. The set in current field deployment includes:

Where the documentation you have on hand references a specific firmware/SDK build number (for example "MotoPlus32 Ver. 3.20-00" or "YAS2.81"), use that as the local pin against which you validate register and prototype signatures; the alarm codes documented below are stable across the listed runtime versions. The Yaskawa Motoman knowledge base entries that confirm the 1020 sub-codes are YRC1000MICRO ALARM CODE 1020 MOTOPLUS (APPLICATION LOAD ERROR) and DX100 ALARM CODE 1020 [5] MOTOPLUS APPLICATION LOAD ERROR.

Root Cause #1: Function Pointer Mismatch in mpCreateTask

The mpCreateTask prototype declared in motoPlus.h requires a function pointer of type FUNCPTR that takes ten int arguments. The cast in C is unchecked at compile time when the function is declared with the extern storage class but never actually defined. The compiler accepts the build, the linker resolves the symbol from another translation unit or, more commonly, emits a 0x00000000 entry in the task descriptor. At boot the motoPlus kernel dereferences that entry and the controller reports:

4207-[1101]  // APPLICATION SYMBOL NOT FOUND (MotoPlus task entry point)

The defect typically appears in projects that grew by copy/paste. A representative broken declaration is:

// header.h
extern void mpRecvData(int a1, int a2, int a3, int a4, int a5,
                       int a6, int a7, int a8, int a9, int a10);

// main.c
Task_id3 = mpCreateTask(MP_PRI_TIME_NORMAL, MP_STACK_SIZE,
                        (FUNCPTR)mpRecvData,    // BUG: function does not exist
                        arg1, arg2, arg3, arg4, arg5,
                        arg6, arg7, arg8, arg9, arg10);

The real function name in the source is mpOnRecvData, not mpRecvData. The C cast hides the prototype mismatch because FUNCPTR is a void (*)(void) typedef on most motoPlus SDKs. There is no warning, no link error, and no runtime error at task creation; the failure is deferred to the first dispatch.

The fix is to ensure the function passed to mpCreateTask exists with the documented prototype, or to wrap the user function in a thin shim. The recommended shape is:

// Always declare the entry point exactly as motoPlus requires
static void taskRecvEntry(int a1, int a2, int a3, int a4, int a5,
                          int a6, int a7, int a8, int a9, int a10)
{
    (void)a1; (void)a2; (void)a3; (void)a4; (void)a5;
    (void)a6; (void)a7; (void)a8; (void)a9; (void)a10;
    mpOnRecvData();
}

Task_id3 = mpCreateTask(MP_PRI_TIME_NORMAL, MP_STACK_SIZE,
                        (FUNCPTR)taskRecvEntry,
                        arg1, arg2, arg3, arg4, arg5,
                        arg6, arg7, arg8, arg9, arg10);

Because the wrapper is defined in the same translation unit that calls mpCreateTask, the compiler can validate the prototype and the linker can resolve the symbol deterministically. The shim is also the cleanest place to pass user context via static state if the arg1..arg10 parameters are not sufficient.

Root Cause #2: Cooperative Scheduling and the Missing mpTaskDelay

Yaskawa Motoman motoPlus uses a non-preemptive, priority-ordered cooperative scheduler. Each task runs to completion of its current iteration, then yields. A task that contains a tight while(1) loop without any blocking primitive starves the scheduler, including the kernel-internal task that services the HMI/watchdog channel. Within a few hundred milliseconds of power-on the controller detects the missing heartbeat and trips:

1050-[1]  // HMI (teach pendant) communication error; the controller cannot
          // exchange I/O with the Dx-class CPU within the watchdog window.

Because alarm 1050 is also the alarm generated when the teach pendant is physically disconnected, faulted, or replaced, the symptom is initially misread as a pendant hardware issue. The motoPlus task starvation produces the same alarm code with the same sub-code. The fact that the same alarm appears after commenting the mpRecv call (but leaving the while(1)) confirms the scheduler-starvation theory: even an empty while(1) without any blocking call starves the kernel in tens of milliseconds.

The motoPlus kernel provides two cooperative blocking primitives. mpTaskDelay(int ticks) blocks the calling task for the specified number of system clock ticks, and mpTaskDelay(SYS_CLK_RATE / 50) produces a 50 ms period (one tick per millisecond on most motoPlus configurations; verify SYS_CLK_RATE in your local SDK header). mpSemTake(...) with timeout is the second option and is preferable when the receive should wake on data availability, not on a fixed period.

// Correct: cooperative receive loop
void mpOnRecvData(void)
{
    while (1) {
        RecvCount = mpRecv(SockHandle, RecvBuf, RECV_LEN, 0);
        if (RecvCount < 0) {
            mpTaskDelay(10);  // back off on socket error
        } else {
            mpTaskDelay(1);   // yield, ~1 tick
        }
    }
}

The single mpTaskDelay(1) call inside the loop is what restored operation in the field case. With the delay in place the controller boots cleanly, the teach pendant remains connected, and the receive task services incoming data at full Ethernet rate without impacting the kernel heartbeat.

Root Cause #3: Multiple .OUT Files and Load Order (Alarm 1020)

Alarm 1020 is the motoPlus application load error. It is generated at boot by the motoPlus loader when it cannot decide which .OUT file to start, when a required .OUT is missing, or when the load order of co-resident applications is wrong. The sub-codes encountered in practice are:

Sub-code 1020-[1] is by far the most common. Each MPLID build produces a .OUT that is dropped into the motoPlus application slot via FTP or the maintenance menu. If an old build is not deleted, two .OUT files coexist and the loader refuses to pick a winner. Maintenance mode is the only state from which files in the motoPlus application directory can be deleted while the controller is in a faulted state. Navigate to Main Menu → Maintenance → MotoPlus Application, list files, and delete everything except the one binary you intend to run. The Yaskawa Motoman knowledge base documents this procedure for YRC1000micro in YRC1000MICRO ALARM CODE 1020 MOTOPLUS (APPLICATION LOAD ERROR).

Sub-code 1020-[5] is specific to DX100. The MotoPlus License Manager (MPLM) is a small .OUT that arbitrates concurrent access to motoPlus features; it must be present and must be loaded before any other .OUT. If the application slot contains the user .OUT but not MPLM, or if MPLM is in a higher slot number, the loader raises 1020-[5] and aborts startup. The fix is to copy MPLM into the controller first, reboot, confirm the alarm clears, then load the user .OUT. The Yaskawa Motoman knowledge base documents this in DX100 ALARM CODE 1020 [5] MOTOPLUS APPLICATION LOAD ERROR.

Alarm Code Reference

The following table consolidates the alarm codes that surface during a motoPlus boot failure. Use the alarm history viewer (F2 → Alarm History on most DX/YRC teach pendants) to capture the exact sub-code before clearing.

The 1050 and 4207 codes are typically reported together when the underlying cause is a function pointer mismatch: 4207 fires when the loader resolves the task entry, and 1050 fires as a secondary effect when the resulting dispatch loop starves the kernel. Resolving the function name removes both alarms in one step.

Step-by-Step Diagnosis Procedure

1. Place the controller in Maintenance mode: from the teach pendant, select Main Menu → System → Security → Management and enter the maintenance password, then cycle power.
2. Open Main Menu → Maintenance → MotoPlus Application. List the .OUT files present. More than one file in the slot is a 1020-[1] condition.
3. Capture the alarm history (F2 → Alarm History) and write down the full sub-code for each entry. Do not clear until the cause is identified.
4. Open the MPLID project. For each call to mpCreateTask, confirm the third argument resolves to a defined function in the same project. Use the IDE's "Go to definition" on the symbol to verify.
5. Grep the source for while\s*\(1\) and audit every occurrence. Each must contain a blocking motoPlus API or mpTaskDelay.
6. Confirm the Ethernet socket is created with mpSocket and bound with mpBind before any task attempts to receive. A null SockHandle passed to mpRecv returns immediately with a negative code, which is enough to keep a tight loop alive without starving the kernel — the symptom then shows up later, not at boot.
7. Rebuild the project with full warnings enabled. MPLID's default build suppresses some warnings; enable -Wall -Wextra in the project options to surface prototype mismatches.
8. Transfer the .OUT to the controller and reboot. Observe the boot screen for 60 seconds; if 1050 clears within 5 seconds of pendant handshake, the kernel heartbeat is healthy.

Step-by-Step Resolution Procedure

1. Fix the function pointer. Rename the task entry function in the source so the symbol exists, or wrap it in a static shim that calls the user function. Rebuild.
2. Add a yield in every infinite loop. Insert mpTaskDelay(1) at the bottom of every while(1). For the 50 ms periodic sender, use mpTaskDelay(SYS_CLK_RATE / 50) or compute the tick count from your SDK's SYS_CLK_RATE macro.
3. Resolve duplicate .OUT files. In maintenance mode, delete every .OUT file in the motoPlus application slot except the intended one. Confirm the file count is exactly 1 (or 2 if MPLM is required on DX100).
4. Verify the load order on DX100. If MPLM is required, confirm it is the first .OUT in the slot, then reboot, then load the user application.
5. Re-build with warnings as errors. Set Project Properties → C/C++ Build → Settings → Warnings → -Werror to make prototype mismatches fail the build.
6. Transfer the new .OUT via FTP (anonymous, port 21) into the motoPlus application directory, or via the maintenance menu's MotoPlus Application → Install entry.
7. Cycle power on the controller. The motoPlus loader runs early in the boot sequence; a soft reset does not re-run the loader on most controller classes.
8. Verify boot: the teach pendant should reach the main menu within 30 seconds with no 1050 alarm. The alarm history should be empty after a controlled reset.
9. Verify the application: trigger a 50 ms send burst from the peer, confirm data on the wire, and confirm the receive callback fires. A motoCom trace (motoCom32 on 32-bit controllers, motoCom64 on YRC1000) or a packet capture on the Ethernet segment can validate the period.

Verification and Field Commissioning

After the resolution is applied, run the following verification sequence before handing the cell back to production:

1. Pendant handshake. Confirm the teach pendant reaches the main menu and the controller does not report 1050. The pendant should not flash the comm-loss indicator.
2. Alarm history clean. Reset the alarm history, reboot, and confirm 1020, 1050, and 4207 do not reappear.
3. Task CPU budget. From the maintenance menu, view the motoPlus task load if exposed in your SDK build. A well-behaved Ethernet client should report single-digit percentage CPU. A starved kernel will report 99% on the offending task and starvation on the kernel task.
4. End-to-end data path. Send a known pattern from the peer at 50 ms intervals, confirm arrival at the receive task, and confirm the response is emitted within the deadline. Latency should be bounded and stable.
5. Stress test. Run the application for 24 hours. Watch for latent alarm entries in the history. Starvation defects often manifest as 1050 within 15-30 minutes of a heavy loop.
6. Recovery test. Pull the pendant cable while the application is running. The controller should report 1050 (physical disconnect). Reconnect the cable; the pendant should handshake and the application should resume. If 1050 persists after reconnection, the motoPlus task is starving the kernel even on the "good" path.

MotoPlus Task Design Best Practices

These rules distill the field failures into reusable guidelines. Treat them as pre-merge checks for every motoPlus commit.

• Always yield in while(1). Every infinite loop must contain a blocking API or mpTaskDelay. A bare loop is a kernel-killer.
• Avoid extern declarations for task entry points. Define them in the same translation unit that calls mpCreateTask, or in a header with the full motoPlus prototype. This makes prototype mismatches a compile error.
• Wrap user code in a shim. The shim has the motoPlus prototype and calls into your real function. This decouples motoPlus ABI from your API and prevents the extern foot-gun.
• One task per role. A receiver task, a sender task, and a main task is a clean split. Do not run the receive loop inside the main task; the main task should set up sockets and resources, then idle or exit.
• Bound the receive buffer and length. Hard-code the receive length to a named constant. mpRecv(SockHandle, RecvBuf, 100, 0) with a 100-byte buffer is acceptable; a dynamically computed length is a vector for stack corruption.
• Check return codes from every motoPlus API. mpRecv, mpSend, mpSocket, mpBind, mpConnect, and mpAccept all return negative codes on error. Treat the error path as the hot path: log, back off with mpTaskDelay, and retry.
• Set stack size explicitly. Default MP_STACK_SIZE is small. Recursive parsers, large printf buffers, and STL-style code can overflow the default. Pass a larger literal and confirm the build accepts it.
• Use SYS_CLK_RATE for timing math. Hard-coded millisecond constants in mpTaskDelay assume a tick rate. Use the macro so the same source builds against SDK variants that change the rate.
• Delete old .OUT files after every build transfer. Maintenance mode is fast. A 5-second delete is cheaper than a 30-minute debug of 1020-[1].
• Keep MPLM in the lowest slot on DX100. The loader expects it first. If a developer tool has reordered slots, move MPLM back to slot 0 before rebooting.
• Distinguish motoPlus from motoCom. motoPlus is the on-controller C runtime; motoCom32 / motoCom64 is the off-controller PC-side SDK that talks to the controller over Ethernet. A peer that cannot connect is almost always a motoCom configuration problem, not a motoPlus alarm.
• Confirm controller class at build time. YRC1000/YRC1000micro require the 64-bit motoPlus SDK; DX/DX200/FS100 require the 32-bit SDK. A 32-bit .OUT loaded on a YRC1000 raises a generic 1020 with no sub-code.

Troubleshooting Matrix

FAQ