Sawmill Production and Lumber Recovery Software: Why Can Nobody Tell You What You Made From Tuesday's Logs?

Why a mill that measures everything still cannot state its recovery

Logs arrive by the truckload and are paid for by weight or by scale. They are bucked, scanned, and turned into solutions by an optimiser that makes thousands of geometric decisions an hour. Boards leave the green chain, get stacked and stickered, go into a kiln for a couple of days, come out lighter and slightly smaller, then run through the planer where a grader decides what each piece is actually worth. At every one of those points a number is produced. At the end of the month somebody assembles a recovery figure that everyone treats with polite scepticism.

The reason is that the units change identity along the line and nobody maintains a single volume model. Logs are measured in cubic metres or in a scaling rule that estimates board feet. Green lumber is counted in nominal dimensions. Kiln drying shrinks it. The planer produces a final tally in graded pieces. Comparing the last number to the first requires a chain of conversions, and each mill does those conversions slightly differently, sometimes differently between shifts.

The systems in the building are largely machine centric. USNR, Autolog and BID Group Comact supply scanning and optimisation, and their software is excellent at deciding how to break a log and reporting on the machine centre it controls. That is what it is for. What none of them provides is a mill wide ledger that follows volume and value from the log purchase through to the graded package, because that crosses their boundaries and involves the kilns, the planer and the accounting system.

The result is a mill that can tell you the optimiser solution value for a log at the primary breakdown and cannot tell you what you actually sold from that log six weeks later.

Problem 1: recovery is a definition problem before it is a data problem

Ask three people at a mill how recovery is calculated and you will get three answers that differ in whether green or dry volume is used, whether trim allowance is included, whether the planer downgrade is counted against recovery or against grade outturn, and whether chip and residual value enters the calculation at all. None of them is wrong. They are just not the same number, which means the mill cannot compare shifts, months or suppliers with any confidence.

What a custom build does: fix one volume model and derive everything from it. Every measurement point converts into a canonical unit with an explicit, documented rule, and every reported figure states which basis it uses. Once that exists, the arguments stop and the numbers become comparable. This sounds administrative and it is the single highest value thing the project does, because every subsequent analysis depends on it.

Problem 2: scanner and optimiser data lives inside the machine

Your primary breakdown optimiser knows the scanned geometry of every log, the solution it chose and the theoretical yield of that solution. The edger and trimmer know their own decisions. That data is the richest thing in the mill and it usually stays inside the machine, exported as shift summaries at best.

Capturing it changes what you can ask. Theoretical yield versus actual green output tells you whether the sawline is achieving its own solutions, which is a maintenance and setup question rather than an optimisation question. Solution value by log class tells you whether the log purchasing specification still matches what the mill does well.

What a custom build does: an acquisition layer per machine centre, normalising into one event model, then joining the optimiser solution to the pieces that actually came off the line. Vendors expose data differently and older installations may need a database read or a file drop, so expect this to be real work. It is also where the analytical payoff sits, because everything downstream is coarse by comparison.

Problem 3: kiln charges destroy lot identity

A kiln charge is built from whatever packs are available, which routinely mixes production from several shifts and sometimes several days. After drying, the identity of what went in is largely gone, so any attempt to attribute planer grade outturn back to a specific log class or shift runs into a mixing problem at the kiln.

Most mills give up here, which is precisely why the grade outturn conversation is never resolved. Grading is where the value is decided, and if you cannot connect it back to the sawline and the log, you cannot improve either.

What a custom build does: track charge composition at pack level, so a charge is a set of packs each with a known origin, and grade results at the planer are attributed proportionally back through the charge to the shifts and log classes that contributed. It is an estimate rather than a certainty, and an honest estimate beats the current position of no answer at all. Pack level barcoding or tagging is usually needed to make this work, and that operational change is often a bigger hurdle than the software.

Problem 4: you buy logs on one basis and cut them on another

Log purchasing is a commercial function that depends on data the mill floor holds. Paying by weight means moisture and species affect what you actually got. Paying by scale means the scaling rule estimate may consistently differ from what your mill recovers from those logs. Either way, the useful question is recovery and value by supplier, by log class and by season, and almost no mill can answer it without a manual project.

