HMI firmware update timeout loop: fix PTC-009 and finish the update

What PTC-009 reports

PTC-009 is the panel's Firmware Update Failed error. The maker's own help topic for PTC-009 names the trigger in plain terms: the update software cannot reach the panel, or the panel reports a timeout during the sequence. Both halves sit in the transfer between the programming PC and the panel, so the error names the link as the first suspect and the panel hardware as the second.

On the panel, the update screen reads "Do not remove power to panel during update!" with a count under it, such as "Updating Exec... 53". That screen is the state that matters. The panel is mid-sequence and needs its power, so keep the panel powered until it reports the update failed. Cutting power during a write is what turns a failed transfer into a corrupted panel.

Symptoms and what each one points to

The failure modes around this error separate cleanly. Match yours before touching anything:

• The Updating Exec count climbs, then PTC-009 arrives. The count is an activity indicator with no fixed final value, so a big number means a long attempt, and the attempt still failed. The timeout and the count are separate things.
• PTC-009 returns on every retry of the same PC link. The path is failing: a cable too long, USB voltage from the PC too low, a hub in the path, a panel ground problem, or electrical noise on the link. Correct the path, or change routes.
• The panel ignores the USB stick entirely. A media compatibility problem, separate from the firmware fault: these panels accept a limited set of drives, and a stick a laptop reads without complaint can be invisible to the panel.
• PTC-005 shows instead. The maker files PTC-005 in the communication category for the same update operation, so the link corrections below apply to it too.
• The panel will not start after a reported failure. A corrupted write, which the maker describes as rare. Use the power-cycle and recovery rules further down.

The first item in that list is the one that keeps people on site for hours, so it gets its own section.

Why the climbing count is not progress

The number after Updating Exec counts steps the update sequence has performed. It has no final value to reach, so it works like a spinner: a higher number means the attempt has run longer, and it says nothing about the work left, because no fixed total exists. In the case behind this article the count stood at 53 on the first view, 116 on a later attempt and 588 in the end, and every attempt still ended in PTC-009.

Read the count for exactly one thing: the panel is still executing. Once an attempt ends in PTC-009, that attempt is over, and the conditions that timed it out are unchanged, so an identical retry rolls the same dice again. Waiting for a guessed finishing number is how one failed transfer becomes an hours-long standstill with a machine down.

Correct the USB link before the next attempt

The causes behind a timed-out USB firmware update repeat from shop to shop: a cable too long for a reliable transfer, the PC's USB voltage sagging under load, hubs between the PC and the panel, a panel with a poor ground, and electrical noise picked up on the link. A laptop power supply is a known offender for injecting noise into USB.

Correct all five before the next attempt:

1. Fit a shorter, higher-quality cable.
2. Connect the panel straight to the PC, with every hub out of the path.
3. Move to a second PC if the first keeps failing.
4. Check the panel's ground connection.
5. Move noise sources, and their cables, away from the USB run.

Then attempt the update once. A retry after corrections tests a new path; a retry without corrections repeats a measured failure.

Worked example: two hours of failed retries against a five-minute thumb drive

Inputs, all from the case behind this article:

• Panel and target firmware: a compact HMI panel with no Ethernet port, updating to V2.78.
• Failed attempts over the PC USB link: 3.
• Time spent on those attempts: more than 2 hours, taken as 120 minutes.
• Updating Exec readings: 53, then 116, then 588.
• Update over removable media once the route changed: about 5 minutes.

The rule: when every attempt on a path ends in the same timeout, put a price and a cap on the attempts, and let the cap force the route change that finishes the job.

The arithmetic:

• 120 minutes ÷ 3 attempts = 40 minutes per failed attempt.
• Cap the corrected PC link at 2 attempts: 2 × 40 = 80 minutes before the route change.
• Removable media at about 5 minutes: one failed attempt costs the same as 40 ÷ 5 = 8 completed media updates.
• Under the cap the job takes 80 + 5 = 85 minutes; the retry loop consumed 120 minutes and still had no updated panel.

Result: the cap finishes the update 35 minutes sooner on these numbers, and it finishes the job at all, which the loop never did.

Decision: cap the PC-to-panel link at two corrected attempts. If the second ends in PTC-009 at a similar step, the path is the fault and removable media is the next move. A count above 500 changes none of that.

Load the firmware from removable media

A USB stick or CF card carrying the firmware package ends the loop, because the transfer no longer runs through the marginal PC link. Panels in this family update over Ethernet when they have the port; the panel in the case had none, so the practical routes were removable media and a corrected PC link, and the media route is the one to reach for on any panel without a network jack.

Use the package the panel maker publishes for that panel family at the version the project needs, V2.78 in the case, and prepare the media exactly as that panel's update procedure describes: file names, folder layout and write steps. Insert the media, wait for the panel to recognize it, then start the update and keep power connected throughout.

If the panel ignores the first stick, that is a media problem separate from the timeout: try a drive from the maker's compatibility list. The preparation steps are in prepare an HMI firmware and project update on a USB drive, and which USB drives an HMI panel actually reads covers the picking.

After a reported failure: power cycle and recovery

Once the panel reports the update failed, cycling power is allowed by manufacture date. The guidance for this panel family allows a power cycle after a failed update on units manufactured after December 2007. Read the date from the panel's manufacture label, since an installation date runs later than the build.

If a failed write did corrupt the operating system or firmware, which the maker describes as rare, the Recovery Tool restores the panel; the maker documents it under help topic CM498. Run the recovery exactly as the current documentation prints it, then confirm the panel boots normally before another update attempt.

A panel that boots but will not communicate afterwards is a separate fault: HMI panel will not communicate after a firmware update walks through that one.

Confirm the version, then send the project

Read the firmware version the panel reports once the update completes, and match it to the target before anything else: the project download that started this needed that version in place. Check the HMI firmware revision before a project transfer shows the check. Then rerun the project download over a stable route and confirm the screens behave at the machine before it returns to production.

Recommendation: Give the corrected PC-to-panel USB link two attempts, no more: shorter high-quality cable, no hubs, a second PC, a verified panel ground, and noise sources moved away from the run. If the second attempt ends in PTC-009 again, stop retrying and load the firmware from a USB drive or CF card on the maker's compatibility list; in the case these numbers come from, that route finished the update in about 5 minutes after more than two hours of failed attempts. Keep power connected while any update message is on the panel, and cycle power only after the panel reports the update failed, on units manufactured after December 2007.

Questions