Troubleshooting Productivity 3000 Save and Transfer Hangs

Problem Details

A Productivity 3000 system goes online normally and monitors live data, but every operation that serializes the project database hangs indefinitely. The Productivity Suite progress dialog appears and never closes, and the application becomes unresponsive with no cancel path.

Failing operations

• File → Save — "Saving file" task bar runs for many minutes, never completes.
• CPU → Runtime Transfer — progress bar stalls, no timeout.
• CPU → Stop Mode Transfer — identical stall.
• System Report generation — progress bar sits ~20 minutes with no completion.

Operations that still work

• Opening the last-known-good project file from the PC.
• Reading the project back from the CPU (upload).
• Going online and monitoring tags/data view.
• RUN/STOP keyswitch changes on the CPU are honored.
• CPU error log is clean — no fault entries logged.

Root Cause Analysis

Save, Runtime Transfer, Stop Mode Transfer and System Report all walk the same in-memory project database and write it out — to disk, to the CPU, or into the report archive. A hang common to all four, while live monitoring continues, isolates the failure to that database traversal rather than to the transport or the controller's execution engine.

Because both PCs opened project content that originated from the same CPU, a corrupt element carried in that project explains why swapping laptops and software versions changed nothing. The Suite parser reads it back without complaint but stalls when it must write it out.

Recovery Procedure

The goal is to prove whether the CPU can hold and return a known-clean project. Do this on a bench or with the machine safely isolated — the sequence erases the controller's project and stops the process.

1. Capture what you can. Save the uploaded project under a new filename only if Save completes. If Save hangs, copy the last-known-good .adpro file from disk to a backup folder instead. Do not overwrite it.
2. Kill the hung session cleanly. Terminate Productivity Suite from Windows Task Manager, then relaunch. The hung save leaves no valid file — verify the file timestamp and size before trusting it.
3. Erase the controller project. Go online and run CPU → Remove CPU Project. This clears the resident project from the controller.
4. Load a blank project. Create a new empty project matching the hardware (P3-550E plus the installed base/I/O), then perform a Stop Mode Transfer to the CPU.
5. Read it back. Immediately upload from the CPU into a fresh Suite session. If the blank project transfers down and reads back cleanly, the Ethernet path, the CPU project memory and the Suite install are all functional.
6. Reload the original project. Open the last-known-good project file and Stop Mode Transfer it to the CPU. Then attempt Save, Runtime Transfer and System Report in that order.
7. Evaluate. If the hang returns only after the original project is loaded, the defect travels with the project. If the hang returns with the blank project, the CPU hardware is suspect.

If the CPU must come out

Where production cannot wait, pull the suspect CPU, flash a spare P3-550E to the same firmware revision, transfer the last-known-good project and return the machine to service. Bag and tag the suspect unit with the firmware revision, Suite version and a written symptom timeline so AutomationDirect technical support can reproduce the failure. Do not reuse or re-flash the suspect CPU before that evaluation — re-flashing destroys the evidence.

System Report and Support Escalation

The System Report is the artifact AutomationDirect support asks for, and in this failure mode it is exactly what will not generate. Handle that explicitly:

When a report cannot be produced, submit this package to support in its place: CPU part number and firmware revision, Productivity Suite version and build (both PCs), the offending project file, the exact operation names that hang, the observed hang duration, and confirmation of which troubleshooting steps were already eliminated. Open the case through AutomationDirect support.

Verification

Consider the system recovered only when all of the following pass in sequence, without a force-kill:

1. Open the project, make one trivial edit (add a comment to a rung), and Save — completes in seconds, file timestamp and size update on disk.
2. Stop Mode Transfer completes and the CPU accepts the download.
3. Place the CPU in RUN via the keyswitch; confirm scan is running and I/O status is normal.
4. Make a second trivial edit online and execute Runtime Transfer — completes without a stall.
5. Generate a System Report end to end and confirm the output file is written.
6. Upload from the CPU into a clean Suite session and compare against the on-disk project — no unexpected differences.
7. Confirm the CPU error log remains clear after 24 hours of runtime.

Preventive Practice

• Keep dated, versioned copies of every .adpro file outside the working directory. This incident is only recoverable because a clean file existed.
• Generate a System Report on a healthy machine periodically. A baseline report makes it obvious what changed and gives support a comparison point.
• Record CPU firmware revision and Suite version and build number in the project documentation. Two PCs on different Suite builds is a useful test only if you know exactly which builds they were.
• Stage a pre-flashed spare P3-550E for critical machines. Swap time was the difference between an hour of downtime and a shift of it.
• Before large edits, verify Save works on a trivial edit first. Discovering the hang after two hours of logic changes loses the work.

FAQ