WinCC Alarm Logging Printout: Resolving 32-Page Daily Limitation

Problem Description

When using WinCC (TIA Portal / WinCC Explorer, including the Reports and Alarm Logging editors) to produce a printed archive of alarm messages, many engineers observe that a daily alarm report only ever contains approximately 32 pages, even when far more alarms have been recorded that day. Pages that should contain valid messages are silently truncated at the print spool, leaving operators with an incomplete audit trail. The issue is most often reported on:

• WinCC V7.x Runtime / WinCC Professional (TIA Portal) V13 to V20
• Projects that use the default Alarm Logging Runtime layout with a per-day message sequence selection
• Printers that correctly receive the WinCC job but stop after a fixed number of message frames

The print job completes without an error, the printer's queue is empty, and the report shows the correct time range, but tail-end alarm frames are missing. This behavior is not a printer-driver failure or a Windows spooler issue; it is a documented characteristic of how WinCC's Message Sequence Report composes pages when its configuration is left at the project default.

Symptoms and Field Observations

Symptoms reported in the field are consistent across WinCC versions and printer brands:

• Daily alarm report consistently stops at 32 pages regardless of alarm volume.
• No WinCC system alarm, no error code in WinCC Explorer > Tools > System Information, and no entry in the Windows event log.
• When the same time slice is exported to a CSV via the Alarm Logging editor, the row count matches the database and exceeds the page-equivalent row count on the printed report.
• Modifying the page count or printer driver does not change the cutoff at exactly 32 pages.

Root Cause: Message Sequence Protocol Limits and Layout Defaults

WinCC's Message Sequence Report prints alarm frames in the order they are written to the Alarm Logging database. By default, the system uses an internal buffer size that maps to roughly 32 print pages under standard line-height and column defaults. When you trigger a print job that requests more frames than the buffer can hold, the spooler only outputs the frames already loaded into the buffer at job-start time; the remaining frames remain queued but are dropped when the report job closes. This is the most common cause of the "32-page daily limit" and is independent of physical memory, disk space, or printer capability.

Three configuration decisions directly drive this limit:

1. Layout — the Alarm Message Table sheet you assign to the print job must contain a row height and column count that fills each page with a known frame count. The default project layout is optimized for screen display, not bulk printing.
2. Print job definition — the Reports editor entry for the alarm log must reference a print job (RPTJobPrint target) and a page range that covers the full time slice; if the page range is left at default, the report only commits frames already in the message sequence buffer.
3. Trigger source — manual Print clicks from the Alarm Control may pre-load the buffer; scheduled global-script triggers with a wider time range require an explicit RPTJobPrint call to commit the full sequence to the spooler.

Prerequisites for a Correct Alarm Printout

Before reconfiguring the report, verify the following engineering prerequisites. Most "32-page" issues are resolved by one of these checks, before any code change is needed.

1. WinCC project must be running on the server that owns the Alarm Logging database. Client stations can view alarms but cannot print the full message sequence unless the project is configured with the Server-Prefetch option enabled in the Alarm Logging editor.
2. The printer must be installed on the WinCC server with a known driver. Use the Siemens-tested driver list when possible; generic Windows PCL/PS drivers are valid for text reports but may break column alignment on multi-byte Windows installations.
3. Disk space on the project path must be at least 1 GB free; message sequence exports use the project folder as scratch space during large prints.
4. Global script runtime must be enabled: WinCC Explorer > Computer > Properties > Startup > Global Script Runtime.
5. User rights for the WinCC user must include Configuration > Reports and Operation > Alarm Logging authorization levels.

Reference: Printing Alarms in Runtime (RT Professional) — WinCC (Siemens TIA Portal V20 documentation, TIA Cloud Help).

Solution 1 — Configure the Alarm Message Table Layout for Print

The first and most reliable fix is to assign a print-optimized Alarm Message Table sheet to the report job instead of the default runtime layout.

1. Open WinCC Explorer > Alarm Logging > Reports.
2. Right-click the report you use for daily logs and select Select Layout....
3. Choose the @Alarm Message Table layout, then click Edit.
4. In the layout editor, reduce the row height of each alarm line to 0.4 cm and the column widths to fit the print page width (e.g. 2.5 cm, 2 cm, 2 cm, 8 cm for a 21 cm-wide A4 printable area). This raises the number of frames per page from ~32 to ~55–65 on a default installation.
5. Confirm with OK and save the project.
6. Re-deploy the Runtime and re-trigger the report.

The change applies to all reports that reference this layout, so plan the layout for the highest-volume report and reuse it.

Solution 2 — Use RPTJobPrint from a Cyclic Global Script

When you need to print on a schedule (daily, weekly, monthly), a cyclic action calling RPTJobPrint is the recommended pattern. The function commits the full message sequence buffer to the spooler, bypassing the manual Print dialog that only pre-loads a partial buffer.

Step-by-step configuration

1. In WinCC Explorer, right-click Global Script > C-Actions and select New > Action.
2. Set the trigger to Time > Cyclic. Recommended intervals:
   • Daily archive: 86400000 ms (24 h), aligned to 00:00 server time.
   • Weekly archive: 604800000 ms (7 d).
   • Monthly archive: trigger on the first day of each month using a tag-driven condition instead of pure cyclic.
3. Paste the following C-action body:

// C-Action: Scheduled Alarm Logging Print
// Trigger: cyclic, e.g. 24h for daily archive

#include "apdefap.h"

