MP370 AlarmS Error 1610613287: Resolving Invalid Message Class 0

1. Problem Description

The Mobile Panel MP370 (and related MP170/MP270/MP370 variants) reports the following plausibility error when an ES2-compiled WinCC Flexible project is transferred to the runtime device:

INTERNAL ERROR
Detail: Plausibility: the alarm-s message nr. 1610613287 has an invalid message class nr. 0 - type d'objet : MESSAGE_ALARMS_MESSAGE

The error halts project download, the panel remains in transfer mode, and the previously active runtime is not overwritten. The string MESSAGE_ALARMS_MESSAGE indicates the failing object is an AlarmS record (the S7-style "alarm with acknowledgment" pushed from the AS to the HMI over S7 communication, not the cyclically polled WinCC Flexible message system). The numeric identifier 1610613287 is the internal WinCC Flexible instance handle for the message; it is generated at compile time and is not a STEP7 DB index. The message class field being set to 0 is the root condition that causes the runtime plausibility check inside the MP370 firmware to reject the configuration.

2. Affected Platforms and Versions

The same error string can be observed on a TP270, OP270, or PC Runtime 2008 panel when the same AlarmS configuration is reused. The instance number in the error will differ; the class-0 invalidity is the common factor.

3. AlarmS Message Architecture

AlarmS messages in the SIMATIC environment are not configured in WinCC Flexible; they are declared and instantiated in STEP7 (or in the S7 distributed safety / F-CPU logic), and then subscribed in WinCC Flexible. The runtime receives them as pushed telegrams over the S7 connection — there is no polling. The standard S7 message types are:

Each AlarmS record carries an EV_ID (event ID), a message class, a message number, and up to ten associated values (SFB 35 / ALARM_8P). The message class is a 16-bit integer that WinCC Flexible reads from the STEP7 symbol table or from the SFB 31 / SFB 33 instance DB and binds to a displayable class (e.g., "Errors", "Warnings", "Information"). When the binding fails, WinCC Flexible writes the placeholder class 0 into the compiled project XML, and the panel firmware refuses the record on transfer because class 0 is reserved for "undefined / uninitialized".

4. Root Cause Analysis

Four conditions, alone or in combination, produce the "invalid message class nr. 0" plausibility fault:

1. Orphaned AlarmS record in the WinCC Flexible project. The STEP7 source DB for the AlarmS was renamed, deleted, or had its UDT changed, but the alarm subscriber in WinCC Flexible still points at the old instance. WinCC Flexible cannot resolve the class, defaults to 0, and the panel rejects the record.
2. STEP7 symbol table mismatch. The AlarmS is generated in STEP7, but the symbol for the EV_ID or class is not exported to the S7 project that WinCC Flexible integrates (e.g., the HMI connection is using a different S7 program object than the one containing the SFB calls).
3. Delta-download residue. WinCC Flexible's delta transfer only sends the modified objects. If the AlarmS record was changed (text, class, ID), the previous binary is left in the panel's flash until a full rebuild all + transfer cycle. The panel sees two records with the same EV_ID and accepts the older one with class 0.
4. Communication-target swap. The MP370 is connected to a different PLC than the one referenced by the integrated S7 project (different IP / MPI address, different rack/slot). WinCC Flexible still resolves the class from the offline project, but the runtime cannot verify the binding and reports the placeholder as invalid on next power-up.

The plausibility check itself runs on the MP370 during the init_pass phase of the bootloader, before the WinCC Flexible image is installed. The check is implemented in the runtime object MESSAGE_ALARMS_MESSAGE (object type 0x0B) and is logged to the panel's SystemLogs\Plausib.log file on the CF/PC card.

5. Diagnostic Procedure

Before applying the fix, capture the following data so the root cause can be confirmed:

1. On the MP370, open the Control Panel (on MP370: Start → Settings → Control Panel, or via the Lo soft key on the OP/MP transfer screen). Note the firmware version under OP Properties → Version and the active project name.
2. Enable verbose transfer logging: in WinCC Flexible ES, Project → Transfer → Settings → Enable trace. Reproduce the transfer; the trace file %TEMP%\TF_MP370_*.log lists the object numbers that were sent. Search for MESSAGE_ALARMS_MESSAGE.
3. Open the WinCC Flexible project and select Project → STEP7 Integration → Reconnect. Confirm that the correct S7 program is bound. A warning such as "no symbols updated" confirms cause 1 or 2 above.
4. On STEP7, open the symbol table containing the AlarmS. The class identifier is the MSGCLASS parameter of SFB 31 / SFB 33 / SFB 35. Verify that it is bound to a known message class (1 – 16 are user classes; 17+ are reserved) and that the corresponding data block is not write-protected.
5. Compare the EV_ID values in the STEP7 symbol table with the AlarmS records in WinCC Flexible (alarm editor → right-click → "Properties" → "Source"). Mismatched EV_IDs indicate a stale subscription.

6. Step-by-Step Resolution

The fix that resolves the error in the majority of reported cases is to force a full re-bind of the AlarmS records. The procedure is described in Siemens FAQ entry 24013249, "AlarmS Messages in WinCC flexible".

