How to Dimension Grids in Revit with Dynamo

Automating grid creation solves half a problem. You run the graph, forty grid lines appear at the right spacing with the right names, and then you sit there clicking each one to build the dimension strings that make the setout sheet legible. On a 22 by 22 grid that is two long strings of manual picks, and you do it again the moment the engineer moves a bay.

Grid dimensions are not decoration. They are the numbers the site engineer measures from, the numbers the steel fabricator checks his shop drawings against, and the numbers the QS uses to sanity check areas. If the grid is parametric and the dimensions are not, then every revision quietly breaks the relationship between what the model says and what the sheet says. That is a coordination problem dressed up as a drafting problem.

The walkthrough below follows a recorded lesson from the Archgyan Revit channel. Every step described as demonstrated is a step shown in the video, with a link to the exact moment it happens. The sections on re-runs, view coverage, dimension strategy and QA are the parts a five minute recording cannot fit, and they are flagged where they start.

This graph starts where the grid graph finished

The lesson is a continuation, not a standalone. It opens a fresh project and switches the units to meters and the decimal places to two before anything else, then opens the existing grid graph from Manage and picks up from there.

Set the units first because the dimension you are about to generate reads back in project units. A grid drawn correctly but displayed at four decimal places produces strings like 6.0000, and the moment a value lands slightly off you get 5.9998 across the sheet with no idea whether that is a real modelling error or a rounding artefact. Two decimal places in meters is tight enough to expose a genuine mistake and loose enough to stay readable at 1:100.

The graph being extended already builds both grid sets from a start point and an end point and renames them in one pass. If you have not built that one, start with the companion walkthrough on creating and renaming grids in Revit with Dynamo, because everything below wires into its outputs.

The gap the first graph leaves

Run the existing graph and the grids appear, correctly spaced and correctly named. Then the recording makes the point that justifies the whole lesson: you still have to click on each grid individually to create the dimensions.

This is the part people underestimate. Placing the grid is the fast half. Dimensioning it is the slow half, and it is the half that has to be redone from scratch after a revision, because a Revit dimension string picks up the specific references it was drawn against. Delete and regenerate the grids and the strings do not follow. They break or they vanish.

Grid.Curve converts a Revit grid into Dynamo geometry

The first new node in the graph is a search for Grid.Curve, plugged into the output of the grid creation node. It returns the underlying line of each Revit grid as Dynamo geometry.

Understand what that boundary is doing, because it is the concept that makes the rest of the graph readable. A Revit grid is a database element with a name, a type, extents and view-specific visibility. Dynamo cannot measure it, sort it or take a point off it directly. Grid.Curve hands you the geometry underneath, and geometry is something you can interrogate: start point, end point, length, direction. From here the graph is doing pure geometry work, and it only touches Revit again at the very end.

Dimension.ByElements is the node that does the work

The end node is Dimension.ByElements, searched for by name in the library. It creates a real Revit dimension from a set of elements. Five inputs get wired in the lesson, listed below in the order the recording works through them rather than in port order:

Input	What it takes	Why it matters
`line`	The line the dimension string sits along	Position only, not what is being measured
`view`	The view the dimension is placed in	A dimension is view-specific, so this decides where the string appears
`elements`	The elements being dimensioned	Here, the grids straight from the grid creation node
`suffix`	Text placed after the value	Maps to the dimension’s own text field
`prefix`	Text placed before the value	Same, on the other side

The recording is also explicit that two of these nodes are needed, not one: one for the horizontal grid set and one for the vertical. The horizontal grids carry a vertical dimension string and the vertical grids carry a horizontal one, because you are measuring across the run of the lines, not along them.

That mirrors how you would dimension by hand. It also means the graph ends up as two identical clusters rather than one clever one, which is a good thing. Two readable clusters beat one that nobody else on the team can unpick.

Build the witness line from the grid start points

The line input is where people get stuck, so it is worth being precise: the line does not define what gets measured. The elements input does that. The line defines where along the drawing the dimension string lands.

The graph builds it out of the grids themselves. It takes the start point of every grid curve, which returns a list with one point per grid. A dimension string needs a single line, not a list of points, so the graph takes the first point and the last point and joins them using first item and last item from the list, then feeds both into Line.ByStartPointEndPoint.

The result is one line running from the first grid to the last grid, exactly parallel to the direction being dimensioned. Because it is derived from the grid points rather than typed in, it stretches automatically when the grid count or the spacing changes. There is no hardcoded coordinate anywhere in this branch, which is the whole reason it survives a revision.

Wire the view, the elements and the text fields

With the line built, the rest of the wiring is quick. The graph plugs the line in, then supplies a view, picking Level 1 as the view the dimensions are created in. The elements input takes the grids straight from the grid creation node.

Then the two inputs everyone skips. The recording pauses to explain that prefix and suffix correspond to the text fields on the dimension itself: double click a dimension in Revit and you see the same fields, one reading before the value and one after. In this graph they are left empty because a grid setout string wants a bare number.

They are not useless, though. A prefix or suffix is how you would push a note like TYP or a unit marker onto every string in one pass, which is otherwise a per-dimension edit. If your office standard calls for that annotation, this is the cheapest place in the whole workflow to apply it.

Run it, then mirror the cluster

Run the graph and the dimensions appear across all the grids at once. One direction is done.

The second direction is not new work. The graph copies the same cluster of nodes down and re-points them: the other grid set into elements, the other line into line, the same view. Run again and both dimension strings are there.

The last step in the recording is housekeeping, and it earns its place: the finished nodes are grouped and the group is named. A Dynamo graph with three named groups is something a colleague can open and follow. A graph with sixty loose nodes is something they will rebuild from scratch rather than try to read, which defeats the point of automating it.

Not in the video: understand element binding before you re-run

