S7-1500 Web Server Adding the Diagnostic Buffer to a User Web

Overview

The SIMATIC S7-1500 web server exposes a fully functional diagnostic surface that mirrors the entries stored in the CPU's internal diagnostic buffer. Engineers typically wire custom HTML dashboards to visualize live tag states for a machine such as a conveyor, but the CPU's diagnostic buffer remains one of the most valuable troubleshooting resources and is normally reserved to the standard Siemens web page reached at https://<CPU-IP>/diagbuffer. Embedding the same diagnostic buffer into a user-defined web page is a documented, supported capability: it uses the S7-1500 user-defined web pages mechanism together with the JavaScript framework file S7_framework.js shipped with the TIA Portal installation.

The CPU's diagnostic buffer records every diagnostic event issued by the operating system, by the user program, by PROFINET, and by I/O modules. Each entry carries a timestamp, a category (information, warning, error), a unique event identifier, and a localized description. On a S7-1500 CPU the buffer is implemented as a ring buffer and typically retains 3200 entries (firmware dependent). Making this buffer available on the same page that already displays live variables shortens troubleshooting time significantly because the operator no longer has to switch contexts.

This article walks through the complete procedure: TIA Portal configuration of the web server, creation of the user-defined web page fragment, integration of S7_framework.js, invocation of the diagnostic-buffer API, and the access-rights settings required to expose the buffer through the custom page.

Prerequisites

Reference the official Siemens entry point for the S7-1500 user-defined web pages application example at SIMATIC S7-1500 / ET 200SP Webserver Application Examples. This single support entry contains the downloadable archive with HTML, CSS, JavaScript samples and the live S7_framework.js reference that the diagnostic buffer extension is built on.

How the Standard Diagnostic Buffer Page Is Built

The standard diagnostic buffer web page served by the CPU at https://<CPU-IP>/diagbuffer is itself generated server-side. The CPU runs a CGI-style endpoint that streams the buffer as a JSON-like structure. The web page then formats each entry into a table row containing:

• Sequence number (1 = newest)
• UTC timestamp in yyyy-mm-dd hh:mm:ss.sss form
• Event category (icon + text: Information, Warning, Error)
• Event ID (for example 0x0001, 0x1151, 0x39B1)
• Event description (multi-line, localized)
• Source (module / OB / user program)

When you create a user-defined web page, the same endpoint is available to the browser through the JavaScript framework. The framework's diagnostic buffer functions perform a request to the internal path /diagbuffer and convert the response into a JavaScript array of objects that can be iterated and rendered on a custom table.

TIA Portal Configuration of the Web Server

1. Open the project in TIA Portal and select the S7-1500 CPU in the project tree.
2. Navigate to Properties > Web server (Webserver).
3. Enable Activate web server on this module (Aktivieren Sie den Webserver auf diesem Baugruppen).
4. Decide on HTTP (port 80) and/or HTTPS (port 443). For production machinery, HTTPS is strongly recommended so that diagnostic data is encrypted on the wire.
5. Open User management (Benutzerverwaltung) and add at least one user. The user role must include the right Read diagnostic buffer (Diagnosepuffer lesen). The "Administrator" role grants this right by default; the "Viewer" or read-only role can also be granted the right explicitly.
6. If your project is at least at firmware V2.6, enable the new User-defined web pages directory and add the path under Web server > User-defined pages. TIA Portal stores a default fragment directory you can extend.
7. Compile the hardware configuration and download to the CPU.

Locating and Shipping S7_framework.js

The framework file is delivered with the Siemens support entry referenced above. Inside the downloadable ZIP archive you will find a file named S7_framework.js (and often S7_framework.css plus sample HTML). Copy S7_framework.js into the user-defined web page directory in your TIA Portal project, typically:

Keep the file naming identical to S7_framework.js because the framework is loaded by the CPU's web server when the custom page requests it. The same script is automatically injected by the standard pages, but in a user-defined page you must reference it explicitly in your HTML:

Calling the Diagnostic Buffer API from JavaScript

The S7_framework.js library exposes a high-level helper that wraps the internal HTTP request and returns an array of buffer entries. The exact public method is documented inside the framework file and is typically called getDiagBuffer or referenced through the S7WebAppFramework.DiagBuffer namespace in newer framework revisions.

A working skeleton for the user page looks like this:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Conveyor HMI</title>
  <link rel="stylesheet" href="S7_framework.css">
  <script type="text/javascript" src="S7_framework.js"></script>
  <style>/* page-specific styles */</style>
</head>
<body>
  <header><h1>Conveyor Status</h1></header>
  <section id="live">Live tags go here</section>

  <section id="diag">
    <h2>CPU Diagnostic Buffer</h2>
    <table id="diagTable" border="1">
      <thead>
        <tr><th>#</th><th>Time</th><th>Category</th><th>Event ID</th><th>Description</th></tr>
      </thead>
      <tbody></tbody>
    </table>
    <button onclick="refreshDiag()">Refresh</button>
  </section>

  <script type="text/javascript">
    // Buffer cache
    var lastDiag = [];

    function refreshDiag() {
      if (typeof S7WebAppFramework === "undefined" ||
          typeof S7WebAppFramework.getDiagBuffer !== "function") {
        console.warn("S7_framework.js not loaded or getDiagBuffer missing");
        return;
      }
      S7WebAppFramework.getDiagBuffer(0, 100, function(entries) {
        lastDiag = entries || [];
        renderDiag(lastDiag);
      });
    }

    function renderDiag(entries) {
      var tbody = document.querySelector("#diagTable tbody");
      tbody.innerHTML = "";
      for (var i = 0; i < entries.length; i++) {
        var e = entries[i];
        var tr = document.createElement("tr");
        tr.innerHTML = "<td>" + e.Number +
                       "</td><td>" + e.TimeStampString +
                       "</td><td>" + e.Category +
                       "</td><td>0x" + Number(e.EventID).toString(16).toUpperCase() +
                       "</td><td>" + e.Description + "</td>";
        tbody.appendChild(tr);
      }
    }

    // Auto refresh every 5 s
    setInterval(refreshDiag, 5000);
    refreshDiag();
  </script>
