Automating Quantity Take-Off in AutoCAD with AutoLISP
Automating Quantity Take-Off in AutoCAD with AutoLISP AutoLISP · DCL · CSV
Building a custom estimation tool that reads walls, columns, beams, and openings straight from the drawing — and writes a clean CSV you can open in Excel.
Watch the Tutorial Video Here
If you have ever prepared a bill of quantities from an architectural drawing, you already know the ritual. Open the plan. Measure a wall. Note the thickness. Multiply by the floor height. Write it down. Do it again for the next wall. Then do it for the columns. Then count the doors. Then count the windows. Then do the beams. Then, three days later, the architect issues a revision and you start over.
This is the part of construction estimating that nobody enjoys and everybody has to do. It is repetitive, it is error-prone, and the errors are expensive. A misplaced decimal on wall thickness, a missed window, a beam count that got out of sync with the drawing — each of these can turn a profitable job into a loss.
This post is about a tool I built to fix that. It is a single AutoLISP file that runs inside AutoCAD, reads quantities directly from the drawing, asks you for the information that cannot be extracted (openings and beams), and produces a sectioned CSV report — all in a few seconds. No plugins, no external software, no cloud service. Just AutoLISP.
What follows is a full walkthrough: what the tool does, why it works the way it does, what it does well, where it falls short, and where it could go next.
Manual take-off is not slow because it is difficult. It is slow because it is repetitive, and every repetition carries a risk of small mistakes that compound. Estimating a modest residential floor can involve 200–300 individual measurements. Multiply that across a project, and across the inevitable revisions, and you end up with thousands of small decisions — each of which could go wrong.
Automation does not remove the estimator from the loop. It removes the mechanical parts of the loop: reading areas, multiplying by height, tracking counts, summing subtotals. What remains is what the estimator is actually paid to do — interpret the drawing, decide what counts as what, and apply judgement.
Three specific problems make this tool worth building:
- Revisions. When the drawing changes, the take-off has to change with it. If the numbers come from a script that reads the drawing fresh each time, the revision takes seconds instead of hours.
- Consistency. Two estimators working on the same drawing often produce slightly different quantities — different assumptions about wall length, different roundings. A script applies the same rule every time.
- Auditability. The output is a structured file that shows every item and every formula. When a quantity is questioned, the reasoning is right there in the CSV.
None of this is unique to construction. It is the same reason engineers script repetitive calculations, accountants script reconciliations, and analysts script data cleaning. The specific tools change; the underlying logic does not.
At its core, the tool has one job: turn a DWG file into a quantity schedule. It does that by combining two kinds of information — what can be read from the drawing, and what the estimator types in.
Read from the drawing
- Walls — every hatch on the
wall hatchlayer. The tool reads each hatch's footprint area and its bounding box. The short side of the bounding box is the wall thickness; the long side is the wall length. - Columns — every hatch on the
column hatchlayer. Only the footprint area is needed.
Entered by the estimator
- Openings — doors, windows, ventilations, and anything else. For each type you enter the kind, a label (W1, D1, V1, …), width, height, count, and wall thickness.
- Beams — for each beam type, width, depth, length, and count.
- Floor height — entered once, used throughout.
Written to CSV
A sectioned file with per-item rows, subtotals, and a project summary. It opens directly in Excel and can be plugged into any downstream pricing workflow.
The idea that drives the whole tool is that a hatch is not decoration — it is data. A hatch in AutoCAD is a full geometric object with an exact area, an exact bounding box, and a defined layer. That makes it the ideal container for quantities.
Why not measure wall lines directly? Because walls have thickness. A line has no width. A pair of parallel lines has width, but pairing them up reliably across a drawing is hard — walls meet at corners, doors interrupt them, hatch boundaries are irregular. A hatch sidesteps all of this: it is already a closed region of the wall footprint, and AutoCAD will tell you its area and extent in one call.
The tool uses two dedicated layers:
Layer "wall hatch" → every wall footprint hatched Layer "column hatch" → every column footprint hatched
Because the tool relies on bounding boxes to get wall thickness, it makes one important assumption: walls are rectangular, axis-aligned or perpendicular, and drawn as separate hatch pieces. No L-shapes, no curves, no merged hatches. This is a deliberate constraint. It keeps the code simple, predictable, and fast — and it matches how most plan drawings are drafted anyway.
Here is where the tool does something that is easy to get wrong. Since the wall hatch is drawn around openings — meaning the hatch stops at every door and window — the hatch area represents solid wall only. The opening itself is not part of it.
But openings are not simple holes. Above every window, there is a lintel band of wall. Below every window, there is a sill band. Above every door, there is a lintel. This wall material is real, it costs money, and it has to be counted. It is not part of the hatch, because the hatch has a gap there.
So the tool calculates it separately, per opening, from the values the estimator enters:
| Quantity | Formula |
|---|---|
| Opening area (m²) | W × H × Count / 10⁶ |
| Opening void volume (m³) | W × H × Count × Thk / 10⁹ |
| Full-strip volume (m³) | W × Hfloor × Count × Thk / 10⁹ |
| Wall above/below opening (m³) | Strip − Void |
The full-strip volume is a thought experiment: what if the opening were not there and the wall ran through floor to ceiling? That gives the volume of wall that would exist. Subtract the opening void and you are left with the wall material that does exist — the band above and the band below.
That band volume is then added to the solid wall from the hatch. The result is the true wall volume, correctly accounting for both the solid segments and the material surrounding every opening.
Worked example. One window, 700 mm × 1300 mm, count 2, wall thickness 230 mm, floor height 3000 mm:
Opening area = 0.7 × 1.3 × 2 = 1.8200 m² Opening void = 0.7 × 1.3 × 2 × 0.230 = 0.4186 m³ Full-strip volume = 0.7 × 3.175 × 2 × 0.230 = 1.0220 m³ Wall above/below = 1.0220 − 0.4186 = 0.6034 m³
0.6034 m³ of wall material sits above and below those two windows. That is exactly the volume the hatch cannot see because the hatch was drawn around the openings and it is exactly what the tool adds back in.
The tool uses AutoCAD's built-in DCL (Dialog Control Language). DCL is not modern — it has no themes, no animations, and no fancy layout options. But it works on every full copy of AutoCAD, requires nothing to install, and is more than enough for a form-based estimator.
The tool uses three dialogs. A hub for global settings, and two child dialogs for openings and beams.
┌──────────────────────────────────────────────┐ │ Building Estimation │ ├──────────────────────────────────────────────┤ │ Floor-to-Floor Height (mm): [ 3175 ] │ │ Wall Hatch Layer: [ wall hatch] │ │ Column Hatch Layer: [col hatch ] │ ├──────────────────────────────────────────────┤ │ [ Openings... ] [ Beams... ] │ ├──────────────────────────────────────────────┤ │ [ Generate CSV ] [ Cancel ] │ └──────────────────────────────────────────────┘
Click Openings… and a child dialog opens. It has a dropdown for the kind (Window, Door, Vent, Other), fields for type and dimensions, and a running list of every entry so far. You can add new rows, select an existing row to update it, or delete it outright. Press Back and you return to the hub.
┌──────────────────────────────────────────────┐ │ Openings │ ├──────────────────────────────────────────────┤ │ Kind: [ Window ▼ ] Type: [ W1 ] │ │ Width: [ 2000 ] Height:[ 1500 ] │ │ Count: [ 15 ] Thk: [ 230 ] │ │ [ Add ] [ Update ] [ Delete ] │ ├──────────────────────────────────────────────┤ │ Window | W1 | 2000 x 1300| Qty 15|Thk 230 │ │ Vent | V1 | 850 x 750 | Qty 4 | Thk 120 │ │ Vent | V1 | 850 x 750 | Qty 2 | Thk 230 │ │ Vent | V | 1791 x 750 | Qty 2 | Thk 230 │ │ Door | D3 | 900 x 2100 | Qty 6 | Thk 120 │ │ Door | D4 | 750 x 1800 | Qty 8 | Thk 230 │ ├──────────────────────────────────────────────┤ │ [ Back ] │ └──────────────────────────────────────────────┘
The Beams dialog is the same pattern, with fields for type, width, depth, length, and count. Enter a beam, click Add, and it appears in the list. When you are done, Back returns to the hub.
Clicking Generate CSV on the hub opens a save dialog and writes a multi-section report. It is deliberately sectioned, not one flat table, because a flat table with 200 rows and 12 columns is harder to review than a document split into logical blocks.
BUILDING ESTIMATION Floor-to-Floor Height (mm) WALLS (SOLID, FROM HATCHES) OPENINGS WALL SUMMARY COLUMNS BEAMS PROJECT SUMMARY Item,Quantity,Unit Solid wall volume (hatch),60.7058,m3 Wall above/below openings,17.1795,m3 Total wall volume,77.8853,m3 Opening total area,73.6515,m2 Opening total volume,14.2239,m3 Column volume,19.05,m3 Beam total volume,0,m3
Every section has per-item rows and a subtotal. The project summary at the end gives you the numbers that usually end up on the front page of the estimate.
The tool is not a general-purpose estimating package. It does one thing, and it does it in a way that fits a specific working style. What it does well:
- Speed. A take-off that would take hours by hand takes a few seconds. Adding an opening or a beam takes two clicks; regenerating the CSV takes one.
- Consistency across revisions. Because the drawing data is read fresh every time, revisions are essentially free. Change the walls, re-run, get updated numbers. There is no risk of forgotten manual edits.
- Full transparency. Every number in the CSV has a corresponding formula on the same sheet. There is no hidden engine, no assumptions buried in code. When a quantity is questioned, the arithmetic is visible.
- Zero deployment cost. AutoLISP is built into AutoCAD. No installers, no license fees, no cloud accounts, no IT tickets. A single
.lspfile and a.dclfile, and the tool is running. - Portable. The two files can be copied to any workstation. The saved state (openings, beams, layers) lives next to the DWG, so it travels with the project.
- Excel-friendly output. CSV is the lowest common denominator. It opens everywhere and it can be pasted into any existing template without conversion.
- Auditable by non-programmers. An estimator who has never seen LISP can still read the CSV and check the math. That matters when the output is being handed to a client or a QS.
In practice, the biggest advantage is not the time saved on any single take-off — it is the fact that take-off becomes something you can redo without dread. That changes how often it happens.
Every tool has a boundary. The honest ones are worth stating up front, so that users know where the tool ends and manual work begins.
- Rectangular walls only. Wall thickness and length are derived from each hatch's bounding box. L-shaped walls, curved walls, diagonal walls at odd angles, or multiple wall segments merged into a single hatch will give wrong numbers. The workaround is to hatch each straight wall segment separately.
- No automatic beam detection. Beams are entered entirely by hand. The tool does not read beam lines from the drawing, because beam labels and cross-sections are not reliably carried in CAD geometry. This is a fundamental limitation of relying on raw drawing data.
- No automatic door/window detection. Openings are entered manually for the same reason. Window blocks and door blocks vary too much from drawing to drawing to interpret reliably.
- Single-floor only. The tool handles one floor at a time. A multi-storey building requires running the command once per floor and combining the CSVs manually.
- No unit pricing. The output is quantities only. Rates, costs, wastage factors, and overheads are all outside scope. The CSV is the raw material for a priced BOQ, not a priced BOQ itself.
- DCL is dated. The user interface works, but it is not modern. It has no drag-and-drop, no dark mode, no rich formatting. It is a form with buttons, and that is all it will ever be.
- Layer names are fixed. The tool reads from
wall hatchandcolumn hatch. Layer names are case-sensitive. Non-standard drawing setups require either renaming layers or editing the script. - No drawing-side validation. If a wall hatch is on the wrong layer, or a wall is drawn as two separate hatches when it should be one, the tool will happily produce wrong numbers. It trusts the drawing.
- No revision tracking. The tool does not remember what it produced last time. Every run is a fresh computation.
The obvious alternatives to AutoLISP are .NET plugins, Python via pyautocad, or external tools that read DXF files. Each has trade-offs.
- .NET is faster and produces much nicer interfaces, but requires a compiler, a deployment strategy, and version-matched binaries. Every AutoCAD release can break compatibility. For a tool that will be used by a small team, this is overhead that pays for itself only if the tool is large.
- Python via pyautocad is powerful and pleasant to write, but requires Python, a COM bridge, and careful version management. It works best when the automation lives outside AutoCAD rather than inside it.
- DXF parsing avoids AutoCAD entirely, but loses access to live object data (like hatch areas), and requires re-implementing a lot of geometry that AutoCAD already exposes through one call.
AutoLISP wins because it is already there. It runs inside AutoCAD, in the same process, with direct access to object data. It has a tiny footprint, no compilation step, and no version-compatibility headaches. For a tool of this size — reading hatches, running a dialog, writing a CSV — it is the right level of abstraction.
The tool as it stands is useful, but there is obvious room to grow. The natural next steps, in rough order of value:
- Unit rates and priced BOQ. Add a rate per item (per m³ for concrete, per m² for openings, per unit for doors) and compute extended cost. This is the single biggest jump in usefulness.
- Multi-floor support. Let the tool hold a list of floors, each with its own height and openings, and sum everything into one CSV. Essential for any building over one storey.
- Wall grouping by thickness. Instead of listing every hatch individually, group totals by wall thickness (230 mm, 250 mm, etc.). Cleaner report, easier to price.
- Excel output. Write a real .xlsx file with formulas, so the sheet recalculates when a rate changes. Removes a manual step for anyone who uses the CSV inside Excel anyway.
- Layer auto-detection. Scan the drawing for layer names matching a pattern (e.g.,
wall*,column*) and let the user pick from a list instead of typing names. - Beam auto-length reading. Read beam lines on a
beamlayer and use their lengths as defaults, while keeping the manual entry option. - Saved presets. Remember common opening types (D1, W1, V1) across projects so a new drawing starts with a sensible template.
None of these change the core design. The tool already does the hard part — reading geometry and applying the right arithmetic — and the rest is incremental.
Take-off is not a creative task, but it is a high-stakes one. Errors are silent, they compound, and they surface only when it is too late. Anything that reduces the chance of those errors is worth the effort to build.
This tool is small — a few hundred lines of AutoLISP and a DCL file — and it does not try to do everything. It handles walls, columns, openings, and beams, writes a clean CSV, and stays out of the way. For that specific job, it replaces hours of mechanical work with seconds of automated calculation, and it produces numbers you can defend line by line.
For anyone who regularly prepares quantity take-offs in AutoCAD, a tool like this is not hard to build and it pays for itself on the first revision.