Why an HMI trend graph will not update every half second

What a half-second trigger pulse actually does

The pulse marks when you want a point. The interval the graph keeps comes from a cycle the pulse has no control over: poll the PLC, receive the value, draw it. When a pulse lands in the middle of that cycle, the panel finishes the read it is on, and the pulse turns into a repeated point or no point at all. Run the pulse at 0.5 s against a cycle that takes about 1 s and the spacing goes uneven, with flat stretches where several pulses fell between two completed reads.

The trend object's own settings tell you where the product line sits: 1 second, 1 minute, 1 hour, and no half-second choice. The pulse is an attempt to override the object's interval from outside.

Two facts bound what the link can deliver. On the PLC side, a PLC refreshes its inputs and outputs when the scan reaches each step, so the value on the wire is as fresh as the last completed scan. On the panel side, one line-trend family samples each assigned tag on a fixed period set in the panel, 200 ms minimum and configurable up to hours, independent of the PLC scan. If your trend object offers a sampling period of its own, set it and skip the pulse race entirely: the interval becomes a configuration value with a documented floor.

Symptoms and what each one points to

• Uneven point spacing on the 0.5-second pulse. The read-and-redraw cycle runs longer than 0.5 s at the current baud rate, and pulses land between cycles.
• Flat stretches, then a jump of two or three points. Those are the pulses that fell between completed reads; the plot repeated the last value.
• The PLC value changes on schedule while the graph lags. The panel's polling and redraw set the pace; work on the link.
• The PLC value itself is late or irregular. The upstream scan or the update logic is the limit; fix that before touching the trend.
• The trend slows when other screens, alarms or logged tags are active. Competing traffic shares the link; the trend viewer's own documentation warns that a large number of pens together with short sampling intervals may affect communication performance.
• The graph records correct values but redraws about a second apart. One control panel's troubleshooting documentation describes exactly this and names the bit assigned to the trend update, in the panel configuration, as the fix.

The first two symptoms are the link limit itself. The second pair moves the problem upstream or sideways. The last two are configuration, and they cost nothing to check before you touch the port settings.

Pulses dropped between reads behave like any PLC-triggered message sent faster than the panel services it. Fix dropped PLC-triggered messages on a serial HMI panel walks the same test on the messaging side, and its checklist separates link loss from panel lag.

Check the link before you change a setting

1. Write down the trend interval setting, the trigger tag and its pulse period, and the baud rate on the panel port and on the PLC port.
2. Look up the maximum baud rate each end supports, in the manuals or the port configuration screens. Both ends must run the same rate with the same protocol settings; a rate only one end supports is a mismatch, not an upgrade.
3. Run the trend for one full minute with the current settings and count the distinct points. The worked example below does the arithmetic.
4. Read the communication diagnostics on both ends over the same minute and note any errors.
5. List everything else that shares the link: alarms, data logging, other open screens. Cut what you can for the test.
6. Compare the plotted points against the PLC value itself, watched from a laptop or a second display reading the same register. One run splits panel-limited from PLC-limited.

Worked example: counting points in one minute of a 0.5-second trend

Inputs and where each comes from:

The rule in words: a window holds window / actual spacing fresh points. Requests beyond that number arrive between completed reads and repeat the previous value.

The arithmetic:

• Requested: 60 s / 0.5 s = 120 points
• Delivered: 60 s / 1 s = 60 points
• Repeats: 120 - 60 = 60 points

The result: half the plot is stale. At 1-second spacing the graph holds 60 distinct points per minute, so the 0.5-second request draws every second point as a copy of the one before it.

The decision: keep the 0.5-second setting only when one full minute at maximum baud rate produces 120 distinct, evenly spaced points with clean diagnostics. When the count lands near 60, the measured spacing is about 1 s, and the 1-second setting is the fastest dependable interval. Your own measured spacing replaces the 1 s input; the arithmetic stays the same.

Set both ports to the maximum baud rate, then test again

1. Record the current port settings on both ends so the link can return to them if the test fails.
2. Set the panel port and the PLC port to the same maximum rate both support. Leave every other protocol setting exactly as it is.
3. Run the trend for one full minute under normal conditions: the same screens open, the same alarms armed, the same logging on.
4. Count distinct points and read the diagnostics again.
5. Keep the faster rate when the points repeat at the spacing you asked for and the diagnostics stay clean. Restore the old settings when errors appear, because a link that corrupts messages is a worse fault than a slow trend.

A higher baud rate shortens transmission time on the wire. The poll cycle and the redraw keep their own duration, which is how a panel can log correct values yet stay near 1-second spacing. Faster polling is also more traffic for the PLC scan to service, and rising scan time is a documented sign of added communications overhead. Watch the scan while you test: if it stretches, the trend reads faster while the value itself leaves the scan later.

Two more settings that cap what the window shows

Pens and span bound the trend from above while the interval bounds it from below.

• Pens. The trend documentation warns that many pens together with short sampling intervals affect communication performance. Run two or three pens on the fast trend and move the rest to slower trends or cut them.
• Span. The span setting caps how much history the window holds. One panel family caps the span value at 999, which its documentation puts at roughly 9 to 10 hours. A longer run needs a data log; how to show the full test duration on a live trend chart covers what the window itself can show.

The decision for each outcome

• 120 of 120 points, even spacing, clean diagnostics at maximum baud. Keep the 0.5-second trend and recheck the count after a week of running.
• A count near 60. Set the trend to its 1-second setting; that is the interval the link delivers. Leave both ports at maximum baud anyway: the headroom costs nothing.
• The PLC value arrives late. Fix the scan or the upstream update first. The trend plotted what the PLC released, when the PLC released it.
• The process needs a faster record. Log it where the link is out of the path: a data log in the PLC or a dedicated logger on the same signal, then page through that record on the panel. Whether the panel itself can hold the log is its own question; whether an HMI panel can store PLC data for later retrieval takes it up.

An uneven plot is a slow plot. Reports built on it will undercount fast events, so label the trend with the interval that actually repeated and keep the fast record in the log.

Recommendation: set the panel port and the PLC port to their maximum supported baud rate, run the trend for one full minute, and count distinct points. Keep the 0.5-second setting when all 120 arrive evenly with clean diagnostics; otherwise set the trend to its 1-second setting and capture anything faster in a PLC or logger data log.

Questions