</body>
</html>

The function call getDiagBuffer(startIndex, count, callback) requests up to count entries starting at startIndex (0 = most recent). Newer framework versions support a synchronous variant getDiagBufferSync() that returns the array directly. Always check the framework version you have: open S7_framework.js in a text editor and search for "DiagBuffer" to confirm the method names available in your build.

Verifying the Page from a Browser

1. Download the project to the CPU and confirm the user-defined web page is reachable at https://<CPU-IP>/<your-page>.html.
2. Open the page in a browser. The web server will respond with an authentication dialog because the page is in the protected area.
3. Log in with a user account that holds the Read diagnostic buffer right. A read-only user with that right is sufficient.
4. Watch the browser network tab: the first GET of your page is followed by an XHR to an internal path similar to /awp/DiagBuffer/?start=0&count=100. A HTTP 200 response means the CPU accepted the request and returned JSON. A HTTP 401 means the authenticated user lacks the diagnostic buffer right.
5. The table populates within a few hundred milliseconds even on a fully populated buffer.

Access-Rights and Security Considerations

Displaying the diagnostic buffer on a user-defined page brings the same security model that the standard diagnostic page uses. Review the following before going into production:

For additional guidance on displaying system diagnostics through the web server of the ET 200 family, the same concepts apply: refer to Diagnostics information using the web server in the TIA Portal documentation.

Error Handling and Troubleshooting Matrix

Performance and Polling Cadence

Every call to getDiagBuffer() performs an authenticated HTTP request and JSON parsing. The CPU can answer hundreds per second, but the web server was not designed for high-rate polling. Field-tested values:

• 2 to 5 second refresh cadence: smooth, no measurable CPU load.
• 1 second refresh: works on a S7-1515 / S7-1516, may show delays on S7-1511 or S7-1511C.
• <500 ms refresh: not recommended. Use PROFINET or OPC UA for high-speed diagnostics.

If you need sub-second diagnostics, do not poll the diagnostic buffer at high rate. Instead, push critical events from the user program into a tag array that the custom web page reads in a single, lightweight call. Use the diagnostic buffer for the human-readable history, and use tag-based alarms for the real-time portion of the HMI.

Localizing the Event Description

The CPU stores diagnostic events with internal event IDs and a language-neutral description. The standard pages translate the description based on the browser language. The framework returns the raw text. To localize on a user page, you can either:

1. Set the HTML lang attribute to the desired language and let the framework translate automatically when the framework's localization is loaded.
2. Maintain a lookup table in your JavaScript for the event IDs that you care about most (for example, 0x1151 = "STOP triggered by user").

The lookup-table approach is preferred for OEM machinery where the same diagnostic page is shipped worldwide and the page text must be controlled, not delegated to the browser locale.

Exporting the Buffer from the Custom Page

Because the framework already retrieves the buffer into a JavaScript array, exporting it as CSV requires a few lines of code:

function exportDiagCSV() {
  var rows = ["Number;Time;Category;EventID;Description"];
  for (var i = 0; i < lastDiag.length; i++) {
    var e = lastDiag[i];
    rows.push([e.Number, e.TimeStampString, e.Category,
               "0x" + Number(e.EventID).toString(16).toUpperCase(),
               e.Description].join(";"));
  }
  var blob = new Blob([rows.join("\n")], { type: "text/csv" });
  var url = URL.createObjectURL(blob);
  var a = document.createElement("a");
  a.href = url;
  a.download = "diagbuffer.csv";
  a.click();
  URL.revokeObjectURL(url);
}

Wire the function to a button on your user page so the operator can save a snapshot before sending it to engineering support.

Relationship to TIA Portal Diagnostics

The same data shown by your custom web page is also displayed in the TIA Portal online view under Online & diagnostics > Diagnostics buffer. For an in-depth description of the buffer structure, the event categories, and the meaning of each event ID, consult the TIA Portal function manual CPU diagnostics buffer. The web-server representation is a strict subset of the TIA Portal representation: every entry visible in TIA Portal is also visible on the web page, but the web page does not allow navigation into the call stack of a user-defined OB.

Verification Checklist

• Web server is enabled and the page is reachable over HTTPS.
• User-defined web pages are enabled in the CPU properties and the directory contains S7_framework.js and the new HTML file.
• The logged-in user has the Read diagnostic buffer right.
• Browser network tab shows a 200 response on the internal /awp/DiagBuffer/... request.
• Table renders at least one entry from the buffer (for example the latest OB100 startup entry).
• No JavaScript errors in the console; S7WebAppFramework is defined as a global object.
• The CSV export button downloads a syntactically valid file.