Diagnose PCS 7 V8.1 System Alarms That Remain in C-Coming State

Do not delete or force-reset a PCS 7 system alarm solely because its date appears as a dash and its status is C-coming. First identify the complete message number, text, source and acknowledgment requirement; the C state indicates an incoming event, but the report does not include enough information to determine whether the cause is still active or what generated it. Because the alarms appear on the redundant OS servers and client, check the alarm origin and system diagnostics before choosing a supported acknowledgment action.

What the Report Establishes

The stated architecture is PCS 7 V8.1, a redundant AS 417H, redundant OS servers and an OS client. Some system alarms appear on both server and client with a dash in the date field and status C-coming; the exact alarm text, message number, source and attachment are unavailable. This is insufficient to identify whether the message is an AS fault, OS/system message, unacknowledged process event, or a display/archive issue. The forum reply raises “PLC fault synchronous” and “PLC fault asynchronous” as possibilities, but the source does not confirm those are the actual messages.

Interpret the Alarm State Before Acting

In the PCS 7/WinCC message model, C means the message has come in. A message state combines the source condition and acknowledgment state. Whether an operator can acknowledge it depends on its configured message class/type; some message types do not require acknowledgment. A dash in a displayed date field is not enough by itself to prove that the alarm is false, stale or safe to remove. Use the actual message properties and list column configuration to establish which timestamp is absent and what the selected view displays.

Identify the Exact Message

Open the same alarm in a message list on the OS server and client. Capture the full text, message number, message class/type, source/tag or system component, state and every available time/date field.
Determine whether the alarm is a process-generated message, an AS system fault, a WinCC/OS system message or another PCS 7 component message. Check the message list's configured columns and message detail/loop-in information rather than relying on the abbreviated state alone.
Confirm whether the message is configured to require acknowledgment. If it is not acknowledgeable by design, repeatedly pressing acknowledge or trying to delete the row is not a correction.
Compare the alarm across both redundant OS servers and the client, and check which OS server is master/standby and whether redundancy synchronization reports faults. Since the same message is visible at multiple stations, begin by locating its shared source rather than clearing the display on one client.

If the Text Is “PLC Fault Synchronous” or “PLC Fault Asynchronous”

The opened Siemens PCS 7 Tips and Tricks manual lists possible synchronous AS faults as OB121 programming errors and OB122 I/O access errors. It lists asynchronous cases as OB80 time errors, OB81 power-supply errors, OB82 diagnostic interrupts, OB83 insert/remove events, OB84 CPU hardware errors, OB85 program runtime errors, OB86 rack failures and OB87 communication errors. These mappings apply only if the message text is the corresponding PLC-fault message; do not infer them from C-coming alone.

For a confirmed PLC-fault message, Siemens' diagnostic guidance is to read the CPU diagnostic buffer and evaluate the local data of the relevant fault OB. With an S7-417H, use the project's approved diagnostics procedure on the appropriate CPU and correlate the diagnostic event with the alarm's message number and time. Resolve the underlying fault before acknowledging an acknowledgeable alarm.

Acknowledge, Reset or Remove

Acknowledgment records an operator response; it does not clear an active source condition. If the message is acknowledgeable and its source is no longer active, use the supported PCS 7 message-list acknowledgment action authorized for that message. If the condition is still active, investigate and correct the source first. If the message class does not support acknowledgment, identify the message type and follow its version-specific handling. No evidence in this case establishes a generic runtime command that safely deletes these messages without a download. Do not edit WinCC/SQL message databases or delete alarm rows manually.

Expected Results and Verification

After the source condition is corrected, verify that the message transitions out of the incoming state according to its configured behavior; acknowledge it only if required. Confirm the resulting state and any acknowledgment time on the server and client, and check that the redundant OS pair remains synchronized. For an AS fault, confirm that the corresponding diagnostic-buffer event is no longer recurring. A message disappearing from one list or one station does not prove the underlying fault is resolved.

Verification

Record the complete message details before making changes. After correction and any supported acknowledgment, compare the message state on both redundant servers and the client, check redundancy status, and verify the relevant AS diagnostic buffer if the source is a PLC fault. Retain the alarm record for incident traceability. The source provides no post-correction result, exact alarm identifiers or evidence that a no-download clearing method applies.

Limitations and Operational Precautions

The screenshot and complete message text are missing, so no exact reset or deletion procedure can be verified. The Siemens PCS 7 Tips and Tricks reference is an older S7-400 diagnostic document and is used only for its stated PLC-fault categories and diagnostic-buffer guidance; it does not establish a PCS 7 V8.1 method for deleting this specific message. Later PCS 7 documentation describes message states and acknowledgment classes, but compatibility of its user-interface details with V8.1 should be confirmed. Do not download a project, delete database entries or restart both redundant servers simply to clear an unexplained alarm. Such actions can affect availability and remove useful evidence without correcting the originating condition.

Engineer FAQ

What does C-coming tell me? It identifies an incoming message state. It does not reveal the cause, acknowledgment requirement or whether the displayed alarm is safe to remove.

Do dashes in the date field mean the alarm is false? No. The report does not identify which date field is shown or why it is blank; inspect the complete message details and display configuration.

Can I acknowledge every PCS 7 system alarm? Not necessarily. Acknowledgment behavior depends on the message class/type and whether acknowledgment is configured or required.

What should I check for “PLC fault synchronous”? Siemens lists OB121 programming errors and OB122 I/O access errors as synchronous AS faults; inspect the CPU diagnostic buffer and the applicable fault OB data.

What should I check for “PLC fault asynchronous”? The Siemens reference lists OB80 through OB87 categories, including time, diagnostic, hardware and communication errors. Use the exact CPU diagnostic event to determine which applies.

Technical References

Siemens, Process Control System PCS 7, Tips and Tricks, A5E00080064-01, §1.1.5 “WinCC messages: PLC fault synchronous and PLC fault asynchronous,” pp. 1-3–1-4; lists the synchronous/asynchronous fault OB categories and recommends reading the CPU diagnostic buffer and evaluating fault-OB local data: https://cache.industry.siemens.com/dl/files/410/7214410/att_50302/v1/S7Prax_e.pdf
Siemens, PCS 7 OS Process Control, Operating Instructions, 02/2021, A5E50314218-AA, §9.2 “Structure and States of Messages”; later-version explanation of incoming/outgoing and acknowledgment state semantics. Siemens PDF could not be opened during this research session: https://support.industry.siemens.com/cs/attachments/109794375/ps7osp_b_en-US.pdf
Siemens, PCS 7 OS Process Control, Operating Instructions (PCS 7 V9.0), §3.8, describes the runtime acknowledge-message function. This is a later release than the reported V8.1 system; verify the exact behavior in V8.1: https://support.industry.siemens.com/cs/attachments/109746535/ps7osp_b_en-US.pdf

Diagnose PCS 7 V8.1 System Alarms That Remain in C-Coming State