This is the behaviour that decides whether re-running the graph is safe, and it is the direct counterpart to the freeze-the-nodes problem in the grid graph.

When a Dynamo node creates a Revit element, Dynamo records a binding between that node and the element it made, and it saves that binding into the graph file. Re-run the same graph and Dynamo generally finds the bound element and modifies it rather than creating a second one. That is what stops a graph from littering the model every time you press run, and it is why a well-behaved graph can be tuned live.

The problem is that the binding is fragile, and the things that break it are ordinary. Open a copy of the graph rather than the original and the binding does not point at your elements. Copy a cluster of nodes to build the second direction, which is exactly what this lesson does at the point where the cluster is duplicated, and the new nodes have no binding at all. Delete the dimensions in Revit by hand and the binding points at nothing. In each of those cases the next run creates fresh elements, and if the old ones are still there you get two strings sitting on top of each other, visually identical to one, and both print.

So treat it as a thing to verify in your own model rather than assume, and work defensively:

Freeze the dimension nodes while you tune the geometry. Right click and freeze, adjust the sliders until the grid is right, then unfreeze and run once. Nothing is created while you iterate, so there is nothing to bind or duplicate.
Treat the dimension pass as terminal. Get the grid layout signed off first. Dimensioning is the last thing the graph does, not something you iterate on.
Work in the original graph file. Re-running a saved copy is the most common way people lose the binding without realising it.
Check the count, not the look. After a run, select all dimensions in the view and read the count off the status bar. Two strings on a two-direction grid. Anything higher means the binding did not hold and you are looking at duplicates.
If duplicates appear, delete and run once. Select the existing strings in the view, delete them, then run a single time. It is the only reliable reset.

Not in the video: one view input means one view

The graph places dimensions in a single view because view takes a single view. The recording uses Level 1, which is right for a demonstration and wrong for an issue set.

A real drawing package carries grid dimensions on every plan you publish, plus the setting-out plan, plus usually the roof and any mezzanine. That is five to ten views, and the graph as built covers one of them. Three ways to close that gap, in ascending order of effort:

Run the graph per view. Change the view input, run, repeat. Crude, but it works today and needs no extra nodes.
Feed a list of views. The node accepts one view per dimension created, so passing a list means understanding how Dynamo pairs the inputs across lists. It is the correct fix and it is the point where this graph stops being a beginner graph.
Dimension once and use a view template plus dependent views. Often the better answer for a repetitive plan set, because it moves the problem out of Dynamo and into the view management you should be doing anyway.

Decide before you generate. Dimensions spread across ten views by hand are ten times the cleanup if you get the strategy wrong.

Not in the video: overall or individual, and when to use each

This graph produces one dimension string per grid set, driven by the elements you feed it. What you actually need on a sheet depends on who is reading it.

Dimension type	What it shows	Use it for
Individual bay	Each grid to the next	Setting out, structural coordination, the working plan
Overall	First grid to last	Envelope checks, site boundary offsets, the general arrangement
Both, stacked	Bay string with an overall string above	The setout sheet the site engineer actually works from
Alternate grids only	Every second line	Dense grids where a full string becomes unreadable at scale

The graph handles the first case natively, since it hands every grid in the set to the elements input. The others are a list operation before that input: filter the list to the first and last grid for an overall string, or take every second item for an alternate string. That is a single node in front of an input you have already wired, which is a fair illustration of why building the graph properly the first time pays off.

Not in the video: check these before the sheet goes out

Automation moves the error from drafting to setup. The failure mode is no longer a mis-picked reference, it is a graph that ran correctly against the wrong assumption. Five checks:

Dimension count per view. Select all dimensions and compare against what you expect. Catches the duplicate-string problem before print.
The values against the engineer’s grid. Read three bays off the sheet and check them against the source drawing. The graph is only as right as the spacing slider that fed it.
String position. The line is built from the grid start points, so the string sits at the start of the grid run. If your title block or a view crop clips it, the fix is an offset applied to the line, not a manual drag of the dimension.
Dimension type. Generated dimensions inherit the view’s current default type. If your office standard expects a specific type on setout sheets, set it before running or expect a select-all-and-swap afterwards.
Behaviour after a grid edit. Nudge one grid and watch what the string does. A dimension created against grid elements should follow. If it does not, it was created against the wrong thing.

Common mistakes

Mistake	What you see	Fix
Re-running after the element binding is broken	Bold-looking dimension text, two strings stacked as one	Freeze the dimension nodes until the layout is final, then check the count
Feeding the point list straight to `line`	Node errors or nothing is created	The input needs one line, so reduce the list to first and last, then build the line
Assuming `line` controls what is measured	Values that do not match the grid	`elements` controls the measurement, `line` controls placement
Using one dimension cluster for both directions	Only one string appears	The two directions need separate clusters, each with its own line
Setting units after generating	Strings at four decimal places, unreadable values	Units and decimal places first, before the graph runs
Leaving the graph as loose nodes	Nobody, including you in six months, can maintain it	Group and name each cluster before saving

Where this fits in a real workflow

On its own, a grid dimension graph saves maybe fifteen minutes. Chained to the graph that creates and names the grids, it turns the engineer’s revision from an afternoon of redrafting into a slider change and one run. That is the pattern worth learning from this lesson, more than the specific node names: build small graphs that hand off to each other, group them so they stay readable, and be deliberate about which steps are safe to re-run.

The same shape shows up across the rest of the Dynamo basics on this channel, from creating levels with Dynamo to driving sheets from an Excel list. If you want the wider view of what is worth automating first, the roundup on using Dynamo to automate repetitive Revit tasks covers the decision rather than the mechanics.

For the full progression from Revit fundamentals through families, documentation and coordination, taught by a working BIM Coordinator, browse the Archgyan course library.