Why fixed trend pens appear blank at runtime

Separate missing pens from blank traces

A fixed pen is a predefined series in the trend display. Establish whether its definition is absent or whether it exists but draws nothing. Those symptoms lead to different checks:

• The pen is missing from the list: inspect the deployed page, pane definitions and configuration-loading path.
• The pen is listed with a connection error: inspect its trend connection, service availability and runtime access.
• The pen is listed without an error but has no trace: check recorded samples, the displayed time range, visibility and scale.
• Existing pens begin drawing after Add Pen: compare their state before and after the action. Binding or initialization becomes a candidate.
• Only the newly added pen draws: compare that pen with the fixed pens. The action may not have repaired the existing definitions.
• The same project behaves differently on another computer: compare deployment and runtime conditions before changing the project globally.

Start from a fresh runtime session. Capture the pen list, connection text, Error column and time window before using any toolbar controls. Then perform only the Add Pen action and record exactly which pens change.

Do not replace this observation with “the trend works after clicking.” You need to know whether existing pens recover, a new pen works, or the visible time window changes.

Compare a fixed pen with a browsed pen

Choose one trend with known recorded samples. Add it through the runtime browsing interface, where available, and compare it with the fixed pen intended to show the same series.

Keep the trend tag separate from the underlying process variable. A live value elsewhere on the page establishes that one data path works. It does not establish that the trend subsystem has recorded that value or that the pen requests the correct history.

Use the connection generated by the supported browser as a comparison, not as a reason to copy an unrelated project's cluster name. Connection syntax must match the installed runtime and the running project.

If the browsed pen draws while the fixed pen does not, with matching connections and view settings, focus next on how the fixed pen receives its configuration.

Use the Error column to choose the next check

Enable the trend control's Error column or equivalent diagnostic view. Record the exact indication for each affected pen at page entry, after Add Pen, and after any configuration-loading test.

A connection error points toward the named source, connection format, permissions or service. Follow the runtime documentation for that indication rather than assuming every blank pen has the same cause.

An error that disappears after configuration loading is evidence that the loading path changes the connection state. It is not proof that every startup requirement has been satisfied.

No reported error is also not proof of usable data. A valid connection can return no samples for the selected period. Keep connection diagnosis and history diagnosis separate.

Avoid suppressing errors while evaluating a workaround. If the configuration function fails, retain enough diagnostic information to distinguish a missing file, an unavailable control and a rejected connection.

Check the time range and recorded history

Set the display to a period where samples are known to exist. Check the runtime computer's clock and the time convention used by the trend service. A mismatch can make available history appear outside the selected window.

Then verify the collection path:

• Confirm that the intended trend is configured for collection.
• Confirm that its data source is available to the running project.
• Check whether samples exist through a supported history view or diagnostic tool.
• Check collection conditions, including any sampling or change-based recording rules.
• Return to the trend pane and choose a suitable scale.

Do not change controller logic merely because a historical trace is blank. First establish where the samples stop appearing: at the process value, the trend collector, the history service or the display.

If a trace is present but arrives late, that is a separate timing question. The display-side checks in factory screen update delay diagnosis help separate acquisition delay from presentation delay.

Compare the deployed runtime

A project working on another computer is a useful comparison, not a diagnosis. The two installations may use different compiled files, runtime builds, data locations or service settings.

Compare these items before replacing fixed-pen definitions throughout the project:

• The project revision and compiled deployment files.
• The runtime version and installed maintenance updates.
• The selected project, cluster and service configuration.
• The saved pen configuration and its resolved file path.
• Runtime account access to required files and data sources.
• Local saved display state and documented cache behavior.

Use manufacturer-approved installation and update packages. Make project and data backups before changing local state.

Do not delete a runtime data directory as a general troubleshooting step. It may contain history or other operational records. If the documentation calls for resetting a specific cache or saved configuration, follow that procedure during a controlled maintenance window and preserve a recovery path.

Load the saved configuration after the page is shown

An embedded trend control and its containing page can have separate initialization stages. A page-start action may run before the control is ready for configuration calls. Where the runtime provides an On page shown event, it is a useful place to evaluate a later configuration load, subject to the installed version's documented event sequence.

Use this controlled sequence:

1. Preserve the original configuration. Back up the page and project. Record how to remove the added event call.
2. Save a known-good pen configuration. Use the trend control's supported save function. Include the intended pane, connections and view settings.
3. Confirm file deployment. For a saved .pav configuration, verify that the required file reaches the runtime computer and is accessible under the runtime account. Check how relative paths are resolved.
4. Identify the intended control. Use its configured object name or supported reference. A function targeting the wrong page instance cannot establish a reliable result.
5. Call the documented configuration loader. Use the installed version's documented function signatures and object methods. Attach the call to the page-shown event for this test.
6. Record loading failures. Check the documented return status or error mechanism. Do not treat an empty pane as sufficient feedback.
7. Reopen the page without toolbar interaction. Confirm that the expected pens and real samples appear without Add Pen.

Do not treat an arbitrary delay as proof that the control is ready. If the runtime documents a readiness event or condition, use it as directed. Also check whether page-shown can run more than once and whether reloading would replace manual pen selections, zoom settings or other saved state.

Check the repair from a fresh session

A successful configuration load establishes a working path under the conditions observed. It does not identify the original fault by itself.

Check startup, navigation away and back, and repeated page entry. Confirm that the load does not duplicate pens or reset a useful time window unexpectedly. Verify every intended connection, not just the first trace that appears.

The repair is ready to retain when the expected pens load without manual intervention, known samples are visible, diagnostic indications are understood, and repeated entry produces the intended state. Keep the configuration file, page event and deployment requirements documented together.

If the fault remains, provide support with the runtime build, project revision, exact pen errors, connection comparisons and before-and-after observations. That evidence is more useful than repeatedly rebuilding the same trend pane.

Questions