Troubleshooting Communication Loss Between a Robot and a PLC

Read the exact fault on both ends

Record the precise alarm text on the teach pendant and the matching diagnostic in the PLC software before you touch anything. A robot-side I/O or network alarm plus a PLC-side connection-timeout tells you which side dropped first. Note the timestamp so you can line the two events up.

Caution: Do not clear the alarm and rerun to see if it returns. Find the cause first so you do not restart the cell into an unknown I/O state.

Identify which transport the cell uses

In the robot controller, physical devices are addressed by rack and slot, and the rack number names the transport. Rack 89 is EtherNet/IP, 99 and 100 are PROFINET I/O controller and device, 81 to 84 are DeviceNet boards, 92 is CC-Link, and rack 32 is the I/O Link slave interface used when a CNC is the master. Knowing the rack narrows every later check to the right board and manual.

Inspect the physical layer at both ends

Check the network cable, connectors, and any switch port for damage, a loose latch, or a disconnected lead at both the robot and the PLC. For copper runs, a cable tester or multimeter confirms continuity and rules out a broken conductor inside the dress pack. Reseat the board connector on the controller side if the link light is dark.

Confirm the I/O device is recognized

Press MENU, select 5 I/O, then use F1 TYPE to reach the I/O Link list so you can see whether the connected board and its slaves are detected. A device that no longer appears points to hardware, power, or cabling on that board rather than a configuration mismatch. Note the slot numbering, which starts at 1 for the first connected device and counts up.

Check the I/O assignment status

From MENU, 5 I/O, F1 TYPE, Digital, press F2 CONFIG to see the RANGE, RACK, SLOT, START, and STAT columns. STAT should read ACTIV for the lines that carry PLC data. PEND means the assignment is valid but needs a power cycle, INVAL means a value is wrong, and UNASG means nothing is mapped.

Caution: If you edit RACK, SLOT, or START, the change only takes effect after a controlled power cycle, and the first power-up after a reassign skips power recovery.

Verify master or slave mode matches the architecture

On an R-30iB Mate the controller runs as an I/O Link master or slave, and the mode must match how the cell is wired. System variable $IOMASTER set to 0 is slave mode (the CNC or PLC is master) and 1 is master mode. A mode that flipped during a restore or software change will break the link even though the cable is fine.

Verify the network settings for an Ethernet bus

For EtherNet/IP or PROFINET, press MENU, SETUP, F1 TYPE, Host Comm, select TCP/IP and press F3 DETAIL. Confirm Robot name, PORT#1 IP addr, Subnet Mask, and Router IP addr still match the cell drawing (for example 192.168.0.4 with mask 255.255.0.0). A subnet or router value that drifted will let the port come up yet never reach the PLC.

PING the PLC from the controller

From the same Host Comm TCP/IP screen, use the PING function to test reachability to the PLC address. A reply confirms the physical path, switch, and IP layer are sound and shifts suspicion to the fieldbus mapping or the PLC connection object. No reply keeps the fault in cabling, switch, or addressing.

Test the segment with a known-good device

Connect a laptop to the same segment and confirm it can reach the PLC and the switch. This separates a controller-side board fault from a wider network problem such as a failed switch port or a broken uplink. Keep the laptop on a spare port so you do not disturb the running addresses.

Check for a duplicate address or node

Look for a duplicate IP address on an Ethernet bus or a duplicate DeviceNet MAC ID or station number, often introduced when a device was recently added. Two nodes at the same address can knock the robot off intermittently as they contend. Cross-check every live address against the topology diagram.

Confirm the remote and ready conditions

Even with the link healthy, the PLC cannot start the robot unless it is in the remote state. The remote conditions are the teach pendant enable switch off, SI[2] REMOTE on, UI[3] SFSPD on, UI[8] ENBL on, and $RMT_MASTER set to 0 for peripheral equipment. Correct the cause of any signal that is off rather than working around it.

Caution: *SFSPD, *IMSTP, and ENBL are protective inputs. Never jumper, strap, or defeat them to force a start; route any suspected wiring fault on these lines to a qualified technician.

Watch the live signal exchange

Open the UI and UO peripheral screens and the DI and DO monitor to watch signals toggle as the PLC drives them. Confirm the SIM column shows U for the signals you are checking, because an S means that point is simulated and ignores the real PLC value. A signal that never changes state under PLC command isolates the fault to that mapping.

Restore the connection and verify real data exchange

After you correct the cause and cycle power if a reassign required it, confirm the specific handshake tags update in both directions, not just that the link light is green. Watch UO[1] CMDENBL, UO[2] SYSRDY, and the application handshake bits follow the PLC. A link that is up while the data is stale still leaves the cell unable to run.

Save the working configuration and document the cause

Once data flows, save the I/O and network settings to external storage so the known-good state can be reloaded. Record the root cause, the exact value you changed, and the fix in the maintenance log. This turns the next occurrence into a five-minute check.

What can go wrong: link is up but CMDENBL will not turn on

If the network is healthy yet the robot will not accept a start, CMDENBL is being held off by a missing condition. Check that SO[0 REMOTE] is on, SO[7 TPENBL] is off, SI[2 REMOTE] is on, the mode switch is AUTO with SI[8] and SI[9] on, UI[3 SFSPD] and UI[8 ENBL] are on, $RMT_MASTER is 0, and UO[2 SYSRDY] is on with no FAULT. Work down that list on the signal screens until the offending item shows.

What can go wrong: assignment shows PEND or INVAL

A line stuck at PEND on the I/O CONFIG screen carries no data until the controller is power-cycled, so the PLC sees dead I/O after an edit. INVAL means a RACK, SLOT, or START value is out of range for the installed board, often a typo or a value copied from a different cell. Correct the value, confirm STAT reads PEND cleanly, then cycle power to reach ACTIV.

What can go wrong: it ran before, then a new device dropped it

When a cell that worked for months fails right after equipment was added, suspect an address collision or a node number reused on the bus. A second device answering to the same IP, MAC ID, or station number pulls the robot offline sporadically. Remove or readdress the new device and confirm the robot link steadies before restoring the addition.

What can go wrong: signals read stale or inverted

If a point never follows the PLC, check the SIM column for an S, which means the signal is simulated on the robot and frozen from the network. If a point tracks the PLC but reads backward, check the Polarity setting on the digital I/O detail screen, since NORMAL versus inverted decides the sense. Clear the simulation or fix the polarity, then confirm on the live monitor.

Caution: Before clearing a simulation on an interlock signal, confirm the true field state so the cell does not act on a value you did not expect.