A P001 PLC COM timeout that appears at power-up has three checkable causes: the sketch waiting for the USB serial monitor, the base controller missing its 24 VDC feed, and boot order. Test them in that order with a meter and one reset press; the first two clear most cases.
A P001 PLC COM timeout that appears right after power-up has three checkable causes: the controller sketch is waiting for the USB serial monitor, the base controller has no 24 VDC feed, or the panel and the controller boot in an order that leaves the controller waiting on a link partner that is not ready. Test them in that order. The first two explain most setups that ran on the bench and fail on the wall, and each check takes minutes. Swapping cables and the Ethernet switch comes last; an error that repeats at every power-up usually has a start-up cause.
What each symptom points to
- P001 on the panel at every boot. The controller never opened its link. Start with the sketch and the base-controller power.
- Link LEDs dark on the controller and the switch. The CPU is not running its sketch, and the serial monitor wait line is the usual blocker.
- Link LEDs lit, P001 anyway. The sketch is running, so move to the supply feed at the base controller.
- The serial monitor prints "no base controller activity". The base controller and the I/O modules have no power. The USB port that carries programming is not that supply.
- Works on the bench, fails on the wall. The bench has USB plugged in with the monitor open; the wall has neither. That is the wait line again.
- Timeouts on some boots and not on others. Test boot order before anything else.
- Cable and switch already replaced, same error. Both swaps leave the start-up code and its power as the remaining suspects.
First check: the serial monitor wait in the sketch
On an industrial Arduino controller, setup code that ends with while (!Serial){} holds the CPU until a USB serial connection opens. The USB port carries data and a 5 V supply for the CPU, but it does not power the base controller or the I/O modules. On the bench, the USB cable is in and the serial monitor is running, so the sketch passes the line and the link comes up. On the wall, USB is out, the CPU waits forever, the Ethernet link never opens, and the panel reports P001 PLC COM timeout.
Comment the line out, reprogram over USB, unplug the cable, and power-cycle. Give the panel 60 seconds after power-up before you judge the result. The link should come up with no monitor attached. Debug prints can stay in the code; only the wait line blocks. The full walkthrough of this fix is in Fix an Arduino sketch that waits for the serial monitor.
If your link is serial instead of Ethernet and the com light stays dead, use a different checklist: HMI to PLC serial timeout with a dead com light.
Second check: voltage at the base controller
The controller library's documentation requires a P1000 Series power supply or an external 24 V supply to power the base controller and the I/O modules. A CPU that runs and prints over USB can coexist with a base controller that has no power; the "no base controller activity" line in the monitor is that split showing itself.
Put a meter on the supply terminals. The setup this article follows measured +24.0 VDC, which meets the 24 VDC requirement, so power level and presence passed. A reading several volts low, or a monitor that prints "no base controller activity" after the meter shows a healthy reading at the supply, puts the fault in the wiring from the supply to the controller terminals. Isolate the supply before you move any wire.
The sizing side, including inrush when one supply feeds a panel and a controller together, is worked through in Sizing a separate 24 VDC supply for HMI inrush current. A screen that flickers when the controller starts polling points at the same family of fault: HMI backlight flickers when polling: check the power supply.
Third check: which unit boots first
Let the panel reach its runtime screen, then press the controller's reset button once. The controller's documentation describes that single press as resetting code execution, the base controller and all I/O modules, which re-runs the sketch against a panel that is already up. Then test the other order: power the panel first, let it come up fully, wait another 30 seconds, and only then power the controller. If P001 shows in both orders, boot order is not the cause; the first two checks are. In the case this article follows, both orders produced the same error, and the wait line in the sketch turned out to be the cause.
How long a panel takes to reach its runtime screen varies by model, and testing startup behavior first is the subject of Choosing an HMI panel: test startup and runtime first.
Example: one feed, P001 on every boot
Scenario: a bench feeds the panel and the controller from one 24 VDC supply through an Ethernet switch linking at 100 Mbps. Every power-up ends with P001 on the panel after about 30 seconds of waiting. A new cable and a new switch changed nothing.
- Meter the supply. The terminals read +24.0 VDC. The documented requirement is a P1000 Series power supply or an external 24 V supply at the base controller, and the reading meets it, so the power check passes.
- Read the sketch. Setup ends with
while (!Serial){}. Earlier bench runs always had the monitor open, so the line never blocked there. On the wall, with no USB connection, the CPU holds at that line, the link never opens, and the panel reports P001. - Fix and retest. With the wait line removed, reprogrammed and power-cycled as described in the first check, the panel reaches its runtime screen within 60 seconds and the link comes up on its own; had it not, one reset press after the screen was up would re-run the sketch.
- Result. The timeout was a start-up dependency in the code, not the network. One line removed, one measurement confirmed.
The decision
Recommendation: Remove the serial monitor wait from the sketch and confirm the supply reading at the base controller before you replace any cable or switch. Power both units together, and if the link is slow to come up, press reset once after the panel shows its runtime screen. Update the controller library and the IDE to the current releases while the USB cable is in; the case here ran library version 1.0.4 and IDE version 1.8.19, and updating alone left the P001 error in place. If the link LEDs are lit, the meter reads a healthy voltage at the controller terminals and P001 still appears at every boot, send the sketch and the panel project to the vendor's support desk, because the start-up code is then the only suspect left.
When the cell also needs a notice board
The HMI link and a shop-floor sign are two different jobs. The HMI shows live machine values from the controller; a sign shows shift messages, targets and schedules from its own offline playlist. If the cell needs that second screen, we build shop-floor displays with offline playback, and the display range is where the sizes are compared. A sign is the wrong tool for live machine values, and an HMI is the wrong tool for a message board.
Questions
Can the panel and the controller share one 24 VDC supply?
Yes. The documented requirement is a P1000 Series power supply or an external 24 V supply present at the base controller, and one feed can carry both devices when its current rating covers their combined draw plus inrush. The setup in this article ran both units from one supply that measured +24.0 VDC at the terminals. If the voltage sags when the panel's screen brightens or the controller polls, split the feeds and size each for its own inrush.
Is a faulty Ethernet cable behind a P001 code?
The code reports that the panel's PLC link never came up, and a cable fault usually announces itself with dark link LEDs at the controller and at the switch. When the LEDs are lit and the code still appears at every boot, the cause sits on the controller side, in the start-up code or in its power. Test the cable last, by watching both LED pairs come up as the units power on.
What do two quick presses of the reset button do?
They put the CPU into bootloader mode, where it waits for a download and runs no sketch, so a link test taken mid-bootloader shows a dead connection with no code on the panel. If a boot-order test lands there by accident, one further press resets code execution and the CPU runs the sketch again. The single press is the one to use when re-running the sketch against a panel that is already up.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.