Home/Blog/Why Your Batch Weights
Field notes · Optimization

Why Your Batch Weights Wander Even When the Recipe Never Changes

By Jonathan Gilmour··10 min read

The recipe hasn't changed, the operator hasn't changed, and yet your cement, aggregate, or additive weights keep drifting outside tolerance — here's where the accuracy actually leaks out.

You usually know the batch is out before the paperwork tells you. The mixer sounds a little wrong, the slump comes back stiff, and a day later a strength test flags a number that shouldn't be flagging. Somebody pulls the batch report and finds the cement came in three percent light and the coarse aggregate a couple percent heavy. Nobody touched the recipe. The operator who ran the good batches last week is running the bad ones this week. And the plant, which has weighed material more or less the same way for a decade, has quietly stopped agreeing with itself.

Weigh batching accuracy is one of those problems that looks like a single fault and almost never is. It's usually three or four small things stacking up, each individually within spec, that together push a batch past tolerance. Worth being clear on what tolerance even means here: the concrete industry generally works to roughly one percent on cementitious material and water, two percent on aggregate, three percent on admixture, which is the ASTM C94 and ACI 117 neighborhood. Three percent light on cement isn't a rounding error, it's well outside the window. The real skill is knowing which of those stacked-up things the control system can fix and which it can't, because chasing a mechanical problem with a cleverer control loop is a good way to spend a month getting nowhere.

In-flight material is the accuracy you're already committing to

Every gravimetric batch has a moment where the controller closes the feed gate or stops the auger, and material that has already left the source but hasn't landed on the scale keeps coming. That falling column of cement or aggregate is the in-flight material, and on a lot of plants it's the single biggest source of batch-to-batch error. The compensation goes by a couple of names, and they aren't quite the same thing: preact is the number you dial in, the amount you cut the feed early by, while free-fall or in-flight is the physical mass that number is trying to predict. Same idea either way. Stop the feed short of target so the material still in the air brings you home instead of overshooting.

The problem is that most preact values were set once, by hand, at commissioning, and then left alone forever. A fixed preact assumes the in-flight mass is constant, and it isn't. How much material hangs in the air when you cut the gate depends on feed rate, on how full the hopper above is, on moisture in the aggregate, and on whether you're trimming the last of the batch in a slow dribble or slamming the gate shut at full flow. A preact tuned for a full hopper on a dry morning will overshoot on a near-empty hopper feeding damp sand that afternoon.

The fix that actually holds is adaptive preact: let the controller measure the real overshoot on each batch, compare it to what it predicted, and nudge the number for the next batch of that material. Set up right, it tracks free-fall across hopper levels and feed rates and keeps up as conditions drift through the day. Set up carelessly, it chases noise. I've watched a learning routine walk the preact something like four percent across an afternoon because nobody had bounded the step size or filtered the input, and the crew ended up switching the whole thing off and running fixed again, which put them right back where they started. So the learning has to be filtered and the correction bounded. But the gain is real, and it's usually the first place I look, because it costs nothing in hardware and it's often been sitting misconfigured since the plant was new.

Load cells drift, and calibration is not a one-time event

A load cell turns weight into a small electrical signal, and like anything that lives on a plant, it drifts with age. Connections in the summing box corrode, temperature swings move the zero, and material builds up on the scale structure until the empty weight isn't empty anymore. None of it is dramatic. A fraction of a percent here, a slow zero walk there, and it hides well because the plant keeps running and the numbers still look plausible.

Two patterns show up over and over. Zero drift, where the tare creeps and every batch carries the same bias until someone starts re-zeroing between batches without realizing they're papering over a real fault. And span error, where the calibration slope has shifted, so small weigh-ups read about right but big ones are off by a growing amount, or the other way round. A single-point calibration will never catch span error, which is why you check it at several points across the working range with certified test weights, not only at some convenient reference down near the bottom. On a dry-batch plant this matters more than it first looks, because the aggregates are often weighed cumulatively on one scale, so a span error shifts every cut in the sequence and preact errors compound down the weigh-up instead of staying put. And you can't hold a tolerance tighter than the scale can read: if the controller's division size is coarse next to the accuracy you're chasing, no amount of adaptive preact saves you, and the answer is a better-resolved scale, not smarter logic.

