FANUC PRIO-620 PNIO(C) Station Deactivated: Diagnosing a Dropped PROFINET Slave Without Tearing the Cabinet Apart

The line PLC stops sending the gripper-open command, the robot sits at its home position, and the only thing in the alarm log is PRIO-620 PNIO(C) station 202 deactivated. The fieldbus light on the cabinet is steady green. Everything looks fine until you realize that one slave node went dark and the PNIO controller stopped polling it. We see this on R-30iB and R-30iB Plus cabinets every time a customer adds a new IO block to an existing PROFINET segment without cleanly redoing the network configuration.

This post is written for technicians integrating FANUC robots with PROFINET IO. The error applies wherever the robot is the PNIO Controller (the master), which is the default configuration for cells that bring their own remote IO.

What this error actually means

PRIO-620 is raised by the PROFINET stack inside the FANUC controller when a slave device that was previously communicating goes silent. Per the FANUC error code manual: “PRIO-620 PNIO(C) station %d deactivated. Cause: The device whose Show error when deactivated setting is ON is deactivated. Remedy: Check the station specified the station number, and activate it.”

The %d is the station number FANUC is trying to reach. On the shop floor, that translates to: the controller pinged station 202 (or whatever number the alarm shows), got no response within the watchdog time, and posted PRIO-620. The bus itself is still up; one slave dropped. The “Show error when deactivated” flag is what made this visible. On a stripped-down configuration, the slave would simply go silent without raising an alarm.

PRIO-620 belongs to a family that includes PRIO-621 (I/O Device is not running), PRIO-622 (I/O Controller is not running) and PRIO-623 (I/O Controller not in OPERATION mode). They look similar in the log but represent different layers of the stack. PRIO-620 is the most common because it represents a single slave dropping, which is what happens when a cable gets pulled or a remote block loses power.

Most common causes, in order of probability

1. Loss of power to the remote IO block. The slave is offline, not unreachable. Check the 24V power LED on the IO block before anything else.
2. Patch cable damage between slaves. PROFINET runs in a daisy chain. A bad cable between slave N and slave N+1 takes out N+1 and everything after it, and you get PRIO-620 with the station number of the first device that went dark.
3. Slave IP address mismatch after a swap. An IO block was replaced, but nobody assigned it the same IP address and device name. The new block boots into DCP and never associates with the FANUC PNIO controller.
4. Watchdog timeout on a busy bus. Rare, but possible. A heavily loaded segment with a marginal cable can time out intermittently, and the log shows the same station deactivating and reactivating.
5. Configuration drift. Someone added or removed a slave in TIA Portal or in the FANUC configuration, and the runtime configuration on the controller no longer matches what is on the bus (reference thread on capturing PRIO-620).

How to diagnose in under 10 minutes

Step 1. Read the station number in the alarm text: PRIO-620 PNIO(C) station 202 deactivated. That number is the device FANUC is looking for. Match it against your IO map.

Step 2. Walk to the slave. Look at the power LED, the BF (bus fault) LED and the SF (system fault) LED. A device that is fully off shows no LEDs. A device that has power but no bus communication shows a steady SF and a flickering BF.

Step 3. Check the upstream cable. PROFINET wiring is daisy-chained, so the cable feeding the deactivated slave is the segment between the previous device and this one. Damaged RJ45 strain reliefs are the single most common physical fault.

Step 4. Open MENU > I/O > PROFINET on the FANUC teach pendant. The slaves should be listed with their station numbers and a live/dead indicator. Confirm which ones are showing red.

Step 5. If you need to capture PRIO-620 in a TP program for PLC handshake logic, the err_num to monitor depends on the controller version. A robot-forum discussion on exactly that question documents which Condition Monitor syntax to use (err_num for PRIO-620). A separate thread covers the same alarm specifically for “PNIO station 202 deactivated” cases (how to capture error PRIO-620 PNIO station 202 deactivated).

How to fix it

For a slave that lost power:

Restore power and wait for the device to boot. The alarm should clear automatically once the PNIO controller re-establishes the cyclic connection. If it has not cleared after 30 seconds, press RESET on the teach pendant.

For a bad cable:

Replace it. Crimping a new RJ45 connector in the field is fine for a test, but the permanent fix is a strain-relieved patch cord rated for PROFINET. If the cable runs in a cable carrier, use flex-rated industrial PROFINET cable (typically with M12 D-coded connectors). Office-grade CAT5e patch cables are not acceptable.

For a swapped slave with the wrong IP address or device name:

Use PRONETA or a TIA Portal accessible-devices scan to find the slave, then assign the device name and IP address that the FANUC configuration expects. The FANUC controller will not accept a slave with a different name even if the IP address is correct: the device name is the PROFINET identity.

For configuration drift:

Export the current runtime configuration from the FANUC teach pendant, compare it line by line against the configuration projected in the engineering tool, and reconcile the two. If the projected configuration is correct and the runtime is wrong, reload it from the engineering tool. If the runtime is correct and the projected configuration is wrong, fix the engineering tool first so that the next download does not break the live cell.

If you need PRIO-620 to set a PLC alarm flag rather than just sit in the FANUC log, configure a Condition Monitor or a BG Logic program that watches the error number and drives a UO output. The forum threads above show the exact syntax. Wire that UO to the PLC and you can route the alarm to the line HMI.

When to call a specialist

Two scenarios are worth a call:

PRIO-620 comes back every few hours with the same station number, but the slave is physically fine and the cable tests clean. That is usually a marginal cable termination or a PNIO controller stack issue that needs a firmware-level look. We have seen this on R-30iB cabinets with old PROFINET firmware revisions, where an update to a Plus revision cleared it.

You are building a new cell and want the PLC to take action when the FANUC controller drops a slave (refusing to send the next cycle start, switching to a degraded mode, etc.). Wiring that handshake correctly involves the err_num technique above plus a documented sequence in the PLC, and it is worth getting right the first time.

Contact us for PROFINET integration, or schedule a preventive maintenance visit so that bus health is checked alongside the mechanical maintenance.

Related errors to check

• PRIO-621 PNIO(D) device is not running: the robot configured as a slave (I/O Device) failed to start. Different role, different fix. Manual remedy: disable the I/O Device if it is not used, or check the I/O Controller (the PLC).
• PRIO-622 PNIO(C) controller is not running: the PNIO Controller itself never came up. This means the FANUC side of the stack failed at boot; it is not a slave issue.
• PRIO-623 PNIO(C) not in OPERATION mode: the controller started but is not in OPERATION mode. Change the startup mode under MENU > I/O > PROFINET > Setup and reboot.
• PRIO-624 PNIO(C) module number mismatch: the configured slot count does not match the physical IO block. Usually appears after a 4-channel block is swapped for an 8-channel block without updating the configuration.

Probot Systems is a FANUC integrator based in Lévis, Quebec, serving Canada and the US. PROFINET integration with Siemens, Allen-Bradley or any other controller talking to a FANUC robot is part of every cell we commission. If your alarm log is full of PRIO-620 entries with no clear root cause, let’s talk: contact us.