Why Does the P3-550 Stop on E01701 and E01005 After a Storm?

Skip the Quick Fixes That Don't Hold

The failure looks like this. A Layer 2 loop forms on the plant network, often because Spanning Tree Protocol (STP) drops out after a switch software update. Traffic starts circulating around the fiber ring. Every P3-550 on that segment reboots itself and comes back in STOP, with E01701 and E01005 logged. Nobody touched power and nobody moved the RUN/STOP switch. DL06 and DL205 CPUs on the same segment, with the same Modbus TCP and programming connections, keep running.

These are the usual night-shift moves and why none of them hold:

Production comes back in this order: stop the storm, recover the CPU, load firmware that ignores the flood, then configure the switches so a storm cannot reach the PLCs again. Get it running, then fix it properly.

Kill the Loop Before You Touch the CPU

At Layer 2, frames have no hop limit. When STP is not blocking a redundant path, a broadcast frame goes around the ring and every switch floods it out every port on every pass. Within seconds each host on the segment receives the entire circulating load. Most endpoints drop frames they have no use for. On pre-1.1.15.111 firmware, the P3000 external Ethernet port tried to process that traffic instead and crashed the processor.

1. Find the switch or switches that were updated most recently. On a plant network, a recent switch software change is the first suspect.
2. Check the STP status on every switch in the ring. Confirm that STP is enabled, that a single root bridge is elected, and that exactly one ring port is in blocking state.
3. If STP will not converge, break the ring by hand. Shut down or unplug one fiber uplink between two ring nodes. The ring becomes a line, which cannot loop.
4. Restore the STP configuration on the updated switch. Compare it against a switch that was not updated, or against your saved config backup.
5. Put the redundant link back only after STP shows the expected blocking port.

Check: Watch broadcast and multicast counters on the switch ports that feed the PLCs. The counters should drop back to their normal background rate, and link and activity LEDs should stop showing solid, continuous activity. Stop here if the counters are still climbing. Any CPU you put back in RUN will go down again.

Read the Log, Then Return the CPU to RUN

1. Connect with the programming software and open the CPU's error and event history before you clear anything.
2. Record the codes, their timestamps, and the loaded firmware version. The key fact is E01701 logged together with E01005 after an unprompted restart. Look up the exact text for both codes in the programming software help for your firmware build.
3. Match the timestamps against the switch logs. The CPU restart should line up with the moment STP went down or the loop formed. If it does, you have confirmed the cause.
4. Clear the fault and switch the CPU to RUN.

Check: The CPU stays in RUN. Modbus TCP clients reconnect, and the programming software stays online without dropouts. If the CPU restarts again on a quiet network, stop. You have a different problem. Save the log and escalate.

Load Firmware 1.1.15.111

AutomationDirect released 1.1.15.111 with changes to the external Ethernet port handling. On this build, the CPU ignores unexpected traffic such as network storms instead of trying to process it and crashing. With this change, the P3000 behaves like the DL-series processors on the same segment. Treat it as protection against crashes. It does not replace a working network.

The update needs the physical RUN/STOP switch in the STOP position. You cannot bypass this, and you cannot run the update remotely with only a program stop. This is deliberate. If communications drop partway through a remote flash, the partially written firmware can leave the CPU unrecoverable. You then have to travel to the site and replace the CPU anyway, with far longer downtime than a planned visit. Having someone on site during the flash cuts the outage if something goes wrong.

1. Download 1.1.15.111 from AutomationDirect's official site. Read the release notes for any project conversion or software version requirements.
2. Save a backup of the project from the CPU before flashing.
3. Get a qualified person to the cabinet. Take the process to a safe state and move the switch to STOP.
4. Run the firmware update from a laptop on a stable connection. Do not run it across the plant backbone that just stormed. Use a short, direct connection or a local switch.
5. Do not remove power or the cable until the update reports that it is complete.
6. Let the CPU restart. Download the project again if the software asks for it, move the switch back to RUN, and confirm I/O.

Check: Read the firmware version back from the CPU. It must show 1.1.15.111 or a later official release. Check that retained values and recipes survived. Compare them against your backup.

Harden the Switch Ports Feeding PLCs

New firmware keeps the CPU alive through a storm. The storm still takes out Modbus TCP polling and programming access while it lasts. Contain the storm at the switch.

• Storm control / broadcast rate limiting: Enable it on every access port that connects to a PLC. Set the threshold from the traffic you measure during normal operation, with headroom. Use the switch's own documentation for units and limits.
• Edge port protection: Set PLC ports as edge ports and enable BPDU guard or the switch's equivalent, so a stray loop at the panel disables the port instead of flooding the ring.
• Loop detection: Enable it if your switches support it. It is a second layer of protection if STP fails the way it did here.
• Segmentation: Move the more than 30 PLCs off the general plant segment and onto their own VLAN or physical network, routed or firewalled from the office network. A smaller broadcast domain limits how many machines one loop can reach.
• Change control: After any switch software update, check STP state and port roles before you leave the switch. Keep configuration backups of each switch before and after the change.

Check: Review each PLC-facing port. Storm control should be enabled, the port should show as an edge port, and the STP topology should match your drawing. Save the running config so it survives a switch reboot.

Plan the Rollout Across the Plant

With more than 200 PLCs, many in remote or restricted locations and some processes allowing only a few minutes of downtime, flashing every CPU in one night is not practical. Put the network work first and the firmware on a schedule.

Bundle each firmware visit with other on-site work, so the trip, the permit, and the special access personnel count toward more than one job. Carry the project backup and a spare CPU on visits to the most remote or critical sites. A failed flash then costs one swap, not a second trip.

Check: Keep a register of every P3000 with its location, current firmware version, and update date. Close it out when every row shows 1.1.15.111 or later.

Verify End to End

Confirm each layer independently. Do not take the first quiet night as proof.

1. Network: STP shows one root bridge and the expected blocking port. Broadcast counters on PLC ports sit at their normal background rate.
2. Switch protection: On a bench switch or an isolated test segment, create a deliberate loop with a patch cable and confirm that storm control or BPDU guard trips as configured. Never create a loop on the live production ring.
3. CPU: On that same bench setup, connect a spare or out-of-service P3000 running 1.1.15.111 and let it see the storm. It should stay in RUN and log no new E01701/E01005 restart.
4. Application: In production, confirm that Modbus TCP clients and programming connections recover on their own after any network disturbance, without anyone touching the CPU.
5. Next switch change: Watch the PLCs during the next planned switch update. Check the CPU logs afterward for unprompted restarts.

FAQ