Restoring a Lost CNC PLC Program via PCIN Serial Load

Problem Details

A machine control powers up and posts persistent fault messages instead of reaching a usable operating state. Diagnosis on the control side points to one condition: the PLC program stored in the control is corrupted or absent. Without a valid PLC user program, the CNC/NC kernel cannot exchange interface signals with the machine (mode selection, feed enable, drive enables, EMERGENCY STOP acknowledgement chain), so the control either stops in a fault state or cycles through startup messages.

Typical field symptoms of a missing/destroyed PLC program:

• Control boots but never releases channel status to RESET/READY.
• Machine operating panel keys have no effect; no axis enables, no spindle enable.
• Repeating startup or checksum-class messages that cannot be acknowledged by RESET.
• PLC status/diagnostics screen shows no user program, an empty program size, or a stop condition.

Root Cause

The PLC user program lives in battery-backed or non-volatile memory in the CNC. It is lost or invalidated by a small set of causes:

Distinguish these two before you touch anything: a program that is gone restores from an archive; memory that will not hold a program needs hardware. The test is simple — reload, power cycle twice, and confirm the program is still present.

Solution: Load the Commissioning Archive with PCIN

PCIN is the DOS-based serial transfer utility used to send and receive data files to and from the control over an RS-232 (V.24) link. The commissioning file (series start-up / start-up archive) is the complete machine image: PLC program, NC and drive machine data, tool and compensation data, and optionally NC part programs, packaged as one punch-tape-format stream.

Prerequisites

1. A verified commissioning archive for this exact machine and serial number. Machine data are machine-specific; a sister-machine archive will load, but axis compensation, encoder offsets, and drive data will be wrong.
2. A PC with a real RS-232 port, or a tested USB-to-serial adapter using an FTDI-class chipset. Cheap adapters drop characters at higher baud rates and produce truncated archives.
3. A correct null-modem cable with hardware handshake lines (RTS/CTS) wired through. Handshake is what prevents buffer overrun on the control side.
4. A fresh backup battery installed, if the failure is battery-related.
5. Machine in a safe state: EMERGENCY STOP pressed, main drive power off if the control permits it, no personnel in the working area.

Procedure

1. Take a receive-side archive first if the control still responds. Even a partial upload preserves tool data and compensation values you may not have elsewhere.
2. Match the interface parameters on both sides. Set the control's V.24 interface and PCIN to identical values. Typical serial settings for this class of transfer:
   9600 or 19200 baud, 7 or 8 data bits, even/no parity, 1 or 2 stop bits, RTS/CTS handshake, XON/XOFF as configured by the control
   Read the actual values from the control's interface parameter screen; do not guess. Mismatched parity is the most common cause of a transfer that starts and then aborts.
3. Select the transfer direction in PCIN as "Data Out" (PC to control) and point it at the commissioning file.
4. Arm the control to read in the series start-up file, then start the send from PCIN.
5. Expect multiple automatic restarts. While the archive is read in, the control reboots several times as machine data blocks that require a restart become active. This is normal behavior, not a failure. Do not interrupt power, do not cancel the transfer, and do not press RESET during these restarts.
6. Let the transfer run to completion and wait for the control to settle at the end of the last restart.
7. Power cycle once manually after completion so all machine data and the PLC program are activated from non-volatile memory.

Verification

1. PLC present and running: open the PLC diagnostics/status screen and confirm a non-zero program size and RUN state with no stop condition.
2. Interface signals live: toggle a hardware input (a limit switch or a panel key) and watch the corresponding PLC input bit change in the status display. This proves both I/O bus and program execution.
3. Persistence: power the control down for at least 5 minutes, then back up. If the program is gone again, the fault is memory hardware or battery, not data.
4. Alarm list clean: the startup fault messages must clear after RESET. Any remaining alarm now describes a real machine condition, not a missing program.
5. Axis referencing: reference each axis and compare the displayed machine position at a known fixture or reference block against the pre-fault record.
6. Drive data: confirm drive machine data / motor selection matches the nameplate on each motor before the first jog. Run each axis first at the lowest override.

Reading Fault Messages Correctly Before You Blame the PLC

Not every fault flood on a machine originates in the control's PLC. Separate the alarm sources by code namespace before starting a restore, because a drive-side trip looks nothing like a lost PLC program and needs no archive load.

The Siemens list manual documents, for every fault and alarm, the cause, the reaction (OFF1/OFF2) and the acknowledgement mode — use it to decide whether a fault self-clears, needs a manual acknowledge, or requires a power cycle. See the SINAMICS G120C List Manual (LH13) and the PowerFlex 525 product information.

Judging Whether the Message Flood Itself Is the Problem

When a control comes back after a restore, operators often report "too many messages." Use published alarm-management benchmarks rather than opinion to decide whether the alarm configuration needs rationalization:

ANSI/ISA-18.2 (2009) is consistent with EEMUA 191 and forms the basis of IEC 62682. Reference: alarm management standards and guidelines overview. If a restored machine still exceeds these rates in steady state, the problem is alarm design — duplicated, chattering, or non-actionable messages — not the PLC restore.

Preventive Measures

• Take a commissioning archive after every commissioning, machine data change, and PLC modification. Store two copies off-machine, one of them off-site.
• Record the serial interface parameters used for a successful transfer directly in the machine file. Recovering those settings under pressure wastes hours.
• Replace backup batteries on a scheduled interval with the control powered on, so memory retention is never dependent on the battery during the swap.
• Label each archive with machine serial number, control software version, and date. An unlabeled archive is a liability during a breakdown.
• Keep one known-good RS-232 cable and one known-good serial adapter in the service kit, tested against a live control, not just a loopback plug.