Bar graphs slow to update on file writes: split live data from recipes

What the symptoms point to

Three failures stack up here, and they hide behind each other. Match what you see against this list:

• The writing message stays lit for most of each 1-second cycle. The panel is spending the cycle on file handling. A recipe update is a whole-file copy plus a processing run, far more work than changing one tag.
• Values step only after each file lands. The alarm event fires, the recipe load runs, and only then do the tags update. The display waits for the file every cycle.
• An alarm fires the load every second. An alarm event announces a condition. Pointing it at a recipe load each second turns the alarm system into the data feed, and every firing is another file job.
• The bar looks frozen during the fine band. With limits of 0 and 200, a 0.1-unit step is 0.05% of full scale. Faster file transfer will never fix this; only the scale will.

The writing message marks an active write operation; there is no error code to clear. The fix is to stop running per-second data through the file path.

Time ten cycles before you change anything

Put a stopwatch on the panel and record three times across ten 1-second cycles: how long the writing indication stays lit, when the PC starts each transfer, and when the displayed value actually steps.

• Writing lit more than half of each cycle: the file path is eating the refresh budget. Move the live values off it.
• Writing clears quickly but values still lag: trace one value at three points, the PC value, the recipe entry it lands in, and the tag the bar reads. The point where the value stops moving is where the delay lives.
• Tag steps promptly but the bar barely moves: the scale is the problem. Go to the worked example below.

Change one thing at a time and re-run the ten cycles after each change.

Move the per-second values to a tag connection

Every panel in this class documents the controller and PC connections it supports. Pick the tag protocol the manual lists for your network and put the per-second tags on it. A tag read updates the one register the graph uses on each poll; no file is copied and no recipe database is reloaded. The same path clears the delays described in Fix Modbus TCP data slow to update on an HMI panel.

Keep the expectation realistic at this rate. One update per second per tag set is already a demanding cycle, and the same pressure is why an HMI trend graph will not update every half second when one link is pushed past its pace. If the graph still lags on a clean tag connection, the remaining suspects are the ones in Fix a slow HMI panel: touch, entry and screen update delays.

Keep file writes for real recipe loads

The recipe file still has a job. The panel's FTP service exists to back up and update history data and recipe data after a project download, and an update is a whole-file overwrite: the copy replaces the recipe database on the panel. That cost is fine when an operator saves a recipe or a batch changes, and wasteful at one write per second, which is 3,600 whole-file passes an hour.

Trigger the write on recipe events instead of the alarm tick: a saved recipe, a recipe loaded to the controller, a batch change. Between events the file sits still and the panel does display work.

One more rate to check: if the per-second values also write into retentive memory in a controller, compare the rate against that device's rated write cycles first; a page on whether per-second Modbus RTU writes wear slave memory works through when the rate matters and when it is harmless.

Back up the project and the recipe data before you change the write pattern, and run the first tests with the line idle, because a half-written recipe file can leave a running process with bad setpoints.

Worked example: two scales for one tag

One tag sweeps from 10 to 200 units during startup and then holds between 150.0 and 150.1 during fine work. Take the bar graph at 240 pixels long with fixed limits of 0 and 200.

• Wide bar: 240 px / 200 units = 1.2 px per unit. A 0.1-unit step moves the bar end 0.1 x 1.2 = 0.12 px. A pixel is the smallest mark the panel can draw, so the bar shows nothing, or an occasional 1-pixel jump.
• Narrow bar on the same tag: set the limits to 149 and 151. The span is 2 units, so 240 px / 2 units = 120 px per unit. The same 0.1-unit step now moves the bar 0.1 x 120 = 12 px, visible from across the panel.

As fractions of full scale, 0.1 / 200 = 0.05% and 0.1 / 2 = 5%: the narrow limits buy 100 times the resolution, and 149 to 151 leaves headroom on both sides of the 150.0 to 150.1 band. Run both bars side by side, the 0 to 200 bar for context and the 149 to 151 bar for fine work, each labeled with its range and units. If the project editor's limit fields accept tag values, test them with real low and high values on a bench panel first. A scale that follows the signal also follows a fault upward with it, so fixed narrow limits stay the dependable choice on a running line.

What to change, in order

1. Back up the project and the recipe data, and schedule the first test with the line idle.
2. Time ten cycles and apply the half-cycle rule from above.
3. Move the per-second tags to the tag connection the panel documentation lists.
4. Point the recipe file write at recipe events: operator save, recipe load, batch change.
5. Add the 149 to 151 bar beside the 0 to 200 bar, labeled with range and units.
6. Verify with three runs: a startup sweep on the wide bar, a fine-band run where each 0.1 step moves the narrow bar 12 px, and a real recipe save where the writing message appears once and clears.

A separate screen for shift targets, counts and notices is a slide-based job for shop-floor signage; the live tag work stays on the panel doing it now.

Recommendation: if the writing indication covers more than half of each 1-second cycle, move the per-second tags to the documented tag connection, trigger recipe file writes only on real recipe changes, and add a fixed 149 to 151 bar beside the 0 to 200 bar for the fine band. If the panel documents no tag path to the PC, shrink the file to the values that changed and set the cycle to the fastest rate ten timed writes sustained.

Questions