There's a wiring and grounding layer under all of this that gets overlooked. A load cell signal is millivolts, and it shares a plant with variable frequency drives (VFDs), contactors, and welding. Ground the cable shield at both ends and you've built yourself a ground loop; run the signal alongside a motor feed and you get noise riding on the weight reading that software filtering never fully cleans up. On one job the intermittent readings turned out to be a summing box a third full of water, corroding away quietly behind a cover everyone assumed was sealed. Sometimes the honest diagnosis is that the scale needs a real calibration and a look at its wiring, and the control system is reporting exactly what it's being handed. Software can filter and compensate, but it cannot invent a weight the load cell never measured cleanly.

Aggregate moisture moves the weight and the water at the same time

Here's the one that catches concrete plants specifically, and it's the part a quick read of this problem tends to skip. Sand and aggregate carry free surface water, and that water gets weighed as if it were solid rock. Load a sand target at six percent moisture when the recipe assumed three, and you've put in less actual aggregate than the ticket claims and dumped the extra water straight into the mix, which moves your water-cement ratio without anyone touching the water batcher. It reads at the panel as weights that wander and yield that won't sit still, and no calibration or preact tuning touches it, because the scale is weighing exactly what's on it. The fix is measuring moisture, usually a probe in the sand bin feeding a correction so the batcher trims aggregate and water per batch. A probe that's wrong or uncalibrated is worse than none, because now you're confidently correcting toward a bad number. In a concrete plant, moisture is often the biggest single reason weights and yield drift from one day to the next, and it has nothing to do with the control loop.

Some flow problems are yours to tune and some belong to the millwright

Cement flows one way warm and freshly delivered, another way after it's sat in a silo bridging against the walls. Aggregate flow changes with moisture, with fines content, with how the stockpile was built. A gate that meters cleanly on dry, free-flowing material will surge and stall on damp sand, and a surging feed makes in-flight compensation harder because the mass in the air jumps around from batch to batch.

Some of that is a control problem: a feed rate too aggressive at cutoff, a gate with only fully open and fully shut and no dribble stage, a coarse-and-fine arrangement that should be trimming the last few percent slowly. Those live in the logic and the payoff is consistency. Some of it is mechanical and physical, and loop tuning will never touch it. Sand bridging in a hopper is a hopper, liner, or moisture problem. A worn screw flight is a flight problem. Try to stabilize a mechanically unstable feed with a software change and you'll waste the time, and worse, you'll burn the credibility you need for the fixes that would actually have worked.

What this looks like on a real plant

A dry-batch operation running structural mixes had intermittent low-cement batches, maybe one in fifteen, with no pattern anyone could name. The recipe was fine. The load cells passed a single-point calibration. Everyone decided the weigh system was healthy and started blaming the cement supplier.

Two things were going on at once. The cement preact was a fixed number set years earlier for a full silo, so late in the silo, when flow slowed and in-flight mass dropped, that fixed early cutoff stopped the feed too soon and left the batch light. Only when the silo was low, which is why it came and went and drove everyone up the wall. Underneath that, a two-point check found a small span error that made the shortfall worse on the bigger pours, where more cement went across the scale. Adaptive preact learning free-fall against feed rate cleared most of the intermittent lights, and a proper multi-point calibration took care of the rest. The supplier, as it turned out, had never been the problem. Had the feeder been mechanically worn, none of the logic would have helped and we'd have been talking about a flight replacement instead. That layered kind of diagnosis, working down through the plant until the fault stops moving, is most of what the building materials and cement work I do actually is.

The plain-English version

Consistent batches need a few things true at the same time: an in-flight compensation that adapts to real feed conditions instead of a number frozen at commissioning; a scale calibrated at more than one point, wired so it isn't reading electrical noise, and reading finely enough to resolve the accuracy you want; a moisture correction that's actually right on your aggregate; and a feed mechanically capable of the accuracy you're asking software for. When batches wander, work through those roughly in that order and stay honest about which layer the fault is really in. Preact is usually the cheapest thing to fix and calibration and moisture are the most overlooked, and plenty of times the honest answer is a liner or a worn flight that software was never going to fix in the first place.

If your batch weights have started disagreeing with your paperwork and you'd rather run down the cause than keep blaming the material, get in touch and we can work out where the accuracy is actually leaking.