Why Won't the PAC 3000 Local Ethernet Port Take Modbus TCP?

The PAC 3000 CPU has two Ethernet ports, and they do different jobs. The External Ethernet port is the general-purpose port for programming, HMI traffic and Modbus TCP. The Local Ethernet port is the remote I/O port. It is built to run a separate network where the CPU and its own remote I/O devices are the only things on the wire, and its IP address is not something you set to fit a plant addressing plan. Most lost nights on this platform come from treating the two ports as interchangeable.

Skip the Quick Fixes That Fail

These are the moves people make first. Each one costs time.

Quick fix	Why it fails
Plug third-party Modbus TCP devices into the Local Ethernet switch	The port serves the remote I/O network. It does not act as a general Modbus TCP client port for other vendors' devices. Foreign devices on that segment also add traffic the remote I/O scan was never designed to share.
Re-address the Local Ethernet port to match the plant IP scheme	The port's IP address cannot be changed. The design assumes an isolated network, so it has no need to fit a plant subnet.
Bridge the remote I/O switch into the plant or campus network so IT can manage it	This breaks the core assumption that the CPU and its remote I/O are the only devices on the segment. Broadcasts, other hosts and IT policy all land on your I/O network.
Write the IP address from ladder logic based on a selector input	The port IP addresses are not exposed for runtime change from ladder on the firmware this limitation applies to. You cannot build a single-image deployment around it without confirming support in your firmware.
Hand the customer one USB flash drive per machine and hope the labels survive	This works until someone loads Machine 3's project into Machine 5. Duplicate IP addresses then appear on the plant network, and the HMI talks to the wrong machine.

Get it running, then fix it properly. The steps below do both.

Know Why the Local Ethernet Port Is Locked Down

A dedicated remote I/O network works like a backplane extension. The CPU owns the network. The devices on it are the ones the CPU expects to find, and the addressing is set by the controller design, not by a site plan. Keeping that network closed gives you three things:

• Predictable traffic. Only I/O exchange rides the segment, so update times don't swing when an HMI, a laptop or a camera starts talking.
• No address conflicts. The controller uses fixed addressing that you can repeat on every machine. That only works because the segments never meet.
• No exposure. Plant broadcasts, discovery traffic and IT scanning never reach the I/O devices.

The port was designed this way on purpose. Opening it up to third-party devices, or making its address configurable, would take real architectural changes, not a checkbox. Design around it: the External Ethernet port faces the plant, and the Local Ethernet port faces only its own remote I/O.

Match the Symptom to the Cause

Symptom	Likely cause	First check
Third-party Modbus TCP device never answers when wired to the Local Ethernet side	Device is on the remote I/O port, which is not a general Modbus TCP port	Move the device to the External Ethernet network and address it in that subnet
Remote I/O faults or slow updates after plant switches were tied in	Remote I/O segment is no longer isolated; foreign traffic is present	Trace the Local Ethernet cable and unplug any uplink to plant switches
IT refuses to connect the remote I/O drop; the PAC is rejected for the project	Site policy requires every Ethernet connection to be managed and addressed by IT, but the Local Ethernet IP cannot change	Reclassify the remote I/O network as machine-internal wiring (see below)
Duplicate IP alarm on the plant network, or HMI shows the wrong machine	Wrong machine's project was loaded onto a CPU	Compare the External Ethernet IP in the running project with the machine's label
Ladder code writing an IP value has no effect	Port IP is not settable at runtime on this firmware	Check the firmware release notes and programming software help for runtime IP support

Move Third-Party Modbus TCP Devices to the External Ethernet Port

The External Ethernet port handles programming, HMI and Modbus TCP together. Put every non-remote-I/O device on it.

