_error value. Closing and reopening the window corrects the color because it rebuilds the component bindings and subscriptions. The number that matters is the delay between changing the indirect tag target and receiving a fresh value and quality for that target.
Fixes That Miss the Failure
Several apparent fixes act on the display without correcting the binding sequence.
| Attempt | Why it appears relevant | Why it does not address the cause |
|---|---|---|
| Resize the containers | The symptom appeared after the containers were made smaller. | Geometry changes rendering area, not the tag path, subscription target, value, or quality. A size-related rendering defect would track component position or clipping; this color error moves among containers near a changed machine assignment. |
| Refresh or repaint from a value-change event | The visible color is stale while the machine number is current. | A repaint can redraw the same stale bound value. It is useful only after proving that the tag value changed internally but the component failed to render it. |
| Replace an indirect binding with an expression binding | The indirect tag changes its target during window initialization. | Both binding types can recalculate a tag path. The functional distinction stated for this system is that an indirect tag binding can be bidirectional, whereas an expression binding cannot. Merely changing binding type does not serialize identity selection and tag subscription. |
| Treat every red state as bad quality | SQL-tag components initially show an overlay and red X. | The overlay later clears while the container remains red. At that point quality has recovered, and the remaining red color comes from the color binding or style configuration. |
| Attribute the color to connection pooling | The behavior changed after moving from MySQL to MSSQL. | A pool problem requires corroborating connection or query errors. A single incorrect color with cleared overlays and otherwise current data points first to binding identity, ordering, or subscription timing. |
Timing and Quality Limits
The recorded settings represent more than one configuration snapshot, so evaluate the active runtime values rather than combining them into one assumed setup.
| Quantity | Recorded value | Engineering significance | Where to read it |
|---|---|---|---|
| SQL-tag polling | 5 sec | Maximum nominal wait for the next polling opportunity after a target changes, before query and update latency are added. | Active SQL-tag or scan-class configuration |
| Later scan-class mode | DIRECT |
Rules out a leased scan class as the stated configuration for that snapshot. | Tag scan-class assignment |
| Later low rate | 5000 |
Five-second acquisition cadence for the recorded scan class. | Scan-class settings |
| Later stale value | 10000 |
Ten-second stale threshold, equal to two nominal 5-second intervals. | Scan-class settings |
| Project SQL Poll Rate | 1000 |
One-second project polling setting in the later snapshot; verify how it interacts with the tag’s scan class. | Project settings |
| Base Rate | 1000 |
One-second scheduling base in that project snapshot. | Project settings |
| Fetch Thread Count | 7 |
Recorded fetch concurrency. Saturation must be proven from diagnostics before changing it. | Project settings |
| Update Thread Count | 3 |
Recorded update concurrency. A backlog could delay propagation, but the value alone does not prove a backlog. | Project settings |
| Earlier recorded values |
1000 poll, 5000 stale; project poll reportedly 250
|
These historical values show that timing settings changed. Audit records and the deployed project determine which change belongs to which layer. | Audit history and project revisions |
Polling is only one part of the latency. A database-backed tag update passes through scheduling, query execution, result processing, tag-cache publication, binding evaluation, and rendering. The stale threshold governs quality; it does not force a component to adopt the correct indirect target. This is timing, not paint.
Binding Retarget Race
The window first displays the configuration saved in the Designer. For example, it can open with machines 1 through 9, then receive a live configuration in which machine 4 is offline and the visible sequence becomes 1, 2, 3, 5, 6, 7, 8, 9. During that transition, a container may briefly hold identity 4 and subscribe to machine 4’s SQL tag. Its identity then changes to 5, but its color can retain the value obtained from the previous target if retargeting and result delivery cross in time.
This is a dependency-order problem. The container value selects the indirect tag path; that tag supplies _error; _error drives the style. Those three states must represent the same machine generation. If an old query completes after the container has changed identity, the runtime needs either request-generation control or a fresh subscription result before presenting the color as current.
The concentration of incorrect colors around the removed machine supports this decision path. The index shift begins at machine 4, so the next visual container changes from target 4 to target 5. If every error occurred at a fixed screen coordinate regardless of configuration, investigate component configuration or rendering instead.
Quality Overlay Versus Process Color
Separate quality indication from process-state styling before changing timing. On window load, the opaque overlay and red X mark unavailable or poor-quality tag data. Within about a second in the observed startup sequence, the live configuration arrives, overlays disappear, and most values become correct. A container that remains red after its overlay clears has a usable-quality value driving a red style; it is not merely displaying the quality overlay.
| Observed symptom | Most useful interpretation | Next check |
|---|---|---|
| Overlay and red X remain | Tag quality has not recovered. | Read quality, database connection status, query diagnostics, and stale state. |
| Overlay clears but color stays wrong | The style binding has a value, but the value may belong to the previous indirect target. | Display target identity, resolved tag path, _error, quality, and timestamp together. |
| Closing and reopening corrects the color | Recreating bindings and subscriptions obtains the current target. | Trace target changes during the original window initialization. |
| Designer is correct while runtime is wrong | The two clients have different component lifecycles, cached state, and subscription timing. | Test runtime independently with the Designer closed, then compare timestamps and resolved targets. |
| Many tags become poor or stale together | Shared database, polling, or worker-capacity delay is more likely. | Inspect query duration, pending work, connection errors, and thread utilization. |
Instrumented Diagnostic Procedure
Add temporary diagnostic labels to every affected container, or at least to containers on both sides of an offline-machine gap. Show the displayed machine identity, resolved SQL-tag path, raw
_errorvalue, tag quality, and last-change timestamp. The resolved path is essential: a correct Boolean from the wrong machine is still wrong data.Record the active scan class, low rate, stale threshold, project SQL Poll Rate, Base Rate, Fetch Thread Count, and Update Thread Count from the running project. Keep the 5 sec/8 sec snapshot separate from the later
DIRECT,5000/10000snapshot.Open the window with the Designer closed. Capture the initial saved machine list, the live list after configuration arrives, the moment each indirect target changes, and the value returned for each target.
Take one machine offline in a controlled test so that later containers shift identity. Watch the first shifted container. If its displayed identity becomes 5 while its resolved path or last value still belongs to 4, the retarget race is proven.
Compare quality with style state. When the overlay disappears, read the raw
_errorused by the color rule. A good-quality error value that disagrees with the correct target redirects the investigation from database availability to binding sequencing.Review audit history for changes from the earlier
1000poll and5000stale values, and for the project poll reportedly changed from250to1000. Establish when each setting changed and which deployed revision contained it.Inspect database and tag diagnostics during the same test. Correlate slow queries, connection faults, fetch backlog, or update backlog with the timestamps. Change thread counts only when measurements show sustained queueing.
Binding Sequence That Works
Make the live configuration the prerequisite for resolving the SQL tag. Keep the color in a neutral loading state while identity is missing, changing, or associated with non-good quality. After assigning the machine identity, recalculate the indirect path, wait for a value from that path, and then apply the red/green style.
Load the current machine configuration.
Assign a stable identity to each visible container.
Derive the tag path from that identity in one binding dependency chain.
Subscribe to or read the derived tag.
Accept the result only while the current identity and resolved path still match the request that produced it.
Apply the style from the accepted
_errorvalue and expose poor quality separately through the overlay.
If the platform’s binding engine already tracks those dependencies atomically, rebuilding the binding when the identity changes should be sufficient. A value-change script that merely repaints the component is weaker because it cannot reject a late value from an obsolete target. Preserve an indirect binding when bidirectional operation is required; use an expression when the binding is read-only and it makes the dependency on container identity explicit.
Runtime Verification
Verification must distinguish a visual correction from a data correction. Run repeated window openings with unchanged configuration, then repeat while removing and restoring a machine in the middle of the sequence.
| Acceptance check | Passing result |
|---|---|
| Identity-to-path mapping | Every visible machine identity resolves to that machine’s SQL tag after each configuration change. |
| Late-result handling | A result associated with the prior identity never changes the current container color. |
| Quality behavior | The overlay remains until the current target supplies usable quality; clearing the overlay does not leave a previous target’s color behind. |
| Polling behavior | Update timestamps follow the active polling configuration without unexplained stale intervals. |
| Client independence | Runtime passes with the Designer open and closed. |
| Window lifecycle | Closing and reopening no longer changes an already-correct machine/color mapping. |
| Configuration gap | Taking machine 4 offline shifts later containers without leaving machine 5 or adjacent containers in the prior state. |
Use several cycles because a race can disappear during a single test. Keep the diagnostic identity, path, value, quality, and timestamp visible until the failure no longer occurs across both normal startup and live reconfiguration.
FAQ
Why does an SQL tag container stay red after the quality overlay disappears?
The cleared overlay means quality recovered, while red is still being applied by the color binding or style. Compare the container identity and resolved tag path with the raw _error value to find a value retained from the previous indirect target.
Why does reopening the HMI window correct the SQL tag color?
Reopening reconstructs the bindings and subscriptions after the live machine configuration is available. That forces the component to resolve the current target instead of retaining a value delivered during the startup identity change.
Why does the SQL tag work in the Designer but fail in runtime?
The Designer and runtime have separate component lifecycles, subscription timing, and cached state, so test runtime with the Designer closed and log identity, resolved path, quality, value, and timestamp. Stop tuning poll rates or thread counts when the resolved path is correct but values still cross targets, or when database diagnostics show unexplained connection or worker failures; preserve the trace and escalate it to the manufacturer’s official support channel.