WinCC Unified: Display Lag, Not a Missing Station List

Treat the disappearing station names as a Unified Runtime display or object-refresh problem first, not as evidence that the S7-1500 lost the station data. On the reported IPC 677E running WinCC Unified V19, the entries reappear after scrolling, which means viewport invalidation or delayed rendering is the primary diagnostic path. Identify the actual screen object, check competing scripts, apply the applicable V19 updates to both engineering and Runtime components, and then test the list without scroll-assisted recovery.

Symptom interpretation

The reported symptom is narrow: the station-navigation list on the main Unified screen becomes invisible, scrolling down and back up makes it visible, and other station lists and drop-down controls update normally. This pattern separates a display defect from a broad communication failure.

The term render lag here means that Runtime has not painted the expected visible rows at the time the operator views them. It does not mean that the source tags are necessarily late. Prove that distinction by monitoring a station-name value independently from the navigation object while reproducing the fault.

Object and rendering mechanism

First identify the object behind the apparent drop-down. In Unified engineering, a conventional selection list may be implemented as a symbolic I/O field, while a visually similar navigation element may be assembled from faceplates or other screen objects. Those implementations have different item-generation, binding, and redraw paths; calling all of them a drop-down hides the most useful diagnostic fact.

Select the affected element in the engineering project and record its exact object type. If it is inside a faceplate, also identify the parent faceplate, its interface bindings, and any nested objects that create the station rows. Compare those properties with one list that never disappears.

Scrolling changes the viewport and requests a new paint of the visible region. When that action restores the names, the item model and the visible pixels have become temporarily unsynchronized. Common causes in this equipment class include a screen script occupying the Runtime execution path, repeated writes that continually invalidate the object, a faceplate whose visibility or content is recalculated during scrolling, and a software defect already corrected by an update. The PLC normally supplies values; the Runtime PC creates and paints the operator interface. Therefore, repeated PLC downloads do not directly correct a client-side redraw problem.

Diagnostic checks

1. Confirm data continuity. Display one affected station-name value in a simple text or I/O object outside the navigation component. Reproduce the blank list. If the independent object retains the correct value, keep the investigation in the HMI rendering path. If it also loses the value, inspect its tag quality and connection before changing the list.
2. Classify the object. Determine whether the element is a symbolic I/O field, a faceplate-based control, or another screen object. Capture its bindings, visibility dynamics, event handlers, and parent containers. Do not tune list behavior until this classification is complete.
3. Correlate scripts with the failure. Inventory scripts triggered cyclically, on screen load, on property change, and by scrolling or selection. Temporarily disable one nonessential script at a time in a controlled project copy. A list that stops disappearing after one script is removed identifies contention or repeated property mutation around that execution path.
4. Compare against a minimal control. Create the same station selection on an otherwise empty diagnostic screen, using the same source values but no decorative layers or unrelated faceplates. If the minimal control works, add the original nesting, dynamics, and scripts incrementally until the symptom returns.
5. Check software maintenance state. Record the installed update levels for TIA Portal V19 and the Unified Runtime PC separately. Base the comparison on the installed-component records rather than the project version label alone.

Corrective procedure

1. Back up the engineering project and record the Runtime PC's current software state before changing packages.
2. Review both official Siemens V19 update resources: Siemens update resource 109925643 and Siemens update resource 109820989. Read each package's applicability and installation notes, then select only the updates that match the installed engineering and Runtime components.
3. Bring TIA Portal and the Unified Runtime PC to compatible, applicable V19 update levels. Updating only the engineering workstation leaves the executing Runtime binaries unchanged; updating only Runtime can leave the development and target environments out of step.
4. Recompile the affected HMI content and deploy it to the IPC 677E using the project's normal controlled-download process.
5. If the symptom remains, remove or reschedule the script identified during isolation. Avoid cyclically rewriting list items, visibility, or selection properties when their values have not changed.
6. If the object is faceplate-based, test a reduced instance with the same interface data. Restore properties and nested elements one group at a time. The first restored group that recreates the blank viewport defines the faulty interaction.
7. If a standard Unified list control works with the same data while the composite object fails, retain the standard control or redesign the composite so item updates and visibility changes do not occur during its paint cycle.

Verification readings

1. Check 1: initial screen load. Expect every station name in the visible region to appear without the operator scrolling the list.
2. Check 2: repeated scrolling. Scroll from the first visible entry to the last and back repeatedly. Expect no blank rows, delayed names, or need for a second scroll to recover content.
3. Check 3: independent data display. Compare the selected entry with the diagnostic text or I/O object. Expect matching station data and valid tag quality while the list is exercised.
4. Check 4: navigation cycles. Leave the main screen, return to it, and repeat the list test. Expect the same complete rendering after every screen load.
5. Check 5: normal script load. Restore required background scripts and operate the screen through its normal sequence. Expect the navigation list to remain visible while those scripts execute.

Recurring pitfalls

Do not diagnose the control from its appearance. A faceplate assembly can resemble a drop-down while having entirely different update behavior. Do not treat scrolling as a repair; it merely forces a repaint and masks the failing path. Do not start by changing PLC logic when other controls remain current and the same entries return through a local screen action.

Avoid changing updates, scripts, bindings, and faceplate structure simultaneously. That prevents attribution of the fix and can introduce another fault. Keep one reproducible test sequence, change one variable, and record the result. Also avoid declaring success after a single recovered display: initial load, repeated scrolling, screen re-entry, and normal background activity exercise different redraw triggers.

FAQ