Resolving PLCnext Controller IP Address Loss on Restart

Overview of the PLCnext IP Address Loss Fault

Phoenix Contact PLCnext Control devices (AXC F 1152, AXC F 2152, AXC F 3152, and the EPC 1502 / EPC 1522 edge controllers) may appear to "lose" their configured IPv4 address after a power cycle, restart, or download cycle. In most field cases the controller has not actually lost the address at the firmware level — the address has been overwritten or reset by an action performed inside PLCnext Engineer (the IEC 61131-3 programming environment) or by a button-press / web-based factory reset on the device itself.

Because the symptom (controller unreachable on the previously known IP) is identical regardless of the underlying cause, the troubleshooting sequence is:

1. Verify whether the controller is reachable on any IP at all (scan, ARP cache, Wireshark).
2. Determine whether the configuration was actively reset, passively overwritten, or corrupted by an interrupted download.
3. Apply the corrective action that matches the root cause.
4. Verify persistence across a controlled power cycle.

Affected Products and Firmware

Always confirm the firmware version installed on the controller before troubleshooting. The firmware is reported on the WBM (Web-based Management) home page at https://<current-ip>/wbm or at https://<current-ip> on controllers shipped from 2022 onward. Cross-reference the firmware against the release notes in the PLCnext Control product area to identify known IP-stack bugs that have been fixed in later service packs.

Root Cause Analysis: Why the IP Disappears

Cause 1 — Factory Reset Performed on the Controller

PLCnext Control devices expose a Restore Factory Defaults function. On the AXC F 2152 and AXC F 3152, this is reachable in two ways:

• WBM path: WBM → Administration → Restore Factory Defaults. Confirming the dialog commits the reset immediately and reboots the controller.
• Physical button: Some PLCnext Control variants include a recessed reset button on the front face. Holding it for the specified time (typically 8–10 s) triggers a factory reset and reboot.

A factory reset clears the IP address, subnet mask, default gateway, PROFINET device name, and any project-specific routing. The controller reverts to the DHCP client behavior defined at shipment (no static address).

Cause 2 — Project Settings Written to the Controller

PLCnext Engineer ships each project with a PLC settings dataset that includes the controller name, IPv4 address, subnet mask, default gateway, and (optionally) DNS and PROFINET parameters. The Write project settings to the PLC command pushes this dataset to the controller and overwrites whatever is currently stored. Running this command — or running a full Build & Download — from a project that contains an empty or default-filled PLC settings block will erase the IP previously configured on the device.

The PLC settings tab is reached through Project → PLCnext → PLC Settings in PLCnext Engineer. The relevant fields are:

Cause 3 — Interrupted Write to NVRAM

The PLCnext Control firmware writes the active IP configuration to NVRAM only after a graceful shutdown of the pnconfig service. If power is removed during the write window (typically the last 2–3 s before the controller reboot completes), the previous configuration can be invalidated. The controller then boots with no static address and falls back to DHCP.

Cause 4 — DHCP Override

When the controller is configured to obtain its address via DHCP, any DHCP server on the network can hand out a new address at the next lease renewal. This is not technically a "loss" of the IP, but it presents the same symptom to the engineer who last knew the controller at a fixed address.

Diagnostic Procedure

Work through the following checks in order. Each step produces a definitive result that points to one of the four causes above.

1. Scan the subnet. Use the PLCnext Scanner utility or the Online → Accessible Devices dialog in PLCnext Engineer. The controller will appear with its MAC address even if its IP is unknown.
2. Read the WBM. If the controller responds on any IP (including a DHCP-leased one), open the WBM and inspect Administration → Network. The current IPv4 configuration is displayed directly.
3. Check the controller LEDs. The LINK and ACT LEDs on the Ethernet port indicate physical-layer connectivity only. A correctly configured controller with a valid link will show steady LINK plus blinking ACT.
4. Inspect the PLCnext Engineer project. Open the project last deployed to the controller. Compare the PLC Settings block against the desired runtime configuration. An empty block is the most common finding.
5. Review the controller's syslog. In WBM → Diagnostics → System Log, search for entries containing pnconfig, networking, or factory-reset. A factory reset produces a clearly identifiable log line.

Step-by-Step Resolution

Resolution A — Recover From a Factory Reset

