Why a real time graph clears when you change HMI screens

Why does the graph lose its points when I change screens?

Because the object is designed that way: a real-time graph stores no values in the panel, so each time the screen containing the object is accessed, the object begins a new display and the previous points are gone. The help page for the object in your project software documents this in one line, and it matches what you see. The points you watch exist only inside the object while its screen runs; navigating away closes that display for good.

Two different jobs hide behind this symptom. Watching a value live on one screen is the object's job, and it does that well. Keeping history the operator can return to is not its job at all. Name which job you have before you change anything else, because the two need different designs.

Is this a software version fault?

No: the panel's own help documents the restart, so installing a different version is not a targeted fix; if your release notes list no such fix, that matches the documented behavior. Checking release notes for a cure spends time on the wrong question. The restart is written into the object's definition, so leave the version alone and answer the design question instead: does the operator need history across screen changes?

One real fault can hide nearby. If the plot never draws points even while its screen stays open and the source values move, that is a data-source or communications problem, not the restart. The checks below separate the two in a few minutes.

Which symptom points to which cause?

Three symptoms cover this job: points vanish exactly on returning to the screen points to the documented restart; no points while the screen stays open points to the data source; garbage or flatline values point to the data format.

• Points reset on return, but plot fine while the screen is open. This is the documented restart. Nothing in the object is faulty; the history job belongs in the PLC.
• No points while the screen stays open and the PLC values change. The object is not receiving what you think it is. Check the configured source address or tag against the registers that are actually moving.
• Points plot but sit flat, spike, or read impossible values. Format mismatch, and the classic case is a 32-bit float read as one 16-bit word; see display a PLC float stored in two word registers.
• Plot updates slower than the interval you set. That is a refresh limit, not storage; see why an HMI trend graph will not update every half second.

How do I confirm the graph is meant to restart?

Run a five-minute reproduction: open the graph screen, let it plot for about two minutes, switch to another screen, come back, and watch for 10 seconds; a plot that restarts empty is the documented behavior. Reproduce before you redesign. If the reset happens exactly on screen re-entry, the object works as documented and the fix is the design change below.

If the screen stays open and no points appear while the source values move, stop there: you have a data-source fault, and the checks in the next section apply. Read the object's help page in your own project software as well; the restart is stated there, and having it in hand settles any argument about whether the panel is faulty.

Do the source values actually change?

A graph cannot plot a trend from values that stand still, so open the graph's source addresses on a data view and confirm each one moves within a single sample interval before you touch the graph object. The quickest way is to watch several PLC values in one data view while the graph screen is open.

• Values move and points plot. The plotting path is healthy; retention is the only open question.
• Values move but no points appear. The object reads different addresses than the ones moving. Correct the configured source.
• Values stand still. Fix the PLC logic or the communications path first; no graph type draws a trend from a constant.

Keep this check separate from retention. A moving input makes the live plot work, but it contributes nothing to history, because the panel never wrote the past points anywhere.

How do I keep the history across screen changes?

Move the history into the PLC: keep a sample array in registers your logic maintains, and display it with a line graph object, which reads the entire data set from the PLC each time the screen opens. This is the same division of labor behind why an HMI historical trend graph needs the PLC to keep the memory: the panel draws, the PLC remembers.

1. Pick the sample interval from the process. A temperature or pressure trend on a machine moves in seconds to minutes; 1 second is a sensible default, and 10 seconds is enough for slow processes.
2. Reserve the data set in retentive registers. One block for the samples, one word for the write pointer, sized by the worked example below.
3. Write the sample logic in the PLC. On each interval tick, write the new value at the pointer, advance it, and drop the oldest sample once the block is full, so the set always holds the most recent samples.
4. Replace the real-time graph with a line graph. Configure it to read the block start and the sample count, and set the data format to match the PLC: one 16-bit word per sample, or two registers per 32-bit float.
5. Test navigation with live values. Watch points arrive, change screens, come back, and confirm the whole data set is still on the plot.

Worked example: how many registers does a 10-minute trend need?

A trend that samples one temperature once per second for 10 minutes needs 600 samples, which takes 600 words of 16-bit registers, or 1,200 words if each value is a 32-bit float. The inputs are yours to set; the arithmetic is fixed:

• Sample interval 1 second, history wanted 10 minutes = 600 seconds. Samples needed: 600 s / 1 s = 600 samples.
• 16-bit integer values: 1 register per sample gives 600 words, plus 1 pointer word, so 601 words total.
• 32-bit float values: 2 registers per sample gives 600 x 2 = 1,200 words, plus 1 pointer word, so 1,201 words total.
• If your PLC gives the block 2,000 retentive words, the same array holds 2,000 samples, which is about 33 minutes of integer history, or 1,000 samples, about 16 minutes 40 seconds of float history.

The general rule: samples = minutes of history x 60 / interval in seconds, and words = samples x registers per sample + 1 for the pointer. Writing a handful of registers once per second is a light load against PLC scan times measured in milliseconds, so the interval choice sets history length, not processing cost.

How do I verify the fix?

Test the requirement, not the object: leave the screen for two or three minutes while values move, return, and confirm the plot comes back with the full data set and keeps adding live points while you watch. Split the two jobs in the test. Live: with the screen open, new points arrive at the interval you set. Retained: the history returns complete after navigation. If retained points are missing, check the PLC data set first, then the line graph's configured source; the panel shows only what the PLC kept. If the trend must survive a power cut, the sample block has to sit in retentive registers; prove it once by cutting control power under safe conditions and rechecking the plot after restart.

If operators judge the process from the trend, label the plot window with its time span, because an unlabeled restart can read as a flat or empty process.

Recommendation: keep the real-time graph object where the job is watching a value on one screen, and switch to a PLC-maintained sample array with a line graph object as soon as the operator needs history across screen changes; size the array at 60 samples per minute of history for 1-second sampling, or 6 samples per minute for a 10-second interval.

Questions