Finding an LS XGT PLC's IP address when you don't know it

You are standing in front of a panel you did not commission. XG5000 wants an IP address before it will connect, the label on the CPU is gone or was never there, and the drawing in the folder is two retrofits out of date. The plant is running, so unplugging things to see what falls over is not on the table.

Why a ping sweep is the wrong first move

The reflex is to sweep the subnet — 254 addresses, ICMP or a TCP connect on a few likely ports, and see what answers. It does work often enough that people keep doing it. But on a live control network it has three problems.

• It is loud. A sweep sends packets to every address in the range, including drives, HMIs and safety devices that have nothing to do with your task. Some older equipment handles unexpected connection attempts poorly.
• It is slow. Two hundred and fifty four addresses times a per-port timeout adds up, and you are usually doing this while somebody waits.
• It tells you an address answered, not what it is. You still have to work out which of the five responding hosts is the PLC.

The vendor-specific discovery below avoids all three: it is one packet in total, the answers come back within a couple of seconds, and anything that replies is by definition an LS PLC.

What the discovery exchange looks like

Bind a UDP socket to port 2007, enable broadcast, and send the request to the broadcast address on the same port. Two request strings are worth sending — older and newer firmware do not answer the same one:

bind    UDP 0.0.0.0:2007          (broadcast enabled)
send -> 255.255.255.255:2007      "STATION_LIST_REQ_DATA"
send -> 255.255.255.255:2007      "NP_DATA_REQ_V2"
listen  ~2 seconds

recv <- 192.168.0.31:2007         "STATION_LIST_RESP_DATA…"   <-- a PLC, at 192.168.0.31
recv <- 192.168.0.44:2007         "STATION_LIST_RESP_DATA…"   <-- another one

The payloads are plain ASCII, which is why this is easy to recognise in a capture. The part that matters is not inside the response body at all — it is the source address of the reply datagram. Everything after the STATION_LIST_RESP_DATA marker is station detail; you can ignore it entirely if all you need is somewhere for XG5000 to point at.

Note that the socket binds to 2007 rather than an ephemeral port. Replies come back to that port, so if something else on the machine already holds it, the bind fails and you will see no responses at all — not an empty network, just a busy port. That failure mode is easy to misread.

When nothing answers

A silent result does not mean there is no PLC. In rough order of how often each one turns out to be the cause:

• The PLC is on a different subnet. A broadcast to 255.255.255.255 stops at the first router — it never leaves the local segment. If your phone or laptop pulled a DHCP address on the office VLAN and the control network is somewhere else entirely, no amount of listening will help. This is the single most common reason.
• You are on Wi-Fi and the AP filters broadcast. Client isolation and broadcast/multicast suppression are on by default in a lot of enterprise wireless. The request leaves your device and dies at the AP.
• The control network is wired-only. Plenty of plants keep the PLC segment off Wi-Fi deliberately. Nothing you do from a phone will reach it.
• Port 2007 is already bound on your machine, as above.
• The CPU has no Ethernet module, or the FEnet module is present but not configured. Serial-only CPUs will never answer a network discovery.

The first two are worth checking before anything else, because both are invisible from the tool's side — the request looks like it was sent successfully in every case.

Once you have the address

With the IP in hand, XG5000 connects the ordinary way: Online → Connection Settings, type Ethernet, enter the address, then connect and read the project from the PLC. If the connection is refused rather than timing out, the address is right and something else is wrong — a full connection table on the FEnet module is the usual culprit, and it clears when a stale session times out.

A word on scanning equipment you do not own

Discovery is a read. It does not change a register, a mode switch or a program. But it is still traffic aimed at industrial equipment, and on a site that is not yours, that is the site owner's call to make and not yours. Get the go-ahead first. Write and job frames are a different category entirely and have no place in a discovery tool.

Related notes

• Identifying industrial devices by port — what the other five ports on a plant network mean, and how far a port number can be trusted.