What a custom build does: reconcile purchase records against actual outturn. Every delivery becomes a lot with its measured input, and once recovery attribution exists through the kiln, the mill can rank suppliers and log classes by realised value rather than by purchase price. The frequent discovery is that a log class the mill has avoided as too small is actually strong on value once grade outturn is counted, or that a favoured supplier is expensive relative to what their logs deliver. That is a purchasing conversation worth several times the software cost.

Problem 5: downtime and setup are recorded on a clipboard

Availability at the sawline sets how much of the shift is producing, and most mills record it as a stop reason written by a supervisor. That produces a Pareto chart that is mildly useful and easy to dispute.

What a custom build does: derive downtime from machine state and production flow automatically, then ask the supervisor only to classify the gap, ideally on a tablet at the line. Duration comes from the machines, cause comes from the person, and the resulting analysis is not arguable. Joining downtime to recovery matters too, because a mill running hard after a stoppage often makes worse decisions at the trimmer, and that shows up in grade outturn a week later.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, a sawmill first release runs $70,000 to $150,000 in 12 to 18 weeks. That covers the canonical volume model, acquisition from your primary breakdown and edger or trimmer optimisers, green output capture, and recovery reporting by shift and log class with a documented basis. It is a system the mill manager reads every morning. The full platform, adding kiln charge composition, planer grade attribution, log purchase reconciliation, downtime capture and finished goods inventory with grade and package tracking, runs $180,000 to $420,000 phased over 6 to 14 months.

Cost drivers specific to a sawmill:

• The number of machine centres and how many different vendors supplied them, since each acquisition integration is its own piece of work.
• Whether pack level identification exists, because attributing grade outturn back through kilns requires it and introducing barcoding is an operational project as well as a software one.
• Species and grade rule complexity, since a mill running several species to different grading rules carries more configuration than a single species mill.
• Whether log purchasing data is in an accounting system with an interface or in a stack of scale tickets.
• Multi site rollout, where scaling practice and grading conventions differ between mills in the same group.

What keeps cost down: start at the sawline and the green chain. Recovery from log to green output is achievable quickly and pays for the kiln and planer work that follows.

Build versus buy, and what the equipment vendors do well

Keep buying optimisation from USNR, Autolog or Comact. Their scanning and solution software is the core competitive technology in your mill and no software house should be attempting to replace it. If your problem is that your primary breakdown is making poor decisions, that is an equipment and setup conversation, not a data one.

Build when two or more of these are true. Your recovery figure is compiled manually and different people compute it differently. Your optimiser data never leaves the machine, so you cannot compare theoretical yield with actual output. You cannot attribute planer grade outturn back to log class or shift because the kiln mixes everything. Your log purchasing decisions are made on price and reputation rather than on realised value per class. You run more than one mill and cannot compare them because each defines its terms differently.

The threshold is throughput times variability. A small custom mill cutting to order does not need this and should not spend the money. A mill cutting tens of millions of board feet with a varied log supply has a recovery question worth real money, and a single point of improvement in recovery across a year usually dwarfs the cost of building the system that found it.

How to choose a developer for sawmill software

Ask them how they will define recovery. If they take your existing definition without asking which basis it uses, they have not understood the problem, and the system will produce a number as disputable as the current one.

Ask how grade outturn will be attributed through a kiln charge that mixes shifts. If the answer avoids the mixing problem, the build will stop at the green chain and the most valuable analysis in the mill will never happen.

Ask which optimiser and scanner systems they have read data from, by vendor and vintage. Some installations expose a database, others a file export, and older machines may require working with the vendor. Ask for the mill and the machine, not a general claim about industrial data.

Ask what they need from the floor. Honest answers include pack tagging, a tablet at the sawline for downtime classification, and a discipline about kiln charge recording. A developer who says no operational change is required is either not building the useful version or has not thought it through.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit, and since the volume model encodes how your mill defines its own performance, owning it is the whole point.