Why an HMI trend graph spikes while the number stays stable

Why does the trend graph spike when the weight number stays steady?

Because the number and the graph read the data through different paths: a numeric display reads one tag at its update rate, while a trend object samples its own configured tag at its own interval, so a transient can reach one and not the other.

A trend object samples the tag you point it at, at the interval you set, and draws the stored samples. The numeric display reads its own tag on its own schedule. Between them sit three things that can differ: the tag, the interval, and the conversion applied to the raw counts. A 100 ms transient lands in a pen sampling every 100 ms and never reaches a display register that a timed rung refreshes once per second. The steady number is real and the spike is real, and both can come from the same load cell.

A stable number does not prove the raw input is quiet. The number is one processed result of that input. Put a second pen on the raw counts, or trend the raw register next to the engineering value; setting raw and engineering units on an HMI trend walks through that setup.

Which four values do I record at the same scan?

Four values, captured at the same scan while a spike is on screen: the module's raw counts, the calculated weight register, the tag the numeric display reads, and the tag the trend object samples; log all four against a timestamp so no column is a memory of what happened.

1. The raw counts from the module's input register, before any scaling.
2. The calculated weight the PLC math writes, in engineering units.
3. The register the numeric display reads.
4. The tag the trend object samples, read out of the trend's own configuration.

Log at the trend's sample interval or faster. A log slower than the trend can step right over the spike. Keep all four columns timestamped, and let it run through the conditions that produce the spikes, typically a full production run. Open the trend's configuration now and write down its sample interval; that number sets what the graph can catch, and why an HMI trend graph will not update every half second covers the limits on how fast a panel samples.

What does each result of the comparison tell me?

Five outcomes, one repair each: raw counts jumping points at the signal path; raw steady with the calculated value jumping points at PLC math; calculated steady with the trend's tag jumping points at the copy or address; the trend's tag steady with the line jumping points at the trend configuration.

One boundary inside the second row: a value that is wrong in every sample is a scaling or format problem, not a spike. Work that with why the scale value differs from the PLC analog input. A BCD or integer format mismatch shows the same steady nonsense on every scan; an HMI showing nonsense numbers from a BCD analog register is the pattern. Spikes are transients, so treat them differently from constant errors.

Is the unshielded cable from the amplifier to the module the cause?

It is the first suspect, and one test settles it: short the input at the module terminals, and a 0 to 10 V channel then reads 0 counts; counts that wander on a shorted input mean noise enters that run or the module.

The wiring as built runs shielded cable from the load cell to the amplifier and unshielded cable from the amplifier to the module. The millivolt load-cell signal has the shield it needs. The amplifier output carries whole volts and tolerates more, but an unshielded pair routed near motor starters, drives, or power conductors picks up induced voltage every time one of them switches, and the module converts whatever arrives at its terminals into counts.

The test, with the process at rest: lift the field wires and short the input at the module terminals, using the method the module manual shows for your input type. A quiet shorted channel sits at 0 counts and stays there. Counts that wander with the input shorted mean the interference reaches the module through its power, its ground, or its mounting, and no field cable change will remove it. Reconnect the run and watch again. Counts that sit quiet shorted but jump with the run connected put the fault on the run: move it away from power wiring, cross power conductors at right angles, and replace it with a shielded twisted pair.

Land the shield at one end, where the module manual shows. A second bond at the far end can drive circulating current through the shield, and that current lands in your counts.

What does a worked example with real counts look like?

A 12-bit unipolar module reads 0 to 4095 counts over a 0 to 10 V input, 2^12 = 4096 steps; with the PLC scaling 4095 counts to 500.0 kg, one count is 500.0 / 4095 = 0.122 kg, and every column of the log comes out of that one conversion.

A hopper holds a steady 244 kg, which is 2000 counts. The trend samples once per 100 ms and throws one sample up before returning. The log across it:

The raw input jumped 560 counts, 560 / 4095 = 13.7% of full scale, worth 560 × 0.122 = 68.3 kg on the graph, for one 100 ms sample with no weight change. The calculated value and the trend tag followed it exactly, so the trend object is drawing its data faithfully. The display register still reads 244 because this program refreshes it once per second from a timed rung, and a 100 ms transient fits between refreshes. That is how a steady number and a spiking graph coexist.

The decision falls out of the columns. The signal path is at fault, not the PLC and not the trend, so the fix is the shorted-input test followed by rerouting and shielding the amplifier-to-module run. Repeat this log through a production run afterwards; a quiet input at constant weight holds within a count or two of 2000.

How do I check the trend object itself?

Open the trend's configuration and confirm three settings: the tag each pen samples, the sample interval, and the pen's scale range; a pen scaled 0 to 100 against a tag that runs 0 to 500 draws the trace wrong the moment the value crosses the pen's limit.

Check the source tag first. Read the address out of the trend configuration and compare it with the calculated weight register in the program. Intermediate registers get reused when programs are edited, and a pen left on a reused address plots whatever the new logic writes there. Then the interval and the buffer: the interval sets what the pen can catch, and the buffer sets how far back you can see. A buffer of 300 samples at one per 100 ms holds 30 s of history. Match the pen's range to the tag's engineering range so the trace uses the full height of the graph. After changing any of the three, rerun the same four-column log; a configuration change without a relog is a guess.

When do I stop and escalate?

Stop when the four logged values disagree in a way the rungs on screen do not explain, or when the repair needs a grounding change the manuals do not document; package the log, the module and amplifier model numbers, and the trend configuration, and take it to the manufacturer's support channel.

The package: the timestamped log across at least one spike, the module and amplifier model numbers, the trend object's configuration with source tags, interval, and pen ranges, and the wiring as built, shielded and unshielded segments marked. Those four columns answer the first question any support engineer asks, which side of the panel the fault sits on.

Recommendation: log the raw counts, the calculated weight, the display register and the trend's source tag at the same scan before touching the wiring. Rewire the amplifier-to-module run only if the raw counts jump at the same timestamp as the plotted spike. If the counts sit still, spend the hours on the PLC rung or the trend's source tag instead.

Questions