1. Install a switch on the External Ethernet side. Use a managed switch if the site requires one. That is the network IT can own.
2. Assign every third-party Modbus TCP device a static IP in the same subnet as the External Ethernet port. Record each address and its Modbus unit ID on the panel drawing.
3. In the project, configure the Modbus TCP client connections to those IP addresses through the External Ethernet port. Set a timeout and retry count for each device so a dead device shows a fault and doesn't stall the scan.
4. Stagger polling so slow devices don't sit on the same trigger as fast ones. Enable a poll only after the previous transaction to that device completes or times out.
5. Map each connection's status bits to an HMI alarm. A device that silently stops answering is worse than one that faults loudly.
6. Leave the Local Ethernet port cabled only to its remote I/O switch and remote I/O devices. Nothing else goes on that switch.

Stop here if the External Ethernet segment is badly loaded: a large HMI tag count, many polled devices and plant traffic all on one port. Measure response times per device before adding more. If the numbers are bad, reduce what the HMI polls, or split polling across time slices in logic.

Deploy Identical Machines Without IP-in-Ladder

The goal is one program image for five identical machines, with the machine number selected by inputs (for example a P3-16SIM simulator module or hardwired jumpers) and the IP set from that number. That depends on runtime IP configuration. If your firmware doesn't offer it, use one of these approaches.

Approach	How it works	Trade-off
One project, NAT router per machine	Every machine uses the same External Ethernet IP internally. A small 1:1 NAT router on each machine presents a unique plant-side address.	One image and one USB drive for all machines. Costs a router per machine, and the HMI or SCADA must target the NAT addresses.
One project, machine ID from inputs, IP per project variant	Logic reads the selector for machine-specific behavior (recipes, tags, HMI text). IP is still set per project file.	Logic stays common, but you still manage one file per machine.
Separate project per machine, controlled distribution	Each file name carries the machine number and IP. Each USB drive is labeled and tied to one panel.	Simple, but it relies on discipline. Mix-ups cause duplicate IPs.

For the NAT approach:

1. Set the same External Ethernet IP and subnet on all machines.
2. Configure each machine's NAT router with its unique plant-side address, mapped 1:1 to the internal PAC address.
3. Point the HMI, SCADA and programming laptop at the plant-side addresses.
4. Label the router, not the USB drive. The USB image is now machine-independent.

If you keep a selector for machine identity, read it into a register at first scan and latch it. That way a bumped jumper doesn't change behavior mid-run. Show the machine number on the HMI home screen so the operator can confirm it at a glance.

Keep Remote I/O Legal on a Managed Campus

Sites that require every Ethernet connection to be managed often treat the remote I/O cable like a plant drop. It isn't one. Here is how to get it through review:

1. Document the Local Ethernet network as machine-internal wiring, the same as a backplane or a device bus. It never leaves the panel or machine, has no uplink, and carries no routable plant traffic.
2. Physically separate it. Use a dedicated switch, or direct connections, inside the panel. Color-code the cables and label the switch ports so maintenance doesn't patch it into a plant jack.
3. Give IT only the External Ethernet port as the managed plant connection. That address fits their scheme.
4. If policy still requires every IP on every segment to come from the site plan, the fixed Local Ethernet addressing won't pass. Choose a different remote I/O approach for that project before the panel is built.

Stop here if IT insists on putting remote I/O traffic on their managed infrastructure. Changing the cabling won't satisfy that requirement, and forcing it breaks the isolation the remote I/O depends on.

Verify the Fix

1. Disconnect the External Ethernet cable. The remote I/O on the Local Ethernet side must keep running with no faults. That proves the I/O network is self-contained.
2. Reconnect it and confirm every third-party Modbus TCP device shows good status, with values updating on the HMI.
3. Pull one Modbus TCP device's cable. Confirm its status bit faults, the alarm shows, and the other devices and the remote I/O are unaffected.
4. From a laptop on the plant network, confirm you can reach only the External Ethernet address (or the NAT address). The Local Ethernet network must not be reachable.
5. For multi-machine sites, check each plant-side address against the machine label and the machine number shown on the HMI. Look for duplicate IP warnings on the plant switch or on SCADA.
6. Save the as-built IP table, including device, port, IP, unit ID and poll rate, inside the panel and with the project archive.

FAQ