void OnTimeTrigger(char* lpszPictureName, char* lpszObjectName)
{
    // Print job name as defined in Reports editor
    char* szPrintJob = "AlarmLog_Daily";

    // Print page name (the Alarm Message Table layout assigned to the job)
    char* szPrintPage = "@Alarm Message Table";

    // Issue the print job; RPTJobPrint handles buffer flush to spooler
    RPTJobPrint(szPrintJob, szPrintPage, 0);
}

4. Compile the action. If you see error 0334: 'RPTJobPrint': undeclared identifier, ensure that the project's AP_Functions.h is included in the project include path (Options > Settings > Include).
5. Save and re-deploy the Runtime.

Solution 3 — Output the Message Sequence to a File (Diagnostic + Archival)

If the print path remains unstable — for example, on remote printer servers or in heavily virtualized environments — output the message sequence to a file and print from a host process. This also doubles as a diagnostic: comparing the file's line count with the printed page count immediately proves whether the truncation is happening in WinCC or in the printer driver.

Using GmsgFunction

Reference: Siemens Support Portal entry 15350783 (C-Script example for GmsgFunction — output of message frames to a text file).

// C-Action: Write today's alarm sequence to a daily text file
// Trigger: cyclic, 60 seconds (file is rotated by date at midnight)

#include "apdefap.h"
#include "GlobalDef.h"

void OnCyclicTrigger(char* lpszPictureName, char* lpszObjectName)
{
    char szFileName[256];
    char szDate[32];

    SYSTEMTIME st;
    GetLocalTime(&st);
    sprintf_s(szDate, sizeof(szDate), "%04d%02d%02d", st.wYear, st.wMonth, st.wDay);
    sprintf_s(szFileName, sizeof(szFileName),
              "C:\\WinCC_AlarmArchive\\AlarmLog_%s.txt", szDate);

    // 0x0001 = MSG_TYPE_ALARM, 0x0002 = include acknowledged, 0x0004 = include cleared
    DWORD dwFlags = 0x0001 | 0x0002 | 0x0004;

    GmsgFunction(szFileName, "@Alarm Message Table", 0, 0, 0, 0, dwFlags);
}

1. Create the target folder C:\WinCC_AlarmArchive\ on a drive with sufficient free space; in industrial sites, prefer a non-OS partition to simplify backup.
2. Add the action to the project's Global Script > C-Actions with a 60-second cyclic trigger.
3. After 24 hours, the file AlarmLog_YYYYMMDD.txt will contain the full day of alarms, line by line, with one record per alarm event.

You can then print the file from a Windows scheduled task using notepad /p, or feed it to a third-party reporting tool such as Excel or Power BI for audit-ready output.

Solution 4 — Buffer and Time-Range Tuning

When the 32-page limit persists after the layout change, the message sequence buffer is the next knob to inspect.

1. Open Alarm Logging > Properties > Archive.
2. Set Message sequence buffer from the default 1024 frames to 8192 frames (or higher, sized to your worst-case day).
3. Adjust the Update cycle to 1000 ms so that alarms are flushed from the working buffer to the archive every second instead of every 5 seconds.
4. For long historical windows (e.g. monthly reports), set the Time range of the print job explicitly to From: 00:00:00 of the first day, To: 23:59:59 of the last day. A relative time range like last 30 days can misalign with the buffer flush boundary and re-introduce truncation.

Verification Procedure

After applying any combination of the four solutions above, validate the printout by executing the following sequence. This is the same sequence used during WinCC Factory Acceptance Tests (FAT) for alarm-archiving deliverables.

1. Generate load: using the internal Alarm Simulator (Tools > Alarm Logging > Test) or a script, fire 5,000 alarm frames within 60 seconds. Confirm that the archive row count in the Alarm Logging editor is 5,000.
2. Trigger the report via the global script action; do not use the manual Print button.
3. Count pages in the spooler output. For a daily report on a load of 5,000 alarms, you should now see between 90 and 200 pages (depending on layout), not 32.
4. Cross-check the printed total against GmsgFunction's text file. Both should report the same alarm count for the same time range. A divergence of more than 1% indicates a remaining buffer or layout mismatch.
5. Inspect WinCC system alarms: open WinCC Explorer > Tools > System Information and confirm there are no entries with IDs 1300001 through 1300999 for the test window. These IDs map to Reports-editor failures.
6. Repeat the test on a quiet day (fewer than 50 alarms) to confirm the report still produces a valid 1–2 page output, ruling out an over-sized buffer regression.

Cross-Reference: WinCC Version Notes

Best Practices for Sustainable Alarm Archiving

• Decouple print from primary alarm storage. Treat WinCC's Reports editor as the print front-end and the Archive database as the source of truth. A scheduled GmsgFunction-style dump into a SQL table or a structured file gives you an immutable record that does not depend on the print pipeline.
• Use a dedicated printer. Network printers with PostScript and bidirectional status updates are the most reliable; generic GDI/direct printers tend to drop pages under burst load.
• Trigger the daily report two minutes after midnight, not at 23:59. This guarantees that the To-time range of the report (23:59:59.999) is fully written to the archive and the next day's From boundary does not collide.
• Set the cyclic action's Error handling to Stop on error during commissioning, and to Continue on error for production. This avoids stopping the Runtime on a single failed print, while still surfacing issues during FAT.
• Document the print job name in the project README. Operations staff will need the exact szPrintJob string to re-trigger reports from the WinCC Alarm Control right-click menu.
• Verify against the system's local time zone. GetLocalTime returns the WinCC server's local time, not UTC. If the plant uses a UTC-shifted time zone, align the cyclic trigger to UTC explicitly to avoid day-boundary drift in monthly reports.

Troubleshooting Matrix

Frequently Asked Questions