Troubleshooting MTP1200 Comfort Panel Table Rendering

The MTP1200 Comfort panel loads the Custom Web Control (CWC) shell in V19 but does not render its table, while the same control renders in the TIA Portal editor, simulation, and the V20 panel runtime. Because filter elements and added text remain visible, restarting the CWC from scratch is not the first corrective action. Isolate table initialization, data delivery, runtime compatibility, and layout in that order.

Failure boundary and decision path

The term CWC shell here means the HTML and JavaScript environment that hosts the control. A visible filter or test string proves that the V19 panel has instantiated that shell. It does not prove that the table constructor completed, that row data arrived in a usable form, or that CSS gave the table a visible area.

Check 1: Table initialization state

Insert temporary visible status text immediately before and after the table constructor. Also catch initialization exceptions and print a short error string inside the CWC. Panel-visible instrumentation matters because a successful simulation does not reproduce a failure that occurs only in the physical panel runtime.

1. Check 1A: expect the pre-constructor marker. If it is absent, execution stops earlier in the script; inspect resource loading and preceding code.
2. Check 1B: expect the post-constructor marker. If the first marker appears but the second does not, the constructor throws an exception or reaches an unsupported API.
3. Check 1C: expect a nonzero row count after initialization. A zero count with a completed constructor moves the investigation to the data path.

If the control uses Tabulator, record the first failing API call rather than treating “Tabulator versus V19” as the diagnosis. Static values were successfully rendered during separate tests with Chromium 55.0.2859.0, 83.0.4103.0, 88.0.4286.0, and 117.0.5888.0. That test shows the table can draw across widely separated browser engines, but it does not test this panel’s live data interface or identify the Chromium build embedded in its V19 runtime.

Check 2: Data transfer and serialization

A table library commonly draws nothing when it receives an empty value, malformed JSON, an unexpected object shape, or an exception during parsing. Replace the live input temporarily with a minimal static array whose field names match the column definitions.

1. Check 2A: expect the static rows to appear. If they do, retain the existing table code and inspect the live input.
2. Check 2B: expect the live payload to have the required type, a positive record count, and keys matching the column fields. Display those three readings inside the control.
3. Check 2C: when using JSON.stringify(), expect the serialized result to contain every property consumed by the table. The function serializes data properties, not executable functions. A design that depends on functions surviving serialization will fail unless the receiving code reconstructs that behavior.
4. Check 2D: expect parsing to complete without an exception. Log or display the parsing error and a bounded prefix of the received string rather than suppressing the failure.

If static rows render on the V19 panel, the browser engine and basic CSS are capable of displaying the table. Continue with the producer-to-CWC data contract; downgrading the development laptop or rebuilding the whole control would not address that branch.

Check 3: Runtime-specific behavior

The TIA Portal design view, simulation, PC Runtime, and panel runtime are separate execution contexts. An editor preview confirms appearance in the engineering environment. Simulation confirms its local runtime path. Neither result proves that the physical panel uses identical framework components, enabled web APIs, or CSS support.

1. Check 3A: run the CWC in the latest available V19 PC Runtime using the same device-version target. Expect the same result as the panel if the behavior belongs to the shared V19 runtime layer.
2. Check 3B: compare the V19 PC Runtime result with the V19 panel. If only the panel fails, concentrate on the panel image, installed updates, deployment, and device-side diagnostics.
3. Check 3C: use the browser console during simulation by opening Chrome DevTools with F12. Expect no uncaught JavaScript errors, missing-resource messages, or rejected API calls. Treat a clean simulation console only as the simulation baseline.
4. Check 3D: place the engineering system at the V19 Update 3 baseline identified for this test path, then apply the approved V19 fixes for the installation. Expect the project and target device version to remain aligned after recompilation and transfer.

The same V19 panel also failed to display a Siemens custom web table intended for V19. That comparison shifts the decision toward a shared runtime, panel image, update, or deployment condition rather than a defect unique to the custom table’s stylesheet. Escalate that branch through Siemens support with the smallest reproducible project and both controls.

Check 4: CSS and visible geometry

CSS compatibility remains a valid branch only after confirming that table elements were created. Embedded Chromium revisions can differ in support for newer CSS attributes. A container with zero computed height, hidden overflow, transparent content, or an unsupported layout rule can make a populated table appear absent.

1. Check 4A: expect the table container to report width and height greater than zero. Print the computed dimensions in the visible diagnostic area.
2. Check 4B: expect basic borders and background colors to appear when applied directly to the container and first row. Visible geometry with missing cells points to table-specific styles.
3. Check 4C: replace complex layout temporarily with block flow, explicit dimensions, basic colors, and no transforms or animations. Expect the static table to become visible if an unsupported or interacting CSS feature caused the failure.
4. Check 4D: restore styles one group at a time. Expect the table to disappear immediately after the incompatible rule group is restored; isolate the individual property from that group.

Removing CSS without first checking whether rows exist mixes rendering and data faults. Use geometry and row-count readings to select the branch.

Resolving procedure and acceptance checks

1. Add panel-visible markers for script start, constructor completion, input type, record count, parsing status, and computed container dimensions.
2. Deploy a minimal table with static rows and basic CSS to the V19 panel.
3. If it renders, reconnect the live data source and correct the payload type, property names, serialization, or parsing at the first failed marker.
4. If it does not render, test the same minimal control in V19 PC Runtime with the same device-version target and review simulation errors through F12.
5. Bring the V19 engineering and device installation to the V19 Update 3 baseline used for the comparison, compile the project, and transfer it again.
6. If the custom and Siemens tables both fail only on the physical panel, submit the minimal project, panel version information, runtime comparison, and diagnostic readings to Siemens support.

Acceptance requires more than a visible empty frame:

1. Verification 1: expect both constructor markers and no reported initialization exception.
2. Verification 2: expect the displayed input type and record count to match the live payload.
3. Verification 3: expect container width and height greater than zero and at least one visible static row.
4. Verification 4: expect the same columns, row count, filters, and representative values on the V19 panel as in the validated V19 runtime test.

Frequently asked questions