1. Connect a PC directly to the controller's ETH1 (or X1) port using a Cat 5e or better patch cable.
2. Set the PC's Ethernet adapter to a static address in the 192.168.0.0/16 range (Phoenix Contact uses 192.168.1.x on first boot when no DHCP is available).
3. Open the WBM at https://192.168.1.2 (default address when the controller boots without stored configuration) and accept the self-signed certificate warning.
4. Navigate to Administration → Network → IPv4 and enter the desired static configuration: address, subnet mask, default gateway.
5. Click Apply. The WBM prompts to commit the change; confirm and wait for the controller to apply the new settings without rebooting.
6. Power-cycle the controller and verify the address persists.

Resolution B — Recover From an Accidental Project Overwrite

1. Open the PLCnext Engineer project that should run on the controller.
2. Open Project → PLCnext → PLC Settings.
3. Enter the desired IP address, subnet mask, and gateway. Use the controller's actual operational address; do not leave the field empty.
4. Right-click the controller node in the project tree and choose Apply PLC settings to the project. This reads the current configuration from the controller into the project — useful when the project was created without the device's runtime IP.
5. Build the project and download only the changed PLC settings dataset, not the full program, using Online → Download PLC Settings.
6. Verify in the WBM that the address persists after the download completes.

Resolution C — Prevent Loss Across Power Cycles

1. Always perform a controlled shutdown through the WBM (Administration → Reboot) before removing power.
2. Disable the Write project settings to the PLC action for projects where the engineering workstation IP differs from the deployed IP.
3. If the controller is on a DHCP-enabled network, reserve the desired IP in the DHCP server (static lease keyed to the controller's MAC address, which is printed on the front face label and listed in WBM → Diagnostics → System Information).

Using the Ad-hoc IP Address for First Contact

PLCnext Engineer and the PLCnext firmware support an Ad-hoc IP mechanism that does not require the controller to have a valid IP at all. The feature is intended for first-contact commissioning in a lab or classroom where the engineering PC and the controller are on the same physical segment.

1. Connect the PC directly to the controller.
2. In PLCnext Engineer, open Online → Accessible Devices and click Ad-hoc IP.
3. PLCnext Engineer assigns a temporary 169.254.x.x / 16 link-local address to the controller and establishes a session.
4. From the active session, navigate to PLC Settings and write the operational IP back into the device.

The ad-hoc address is volatile. It is discarded as soon as the controller reboots, so this path is for configuration only — not for runtime operation.

Project Engineering Best Practices for the Classroom and the Plant

When the same project template is handed to multiple engineers or students, package the PLC settings dataset so that the project always carries a known-good IP configuration:

• Lock the PLC settings block with a project-wide default; students/engineers override only if their network segment differs.
• Document the IP and subnet in the project header (a comment block at the top of the PLC_PRG program file is the conventional location).
• Disable the Factory Reset privilege for non-admin WBM users through Administration → User Management.
• Always use Apply PLC settings to the project as the read direction. This pulls from the controller into the project and is the safe direction when the controller's runtime IP is the source of truth.
• Reverse the read direction with caution. Write project settings to the PLC pushes the project's IP into the controller and will overwrite an in-service configuration.

Verification Procedure

1. After applying the fix, ping the configured IP from the engineering workstation: ping <controller-ip>. Expect replies with sub-millisecond times on a directly connected segment.
2. Open the WBM in a browser and confirm the displayed IP matches the configured value.
3. Open PLCnext Engineer → Online → Accessible Devices and confirm the controller appears at the configured IP with the configured name.
4. Perform a controlled reboot through the WBM. Re-verify the IP.
5. Perform an uncontrolled power cycle (pull the power connector, wait 10 s, restore). Re-verify the IP.
6. Document the final configuration (IP, subnet, gateway, MAC, firmware version) in the project README and the asset registry.

Cross-Platform Notes: Similar IP-Loss Symptoms on Other Controllers

The "IP address disappears after power cycle" symptom is not unique to PLCnext. Two documented cases on other platforms illustrate the same pattern:

• Rockwell Automation CompactLogix 5380 and 1756-EN4TR modules: EtherNet/IP addresses are reported as lost or changed after power is cycled. The official Rockwell Automation knowledge base documents the failure mode and the corrective firmware revision that resolves it. See the KB article EtherNet/IP Address is Lost or Changes After Power is Cycled for the affected catalog numbers and firmware threshold.
• B&R Automation X20CP3687X: A B&R Community thread reports the controller losing its configured IP at every restart on certain AR version I4.11 firmware builds. The remedy in that case was a firmware upgrade to a build that contains the corrected network stack.

Takeaway: when the IP loss repeats across multiple controllers of the same model and firmware, treat it as a firmware bug and consult the manufacturer's knowledge base for a corrected firmware revision before debugging the configuration.

Troubleshooting Matrix

FAQ