Why Does an Easy Chart Lag Behind HMI Indications?

Stefan Weidner6 min read
HMI / SCADAOther ManufacturerTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

After aligning the HMI client and gateway clocks, the Easy Chart should plot current samples against the same definition of “now” used to request its visible time range. A reported 30–45 second delay between discrete indications and the chart points first calls for a client-to-gateway clock comparison, not a chart replacement.

Where does the chart request travel?

Follow the packet. The Vision client determines the chart’s requested time window. That request crosses the network to the gateway, which retrieves timestamped history and returns the result to the client for display. The relevant path is:

Vision client → network → gateway → historian → gateway → Vision client

A discrete indication takes a different logical path. It normally displays the latest subscribed tag value, while a historian-backed chart selects records by timestamp. Both objects can receive data through the same connection yet disagree about which samples belong in the current chart window.

If the client clock says “now” is 45 seconds earlier than the gateway clock, the chart can request a window ending 45 seconds behind the gateway’s present time. Current discrete values may still change immediately because their display does not depend on that historical end-time calculation. The resulting symptom looks like slow acquisition even though the live tag path is operating normally.

Which cause best matches a fixed chart lag?

Check Expected symptom Decision
Client and gateway clock offset Chart stays behind current indications by a fairly repeatable interval Primary check for a 30–45 second apparent lag
PLC clock error on timestamped OPC data Samples arrive but appear at the wrong horizontal position in both Vision and Perspective Inspect when the data source supplies or influences timestamps
Network interruption or congestion Live values, chart requests, or both update irregularly; delay often varies Check the physical and transport path when the symptom is intermittent
Historian write or query delay Stored samples become visible late even when all clocks agree Compare live value time, stored timestamp, and query result
Normal chart refresh behavior Delay follows the configured polling or refresh behavior Review chart settings only after timestamps agree

The strongest discriminator is repeatability. A stable offset points toward clock disagreement. Variable delay, gaps, or simultaneous freezing of discrete values points toward communications, acquisition, storage, or query performance. Layer one first when multiple objects stop updating: link state, interface errors, and connection stability precede protocol analysis.

The reported client was within one or two seconds of an external time reference. That verifies only the client. The gateway may still differ, so compare the two clocks directly from the same Vision session.

Why can discrete indications update before the chart?

A discrete object answers “what is the latest value?” A historian chart answers “which timestamped values fall between the requested start and end times?” Those are different operations.

For a live indication, a newly received value can replace the displayed value as soon as the subscription processes it. For a chart, each sample must carry a timestamp, be stored or queried, fall inside the selected range, return to the client, and then be rendered. A mismatch at any timestamp boundary can hide a current sample until the client’s requested end time reaches it.

Do not convert the observed visual difference directly into historian latency. First establish three times: the client’s current time, the gateway’s current time, and the timestamp attached to the plotted sample. The point where those diverge identifies the failing hop.

PLC time matters when OPC data carries source timestamps or when a data pipeline derives historical timestamps from the controller. A wrong PLC clock can shift plotted data in both Vision and Perspective. If the gateway assigns the history timestamp instead, the gateway clock becomes the decisive reference. Read the timestamp shown by the tag diagnostics or stored record rather than inferring timestamp authority from the chart.

How do you measure the client-to-gateway offset?

Add a temporary label to the same Vision window as the Easy Chart and bind its text to this expression:

secondsBetween({[System]Client/System/CurrentDateTime},{[System]Gateway/CurrentDateTime})

This exposes the relative difference that affects the chart request. It is more useful than checking the client against an external reference because it compares the two systems participating in the display path.

  1. Open the affected window from the same client computer used by the operator.
  2. Observe the temporary offset label while watching a discrete indication and its corresponding chart trace.
  3. Record the sign and magnitude of the client-to-gateway difference.
  4. Trigger or wait for a process transition whose live indication and plotted value are easy to identify.
  5. Compare the clock offset with the apparent horizontal chart displacement.
  6. Inspect the PLC clock and the sample timestamp if the client and gateway already agree.

Use a screen recording or timestamped test note if an operator must react to the trace. The initial report estimated 30–45 seconds, but the actual delay was not confirmed. Measure it before changing chart settings.

How should the clock fault be corrected?

Use a common time-synchronization source for the client, gateway, and any PLC whose timestamps enter the data path. The objective is not merely for each device to show a plausible wall clock; all participating clocks must agree with each other.

  1. Identify the host running the Vision client and the host running the gateway.
  2. Compare their current times with the temporary Vision expression.
  3. Check each host’s operating-system time service, configured time source, synchronization state, time zone, and daylight-saving configuration.
  4. Correct the host that differs, then allow its time service to synchronize according to the site’s operating policy.
  5. If OPC source timestamps are used, compare the PLC clock with the gateway and correct the controller through its approved engineering procedure.
  6. Reopen or refresh the chart window and repeat the transition test.

Avoid hiding a clock fault by shifting the chart range or adding an arbitrary display offset. That compensates for one observed condition while leaving historical records, alarms, reports, and other clients on conflicting timelines. Likewise, changing historian sampling settings will not correct samples plotted at valid but mismatched timestamps.

How do you verify the complete data path?

Verification must separate timestamp correction from true acquisition or query delay.

Observation Interpretation Next check
Clock offset matches chart displacement Client and gateway disagree about the chart’s end time Correct synchronization and retest
Clocks agree but stored timestamp is shifted Timestamp authority lies elsewhere in the acquisition path Check PLC time and OPC timestamp source
Timestamps are correct but records appear late Delay occurs during storage, query, or refresh Measure when the sample is acquired, stored, returned, and rendered
Discrete values and chart both freeze Problem is broader than chart time selection Inspect physical link and connection health

Run the final test at the process point used to select the subsequent set point. Observe the live indication, note the gateway-relative offset, and confirm that the corresponding chart point appears at the correct timestamp. Repeat the test rather than relying on a single visual estimate.

FAQ

Can I make an Easy Chart display true real-time data?

A historian-backed chart can track current data closely when the client, gateway, and timestamp source agree. First correct their clocks; replacing the chart does not repair a mismatched time base.

Does a 30–45 second Easy Chart lag mean the historian is slow?

No. A stable 30–45 second displacement can come from the client requesting a historical window based on a clock that differs from the gateway. Compare the clocks before measuring storage or query latency.

Can I check the gateway time from a Vision client?

Yes. Bind a temporary label to secondsBetween({[System]Client/System/CurrentDateTime},{[System]Gateway/CurrentDateTime}) and compare the displayed offset with the chart displacement.

Does the PLC clock affect Vision and Perspective charts?

It can when OPC data uses timestamps derived from the PLC. Inspect the plotted sample timestamp and compare the PLC clock with the gateway clock.

Can I verify the fix without changing the chart configuration?

Yes. Repeat a recognizable process transition, confirm the client-to-gateway offset is no longer responsible for the displacement, and verify that the new point appears at the correct timestamp while the discrete indication changes.

Back to blog