The Ethernet conflict means the panel and the PLC hold one IP address between them, usually because the PLC's address was entered in the panel's own IP field. Give the panel its own unused address on the PLC's subnet, keep the PLC's address in the driver's destination field, and verify with a live value.
An Ethernet conflict message on an HMI panel means two devices on the link are holding one IP address between them. The usual cause is a shortcut: the PLC's address gets typed into the panel's own IP field for a direct connection. The panel then becomes a second copy of the PLC. The fix is to give the panel its own unused address on the PLC's subnet, and to keep the PLC's address in the driver's destination field where it belongs.
This page lists the symptoms and what each one points to, explains the DHCP fallback that strands a panel on a 169.254.x.y address, walks a worked example with the arithmetic shown, and gives the order to change and verify everything. No cable swap fixes an address conflict. The port's LINK light will sit green through the whole fault.
Why does an HMI panel report an Ethernet conflict on a direct PLC link?
The conflict means two devices on the same link hold one IP address between them. In this fault that means the PLC's own address, 192.254.207.182, entered into the panel's IP field, so the panel has become a second copy of the controller.
Every device on an IPv4 Ethernet network needs an address no other device holds. When the panel calls the controller, the PLC sends its reply back to the source address carried in the request. With the panel sitting on the PLC's address, that reply comes straight back to the PLC, and the panel never sees an answer. Address lookups along the path now map one IP to two hardware addresses, so replies land on whichever device answered last. Panels and controllers that run duplicate-address detection stop using a contested address and raise the conflict. Controller manuals for EtherNet/IP devices document the outcome plainly: both stations enter conflict mode, and neither communicates until one address changes.
The panel's own message, repair the conflict and cycle the power, is that detection doing its job. The power cycle alone repairs nothing while the project still carries the duplicated address. The fault survives every restart until the addresses differ.
How did the panel end up with the PLC's address?
A project carries two address settings that are easy to mix up: the panel's own local IP, which identifies the panel on the network, and the PLC driver's destination IP, which tells the panel which controller to call. Only the destination field should hold 192.254.207.182.
Both fields look like the IP address in the software, and a direct-connection setup makes it worse, because it asks only for the PLC's address. The panel's own address lives in its network settings. On panels that label the screen this way, the path is Setup > Touch Panel Network > Ethernet Port, where the port is set to one of two modes, Obtain Address from DHCP or Use the following IP Address. The same value is reachable from the project transfer dialog through Ethernet > Browse > Change IP Address, which is the way in when a failed transfer is what led you here. The destination address lives elsewhere: in the project's PLC device configuration, on the entry that selects the controller's Ethernet driver.
So there are two possible mistakes and one of them is this fault. The PLC's address in the panel's own field duplicates the controller. The panel's address in the destination field aims every request at the panel itself, which shows up as timeouts with no conflict message at all.
What does each symptom of the conflict point to?
Read the symptom against the two addresses before touching anything, because each one points at a different layer: the same address in both fields means a duplicate, an address starting 169.254 means a missed DHCP request, and a lit LINK light with a conflict means the cable is fine.
| Symptom | What it points to | What to do |
|---|---|---|
| Panel and PLC fields both read 192.254.207.182 | One shared identity; the controller cannot answer the panel | Give the panel a unique address on the PLC's subnet |
| Panel address starts 169.254 | The port asked for a DHCP address, no server answered, and the port self-assigned a link-local address | Switch the port to a fixed address on the PLC's subnet |
| LINK light on, conflict message up | The physical link is good; the fault is addressing | Leave the cable alone and correct the addresses |
| Addresses unique, still no data | The masks differ between the devices, or the destination address is wrong | Compare masks, then read the destination back from the project |
| Conflict returns after every transfer and restart | The project still carries the duplicated address | Correct the address first; restarting reloads the same wrong value |
Work down the table in order. The first two rows need an address change or a mode change. The last three are only reached once the panel holds a unique address.
What IP address should the panel get instead?
Give the panel the PLC's address plus one on the last octet: a PLC at 192.254.207.182 with a 255.255.255.0 mask takes a panel at 192.254.207.183, unique on the link and inside the same subnet.
The rule has two parts. The address must be unique on the link, and it must sit in the same subnet as the controller under the masks both devices carry. A subnet mask is a string of ones followed by zeros, and the ones mark the network part of the address. With 255.255.255.0, 24 of the 32 bits are ones, so the first three octets are the network and the fourth octet picks the device. That is where the rule of thumb first three octets match, last octet differs comes from. Usable device addresses in that subnet run from 192.254.207.1 through 192.254.207.254, which is 254 addresses in total, because .0 names the network and .255 is its broadcast address.
If the controller's mask is anything other than 255.255.255.0, read the configured value from the PLC and enter that same mask on the panel; the octet rule only holds for 255.255.255.0. Then prove the address is free: with the panel still disconnected, put a laptop on the link, give it any address in the same subnet, and ping 192.254.207.183 for 3 seconds. A reply means something already holds the address; silence is the result you want.
Does the panel need DHCP or a fixed address on a direct link?
On a direct cable between panel and PLC there is no DHCP server, so set the panel's Ethernet port to a fixed address. A port left on automatic finds no server, falls back to a self-assigned 169.254.x.y link-local address, and that address cannot reach a PLC at 192.254.207.182.
The fallback value is not random. The IPv4 link-local range 169.254.0.0/16 is set aside in RFC 3927 for devices that configure themselves without a server: a port that gets no answer to its DHCP request picks its own address from that range. Link-local traffic works only when every device on the link is using it, so a panel on 169.254.x.y has no path to a fixed 192.254.207.x network.
Set the mode to Use the following IP Address, enter the new panel address and the controller's mask, and stay on fixed addressing for a direct cable. Automatic addressing is the right choice only where a DHCP server actually runs on that network, and then the job is to read back the address the panel was given. If that readback is the part that keeps going wrong, finding a panel's DHCP address without guessing covers the method.
Worked example: the PLC is at 192.254.207.182, so what goes in each field?
With the PLC at 192.254.207.182 and a 255.255.255.0 mask on both devices, the panel takes 192.254.207.183, the PLC driver's destination stays 192.254.207.182, and the two values are entered in two different places in the project.
The mask decides it. 255.255.255.0 in binary is 24 ones followed by 8 zeros. The first 24 bits, written 192.254.207, are the network part, and the fourth octet selects the device.
- PLC: 192.254.207.182, network part 192.254.207, device part 182.
- Panel: 192.254.207.183, same network part, device part 183, one step above the controller and free.
- Range check: usable device addresses run from 192.254.207.1 to 192.254.207.254, 254 in total; 192.254.207.0 names the network and 192.254.207.255 is the broadcast, so .183 is a valid choice.
| Setting | Where it is entered | Value |
|---|---|---|
| Panel's own IP address | Panel network settings, Ethernet port tab | 192.254.207.183 |
| Subnet mask | Same screen | 255.255.255.0 |
| Addressing mode | Same screen | Use the following IP Address |
| PLC destination address | Project's PLC device configuration, Ethernet driver | 192.254.207.182 |
Transfer the project, apply the settings, wait about 30 seconds for the port to come up, and cycle the panel's power once: the conflict message is gone. The table also shows both ways to get it wrong again. 192.254.207.182 in the first row re-creates the duplicate. 192.254.207.183 in the last row makes the panel call its own address, so no request ever reaches the controller.
What order do I fix and verify the connection in?
Change the addresses first and cycle power once, at the end: read the PLC's address and mask, give the panel its own fixed address on that subnet, leave the driver's destination on the PLC, transfer, power-cycle the panel once, and confirm a live value changes on screen.
- Read the controller's current IP address and subnet mask off the PLC and write them down: 192.254.207.182 with a 255.255.255.0 mask in the example.
- Ping the candidate panel address for 3 seconds while the panel is still disconnected; if something answers, take the next free octet.
- In the panel's network settings, select
Use the following IP Address, enter the new address, and enter the controller's mask on the same screen. - In the project's PLC device configuration, confirm the driver and its destination address still read the controller's current address.
- Transfer the project, apply the network settings, and cycle the panel's power once if the software asks for it. Transfers and restarts before this point change nothing, because each one reloads the same duplicated address.
- Read the panel's address back from the network settings or the transfer dialog after startup, so the new value is confirmed on the panel and not only in the project.
- Verify with data: change a value in the PLC and watch the panel object update. A lit LINK indicator means the ports linked at the physical layer; it does not prove the addresses are right. Where the software offers communication diagnostics, read the request and response counters.
- If values stay stale after all of this, work out whether the panel itself is frozen or the PLC link dropped before changing more settings.
- If the panel comes back without its project after the power cycle, treat that as its own fault; and before the panel writes anything to the machine, follow the operator panel link setup that tests writes before motion.
Safety note: keep this address pair on the isolated cable. Before either device joins a shared plant or office network, the network owner must assign and authorize the addresses, because 192.254.x.x is not one of the private IPv4 ranges and may already belong to another site on a routed network.
Recommendation: on a direct panel-to-PLC cable with no DHCP server, set the panel's Ethernet port to a fixed address one step above the controller on the same subnet, 192.254.207.183 against a PLC at 192.254.207.182 with a 255.255.255.0 mask, enter the PLC's address only in the driver's destination field, and cycle power once after the transfer. Choose automatic addressing only where a DHCP server actually runs on that network.
Questions
Is 192.254.207.182 a private address I can reuse anywhere?
No. The private IPv4 ranges set aside in RFC 1918 are 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255 and 192.168.0.0 to 192.168.255.255. An address like 192.254.207.182 sits outside those blocks, which is why it works on an isolated panel-to-PLC cable but must never be carried onto a routed plant or office network without the network owner assigning it.
Do I still need a crossover cable between the panel and the PLC?
Usually not on current hardware. Ethernet ports with automatic crossover negotiate the transmit and receive pairs themselves, so a standard straight-through cable works on a direct link. The crossover cable in an older setup is harmless, and the cable was never the fault here: a lit LINK light with a conflict message means the physical link came up and the addresses were wrong.
Why does the panel ask me to repair the conflict and cycle power?
Controller manuals document duplicate-address detection for Ethernet-enabled controllers: when two stations claim one address, both enter conflict mode and stop using the address until an operator intervenes. The power cycle only helps after a unique address has been entered, because restarting reloads the same duplicated address if the project still carries it.
What changes when a second panel joins the same link?
Nothing about the rule: every device gets its own last octet on the shared subnet. With the PLC at 192.254.207.182 and the first panel at 192.254.207.183, the second panel takes 192.254.207.184 with the same 255.255.255.0 mask, and each panel's driver keeps the PLC's address as its destination. Ping each new candidate address before you commit it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.