Resolving FANUC Robot Web Server Access: RIPE vs Port#

Where does the browser request stop?

A browser request to a robot controller can die in five places: the patch cable, the switch port, the controller jack you did not configure, the controller's routing decision on the way back, and the HTTP server itself. When four of six controllers in a cell serve a page and two time out, the two failures are almost never in the same place as each other's IP address field — that field is the one thing everybody checks first, and it looks correct on both.

The RIPE screen carrying entries on exactly the two dead controllers is a fingerprint, not a cause. That peer table does not filter traffic, does not authenticate, and does not bind TCP 80. What it tells you is that those two controllers were commissioned for an inter-controller function, which nearly always means a second Ethernet segment, a second port with an address on it, and a router entry that may not belong to the plant network. Follow the packet in that order.

Is the address on the jack you plugged into?

Layer one first. Confirm link and activity at the controller jack and at the switch port, then confirm the switch has learned the controller's MAC on that port. A dark link LED ends the investigation before any protocol argument starts.

The controller main board carries two Ethernet ports, and the TCP/IP setup screen shows one of them at a time. Open MENU → SETUP → Host Comm → TCP/IP, then use F3 [PORT] to toggle between Port#1 and Port#2. Each port holds its own robot name, IP address, subnet mask and router address. An engineer who glances at the screen, sees the plant IP, and walks away has read whichever port was last selected — not necessarily the one with the cable in it. Record both ports on both failing controllers before changing anything.

Address changes take effect on a cold start on most software versions. Make the edit, cycle control power, and re-read the screen; a value that reverts or fails to apply is telling you the edit never committed.

Then rule out a duplicate. Plug a laptop into the same switch on the same subnet:

:: laptop on the same subnet, same switch
arp -d *
ping <robot-ip>
arp -a | findstr <robot-ip>

One MAC address in the ARP table, and the ping stops replying when you power the controller down. If replies continue with the controller off, another node owns that address and you have been talking to it all along.

Do the two ports share a subnet?

The controller makes one routing decision per destination and holds one default gateway. Give Port#1 an address in 192.168.1.0/24 and Port#2 another address in the same 192.168.1.0/24 and the stack now has two candidate interfaces for the same network. The result is asymmetric and version-dependent: the TCP SYN arrives on the cabled port, the SYN/ACK leaves the other one into a segment that goes nowhere, and the browser sits on "connecting" forever while ICMP echo — which some stacks answer on the receiving interface — still looks healthy. That combination, ping up and HTTP dead, is the signature of an overlap.

This is exactly where an inter-controller link bites you. Peer entries usually mean a private robot-to-robot segment on the second port. If whoever built that segment reused the plant subnet range, the two link-configured controllers are the only two in the cell with overlapping interfaces.

Fill that worksheet for all six controllers. The two odd rows fall out of the table without further debate. Prove the fix by pinging from a client on the far side of the router: if a same-subnet ping succeeded and a routed ping still fails, the gateway is on the wrong port.

Is the HTTP server published and reachable on port 80?

With the transport path proven, move to layer 7. Open MENU → SETUP → Host Comm, select the HTTP protocol entry, and confirm the server is enabled and the pages are published. Authentication produces a credential prompt, not a timeout — that difference in failure signature separates a layer 3 problem from a layer 7 one before you touch a password.

Test the socket, not the browser. Browsers hide RSTs, retry silently, and hand private addresses to a corporate proxy:

curl -I http://<robot-ip>/
Test-NetConnection <robot-ip> -Port 80

An HTTP status line back, or TcpTestSucceeded : True, means the server is listening and the path is clean. If that works and the browser still fails, add the robot subnet to the proxy bypass list and type the scheme explicitly as http://<robot-ip>/; browsers that upgrade to HTTPS on their own get nothing, because the controller's classic web server does not serve TLS.

What is the RIPE table actually for?

It is the peer list that inter-controller functions use to find the other controllers by name and address — the table an option reads when it needs to know which physical robot is number two. Link, coordinated and multi-arm motion, and inter-controller position exchange all depend on a peer list of this kind. Entries mean somebody commissioned such a function, or the controller was restored from a backup taken off one that had it.

Do not clear it because it looks unfamiliar. Read MENU → STATUS → Version ID and the order file to see which inter-controller options are actually loaded on that controller. If a link option is present and the peer table is wrong, you get link alarms and possibly a motion hold — a different and far more expensive fault class than a dead web page. If no such option is loaded, the entries are leftovers from a cloned image, and so are the port and router settings that came with them.

Use the peer addresses as evidence. Peers in the same subnet as your plant address confirm the overlap described above. Peers in their own subnet tell you which physical port belongs to the link, and therefore which port must carry the plant address and the gateway. Faster than paging the pendant: pull an All of Above backup from one working controller and one failing controller and compare the host comm setup file (SYSHOST.SV) side by side — port bindings, router entries and HTTP state in one diff.

How do you prove the path end to end?

1. Cold start after the last TCP/IP edit, then re-read both ports with F3 [PORT] and write the values down.
2. Confirm link at the controller jack and that the switch shows the controller MAC on that port.
3. From a laptop on the same subnet and same switch: ping <robot-ip> replies, and arp -a shows exactly one MAC for that address.
4. Power the controller down and ping again. No reply is the pass condition; a reply means a duplicate address elsewhere on the segment.
5. From the pendant PING screen, ping the laptop. Success proves the return path and the router entry on that port.
6. From the routed client you will actually browse from: ping <robot-ip> replies. If step 5 passed and this fails, the gateway is on the wrong port or the two ports overlap.
7. curl -I http://<robot-ip>/ from that same client returns a status line. A timeout here with ping working puts the fault in the HTTP server or the proxy.
8. Load http://<robot-ip>/ and confirm the served page reports the same robot name as the TCP/IP screen on the controller in front of you. Repeat for all six and confirm six distinct names.

FAQ