Resolving P2000 'No External Power' Faults After an Outage

This Productivity2000 (P2000) system ran CPU firmware 1.2.1.15. After a full power outage the CPU came back online, but the P2-16AD-1 analog input module kept reporting "No external power" even though its external supply was live. The only thing that cleared the flag was removing and restoring that module's external power while the CPU was already running. Nobody can hand-cycle modules after an unattended outage at 3 a.m., so the job is to find why the module never re-evaluates its supply on a cold restart.

Skip the quick fixes that only clear it once

Most people try these first. Each one either clears the flag for a single restart or hides the real problem.

Understand why the module holds the missing-supply state

P2000 analog modules take external field power for their analog circuitry. That supply is separate from the logic power the module draws from the base. The module watches the external supply and reports its status to the CPU, and the CPU displays it as "No external power."

The single-module path works correctly. Pull the external supply from one module with the CPU running and the error appears. Reconnect it and the error clears. The manufacturer confirmed this on both a P2-8AD4DA-2 and a P2-16AD-1.

The failure appears only when everything powers up together. At that point the module evaluates its external supply during its own startup and never updates the status afterward. Cycling the external supply later, with the CPU running, gives the module a fresh off-to-on transition to detect. That explains why the manual fix works.

Two things decide whether the module catches the supply at startup:

• Power-up order and rise time. The external field supply and the base/CPU supply may not come up at the same moment. They may be separate supplies, on separate breakers, with different capacitive loads. If the external supply is still ramping when the module initializes, the module can miss it.
• Firmware behavior. The failing system ran CPU firmware 1.2.1.15. The manufacturer could not reproduce the fault on CPU 1.2.2.59 with module firmware 0.11.

Separate a real supply fault from a startup latch

First decide which case you have. Use this table:

Stop here if you find a real supply fault. Fix the wiring or supply and re-test before going further.

Record CPU, GUI, and module firmware before changing anything

Capture the exact versions before you update anything. You need them to compare against a known-good setup, and support needs them to reproduce the fault. The manufacturer's lab ran these comparisons:

1. Read the GUI revision under Help -> About, or from the title bar at the top of the programming software window.
2. Read the CPU firmware from the CPU information or system status in the programming software.
3. Read each analog module's firmware from the hardware configuration or module information view. Do this for every module that latched, not just the first one you noticed.
4. Write down the exact catalog number from the module label. P2-16AD-1 and P2-16AD1 are easy to mix up in notes.
5. Note how the external field supply is wired. Record whether it shares a source with the base power supply, which breaker feeds each, and whether anything switches them.

Restore production tonight by re-sequencing the external supply

This is the temporary restore. It gets the analog inputs valid again. It does not stop the fault from coming back at the next outage.

1. Confirm the CPU is in Run and communicating.
2. Confirm the process is in a state where losing the affected analog signals briefly is safe. Put loops on those inputs into manual first.
3. Open the external supply to the latched module, using its fuse, terminal disconnect, or breaker. Wait until the programming software shows the supply loss.
4. Restore the external supply and confirm the "No external power" status clears.
5. Check that the analog readings match field values before returning loops to auto.
6. Repeat for each latched module.

For unattended restarts until the permanent repair is done, have the panel reproduce the manual fix automatically. Feed the analog modules' external supply through a contact that closes only after the CPU is running. Two ways to do that:

• A time-delay-on relay in the field supply feed. Set its delay longer than your measured CPU boot-to-Run time. Time that boot on this panel with a stopwatch; don't guess.
• A discrete output, driven from logic once the CPU is in Run, that energizes a relay in the field supply feed.

Either option changes panel wiring. Mark it on the drawings as a workaround. Also confirm that anything else on that field supply, such as transmitters or loop power, can tolerate the added delay at startup.

Make the permanent repair with firmware and a system report

The lasting fix is to get the system onto firmware where a full power cycle recovers cleanly. Then prove it on this panel.

1. Download the current CPU firmware and matching programming software from the manufacturer. Read the release notes for anything about module power status or power-up recovery. The lab setups that did not show the fault ran CPU 1.2.2.59, so treat that as the minimum target.
2. Update the GUI to the version that matches the new CPU firmware.
3. Update each analog module's firmware if the software offers a newer version. The lab used module firmware 0.11.
4. Re-download the project and confirm retentive tag settings survived the update.
5. Remove the sequencing workaround. Then run the outage test in the next section without it. If the fault is gone, the workaround can stay out.
6. If the fault persists on current firmware, generate a system report from the programming software. Send it to AutomationDirect technical support along with the module catalog numbers, all firmware versions, and your power supply arrangement, so they can duplicate the setup in their lab.

Prove recovery with repeated full-panel power cycles

One clean restart proves nothing, because the original fault depends on power-up timing. Test the way real outages happen:

1. Kill power at the main panel disconnect, not at individual breakers. This makes the CPU base supply and the field supply drop and return together.
2. Run several full cycles in a row. Include both short interruptions and outages long enough for the supplies to discharge fully.
3. After each restart, check with no hands on the panel:
   • Every analog module shows no external-power fault.
   • Analog values track the field.
   • The CPU is in Run.
4. Verify retentive tags held their values across every cycle. That was the original purpose of the commissioning test, and a firmware update can change retentive settings.
5. Log the firmware versions, number of cycles, and results in the commissioning record. Any module that latches again goes back to support with a fresh system report.

FAQ