1. In the WinCC Flexible project, open Alarms → AlarmS. The list of subscribed AlarmS messages is displayed. If the editor is greyed out, the panel was created against a target that does not support AlarmS (for example, the OP73 — these support only the cycle-polled Bit message system).
2. Identify the AlarmS record whose class is shown as 0 or as <undefined>. The instance number in the error string (1610613287) can be cross-referenced against the HMI-tag list: the matching entry has the form ALARMS_xxxxxxxx where xxxxxxxx is a hex representation of the lower 32 bits of the instance number. For 1610613287, the lower 32 bits are 1610613287 = 0x60000227, so look for tag ALARMS_60000227 in the tag editor.
3. Right-click the alarm → Deactivate. Compile and check whether the error message number changes. If it does, the identified record is the source. If the error persists, repeat the deactivation on the next suspect record until the error number changes; the last deactivated record is the corrupted one.
4. Reactivate the record (right-click → Activate). Confirm that the message class field now displays a value between 1 and 16 (or the expected class number).
5. If the class field is empty after reactivation, the STEP7 symbol for the message class is not being resolved. Switch to the STEP7 side, open the symbol table, and ensure that the data block / UDT field used as the MSGCLASS source has its symbol checkbox enabled and is marked as HMI-visible.
6. Now force a full rebuild: Project → Compiler → Rebuild All (German: Projekt → Compiler → Alles neu erzeugen). This recompiles every object in the project, including the offline AlarmS binding, and regenerates the .fwx image. Rebuild All takes longer than an incremental build but is required to clear delta-transfer residue.
7. On the MP370, perform a controlled transfer: in WinCC Flexible, Transfer → Transfer to target device. The transfer settings dialog should show the correct panel type and connection. Click Transfer; the panel reboots and the new image is written to flash.

If the error persists after a single rebuild, repeat the cycle a second time. The first cycle erases the corrupted object; the second cycle re-creates it with a correct class binding.

7. Alternative Recovery Paths

8. Communication and Acknowledgment Considerations

AlarmS messages are a pushed protocol; the MP370 does not poll the PLC. Each AlarmS frame contains:

• Timestamp generated by the CPU (10 ms resolution on S7-300, 1 ms on S7-400) — not by the panel.
• EV_ID (16-bit) — identifies the message source.
• Message class (16-bit) — bound to the WinCC Flexible class.
• Associated values (up to 10 × 32-bit) — supplied by the SFB call parameters.
• State flags (came, went, acknowledged, locked).

If the connection between the MP370 and the PLC is lost, AlarmS messages are buffered in the PLC's S7 communication resources. S7-300 supports roughly 1,000 pending AlarmS frames; S7-400 supports several thousand, depending on the configured message queue size (HW Config → CPU Properties → Communication → Message Queue). When communication is restored, the panel receives the buffered burst. A correctly functioning message class is essential because the panel's alarm log uses the class to filter, route, and archive. A class-0 record causes the log writer to discard the frame silently, which can mask real process events.

9. Verification and Commissioning

After the fix, run a structured verification:

1. Trigger the AlarmS in the PLC. The simplest test is to force a SFB 31 instance's EN input from a STEP7 VAT table or from the test mode in the standard library FB_SEND_ALARM_S. Confirm that the message appears on the panel's alarm line within 1 – 2 seconds.
2. Acknowledge the alarm on the panel by pressing the Ack button on the alarm view. Verify that the ACK output of the corresponding SFB 31 instance is set in the PLC (monitor the instance DB in STEP7 online).
3. Cycle power on the panel. The acknowledged alarms should remain in the "history" view, and the active alarms list should be empty.
4. Disconnect the panel's cable to the PLC for 30 seconds, reconnect, and trigger a new alarm. The panel should display the new alarm and any alarms that occurred during the disconnect should be reported with their original PLC-side timestamps (not the reconnect time).
5. Export the runtime log: Start → Programs → File Manager → Storage Card → Logs. The Plausib.log should not contain the "invalid message class" line after the fix.

10. Preventive Measures

• Use a single source of truth for the S7 program. Always connect WinCC Flexible to the same S7 program that is downloaded to the CPU. Avoid having two parallel S7 program objects (one for PLC development, one for HMI development) because they will diverge over time and AlarmS class bindings will silently desynchronize.
• Build with "Rebuild All" once per week on a maintenance engineer workstation. This catches drift between the STEP7 symbol table and the HMI project before the next on-site transfer.
• Disable delta transfer for production units. The time saved on a few MB of project data is not worth the risk of stale records. Use delta transfer only for engineering / FAT panels that are wiped between runs.
• Tag the AlarmS class with a project-internal naming convention, e.g., always use class 4 ("Process warnings") for operator-informational events and class 1 ("Process errors, must be acknowledged") for events that need a process response. Auditing the class list before a transfer catches the "class 0 = uninitialized" problem at compile time.
• Apply WinCC Flexible SP and hotfix updates. The plausibility check was tightened in 2008 SP3 to reject class 0 explicitly with the wording reproduced in the runtime error. Earlier versions (2004 SP1) silently accepted class 0 and only failed at runtime. Keeping the ES up to date ensures the failing record is identified at compile time rather than on the shop floor.

11. Related Errors

FAQ