How to Create and Rename Grids in Revit with Dynamo

The structural engineer sends the grid layout on a Tuesday. It is 22 lines one way at 12m and 22 the other, and you draw them by hand because that is what everyone does. On Friday the layout comes back with the bays at 6m instead of 12, and the grid you drew, named, aligned and dimensioned is now the wrong grid. You do it again.

Grids are the coordinate system every other discipline references. Structure locates columns off them, MEP locates risers off them, the contractor sets out on site off them, and every section mark, view title and dimension string in the set eventually points at one. Drawing them is not hard. Redrawing them, and renaming them correctly, and doing it a third time when the engineer revises the bay spacing, is where the hours go.

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. The sections on naming conventions, grid extents, QA and the re-run trap are the parts a seven minute recording cannot fit, and they are flagged where they start.

Set the units before you open Dynamo

The first move in the video happens in Revit, not in Dynamo: switch the project units to meters before starting anything. The reason given is that you end up typing fewer digits and the numbers stay cleaner to work with.

There is a mechanical reason to care as well. Dynamo’s Revit nodes read and write length in the document’s display unit, so a slider set to 12 means 12 of whatever the project is currently using. Build the graph in millimetres and your spacing slider needs a range in the thousands with a step to match. Build it in meters and the same slider runs 0 to 100 with a step of 1, which is a range you can actually drag.

Set this first. Changing units after the sliders are configured means going back and re-ranging every one of them.

The nodes the graph needs

Open Dynamo from Manage, then start a blank graph. The video builds the whole thing from scratch rather than opening a finished file, which is the right way to learn it, because the wiring is the part that transfers to your next graph.

Right click on the canvas to search for nodes. The set the graph uses:

Node	Job
Number Slider	The four inputs: spacing and count, for each direction
Code Block	Turns count and spacing into a list of coordinates
Point.ByCoordinates	Builds the start and end point of every grid line
Grid.ByStartPointEndPoint	Creates the actual Revit grid element
Grid rename node	Applies A, B, C to one set and 1, 2, 3 to the other

Four of those five ship with Dynamo. The rename node does not. It comes from a third party package installed through Dynamo’s Package Manager, and the video shows which one on screen when it is searched for. That is the single dependency in the graph, and it is worth installing on the machine of anyone on the team who will run it, because the graph fails on a missing node rather than degrading gracefully.

The other habit worth copying: hover over an input before you wire it. Hovering start on the grid node tells you it wants a point, which is what sends you looking for Point.ByCoordinates in the first place. That is how you work out what a node needs without reading documentation.

The code block that turns two sliders into a row of coordinates

This is the piece that does the real work, and it is one line. Double click the canvas and write a range that starts at zero, takes the number-of-grids slider as the item count, and the spacing slider as the step.

The syntax detail that matters is the #. In DesignScript, 0..x..y reads x as the end value of the range, so you get however many items happen to fit between 0 and x at step y. Writing 0..#x..y reads x as a count, so you get exactly x items, spaced y apart, no matter what y is. For a grid you almost always want the count form. You know how many gridlines the engineer asked for; you do not know, and should not have to calculate, where the last one lands.

Set the sliders up as you create them. Rename them to something readable such as “horizontal grid spacing” and “horizontal number of grids”, and set the step to 1 with a max around 100. A slider named Number Slider is useless six months later; a slider named “horizontal number of grids” is a working interface.

Why the first run produces nothing visible

Feed the range into the first Point.ByCoordinates and the graph runs, but nothing useful appears. The video hits this deliberately.

Horizontal grids run along X, so the varying coordinate is Y. Plug the range into Y and leave X empty, and you get a column of points at the right spacing. Wire that same range into the second Point.ByCoordinates, and both points of every grid land on the identical coordinate. A line from a point to itself has no length, so the grid either fails or collapses.

The fix is a second slider giving the end point an X value, which is the grid’s length. But a fixed length is a trap: set it to 22 and it stops matching the model the moment you add more grids in the other direction.

So multiply instead. Grid length becomes number of grids times spacing, taken from the perpendicular direction’s sliders. Now the horizontal grids automatically span the full width of the vertical set, and they keep spanning it when either number changes. That one multiplication node is the difference between a graph that draws a grid once and a graph that stays correct.

Turn on the background preview at this point to see the points in the graph view before committing anything to Revit. Debugging geometry in Dynamo’s own viewport is far faster than creating elements, checking Revit, deleting them and running again.

The second direction, with two wires swapped

The vertical set is the same five nodes with the coordinates exchanged. Duplicate the sliders, rename them “vertical grid spacing” and “vertical number of grids”, and this time the range drives X while the length drives Y.

Getting this backwards is the most common wiring error in the graph, and the symptom is unmistakable: both sets of grids come out parallel instead of crossing. If that happens, you have wired the range into the same axis twice.

Once both point pairs exist, feed them into the start and end inputs of the grid node and run. The grids appear in Revit.

Push the grids past the corner with a negative offset

The first real result has two problems, and the video names both: the sets collide at the origin and the names are wrong.

Because both directions start at 0,0, the first horizontal grid begins exactly where the first vertical grid begins. The lines terminate on each other and the grid heads stack up in the same corner, which is unreadable on a drawing.

The fix is to start each line short of the intersection. Add an offset slider and a multiplication node set to minus one, then feed that negative value into the origin coordinate. Every grid line now begins outside the grid rather than on it. Apply the same treatment at the far end so the lines overhang on both sides.

This is not cosmetic. Grid bubbles that sit inside the building footprint get hidden behind walls and title blocks, and every drafter downstream drags them out by hand, once per view.

Freeze the geometry nodes while you are still building

Here is the trap that catches everyone, and the reason the video right clicks the grid nodes and freezes them while working on the rename logic.

Dynamo does not update the grids it made last time. It makes new ones. Grid.ByStartPointEndPoint creates elements. Run the graph three times while tuning a slider and you have three complete grid sets stacked on top of each other in the model, most of them invisible because they sit on identical lines. You find out later, when the grid schedule shows 66 entries instead of 22, or when a section mark snaps to a grid that nobody can select.

Freezing a node suspends its execution so the rest of the graph still evaluates. Freeze the two grid nodes, get the rename inputs right, then unfreeze and run once. If you have already run it several times, delete every grid in the model before the clean run rather than trying to sort the duplicates out.

The rename, and why it needs a temporary name

The rename is the half of this graph that saves the most time and looks the most cryptic. Both grid sets are wired into the rename node, then a code block supplies the string inputs: a sort axis, a temporary prefix such as _temp, an alphanumeric string, and two booleans.

The temporary prefix is the part worth understanding, because it is solving a Revit constraint rather than a Dynamo one. Revit will not allow two grids to share a name. If your existing grids are named 1 through 22 and you rename them A through V one at a time, the sequence collides partway through: the moment the script tries to write a name that another grid still holds, Revit rejects it and the run fails.

The two pass approach steps around it. Every grid is first renamed to a temporary, guaranteed-unique string, which frees the whole namespace. Then the real names are applied to a clean slate. That is why a prefix input exists at all, and why the boolean controlling it is switched on.

The other two inputs control direction. The sort axis tells the node which coordinate to order the grids by before numbering them, and the reverse boolean decides which end the sequence starts from. Leaving reverse false numbers from one end; flipping it renumbers from the other. Get this wrong and the grid reads right to left, which is a real problem once dimension strings and sheet references exist.

Unfreeze the nodes, minimise Dynamo and run. The grids offset and rename in a single pass, visible live in Revit.

Make it parametric, then actually use that

With both directions matching, you get a square grid. The payoff comes when you switch Dynamo from Manual to Automatic and drag a slider. The grid count changes and the model follows. Change the spacing and it follows again. You can type values directly into the slider fields rather than dragging, which is what you want when the engineer’s number is 7.5 and not something you can hit with a mouse.

Be careful with Automatic mode on this particular graph, though, given what the previous section said about element creation. Automatic mode plus an element-creating node means a fresh grid set on every slider tick. Use Automatic while the grid nodes are frozen to preview the point layout, then switch back to Manual and run once to commit.

Manual grids, this graph, or a template

There is a real choice here and it depends on how often the layout moves.

Approach	Setup time	Cost of a revision	Fails when
Draw and rename by hand	15 to 30 min	Redraw, rename, re-dimension, roughly the same again	Every revision
This Dynamo graph	20 min once, 1 min per project after	Change a slider, delete the old set, run	Spacing is irregular between bays
Pre-gridded project template	Near zero	You are back to editing by hand	Every project has a different grid

The graph assumes even spacing, which is its real limit. A layout with 8m bays at the podium and 12m in the tower does not come out of two sliders. For that, feed the code block a written list of coordinates instead of a range, or run the graph twice with different sliders and different offsets. The template option only wins on repeat typologies where the grid genuinely never changes.

What to do after the script finishes

The video ends when the grids appear correctly named. On a live project, four things happen next, and none of them are automated by this graph.

Pin them. Grids and levels are the two element types most often moved by accident. Select all of them and pin immediately after creation, before anyone else opens the model.

Check the 3D extents. Dynamo creates the grids at the elevation of the current work plane. They are model elements with a vertical extent, and if that extent does not cover every level, the grid vanishes from upper floor plans. Open a section, select a grid, and drag its extents to cover the full building height.

Propagate 2D extents. Grid bubble positions are per view. Set the crop and bubble positions right in one plan, then use Propagate Extents to push that to every other plan view rather than adjusting 30 views by hand. The bubble itself is an annotation family rather than a graph setting, so its shape, its colour and its label text are all edited in the grid head family.

Add scope boxes if the building is large. On a project split into zones, assign the grids to scope boxes so each plan region shows only its own grids.

Naming conventions, decided before you run the graph

Renaming grids after the model has been developed is genuinely expensive, because grid names are copied into places that do not update: dimension string references in views, sheet notes, the structural engineer’s own model, RFIs already issued, and setting-out drawings already on site. The name you generate on day one tends to be the name for the life of the project.

Two rules cover most offices. Letters run one direction and numbers the other, conventionally letters on the vertical grids and numbers on the horizontal ones. Sequences skip the letters that read as digits, so no I and no O. Beyond that, check the project’s BIM Execution Plan or the client’s national annex before running the script, because some clients mandate the direction letters run and where the sequence starts. Changing the sort axis and the reverse boolean before the first run takes two seconds. Changing them after coordination has started takes a week.

Common mistakes

Running the graph more than once. Every run creates a new grid set. Delete the previous grids before re-running, or freeze the creation nodes while tuning.
Building the graph in the wrong units. Sliders configured for meters produce a 22mm grid in a millimetre project.
Wiring the range into the same axis twice. The two grid sets come out parallel instead of crossing.
Skipping the temporary prefix. The rename fails partway through with a duplicate name error and leaves the grid half renamed.
Fixing the grid length as a number instead of multiplying. The graph looks parametric and quietly stops matching the model as soon as a count changes.
Forgetting the vertical extents. The grids look perfect in the plan you were working in and are missing from every other level.
Not pinning. A dragged grid on a coordinated project is a coordination issue, not a modelling one.

Where this fits in a Dynamo workflow

Grids are one piece of project setup. The same pattern, sliders driving a code block driving an element creation node, is what runs behind creating levels with Dynamo and behind generating sheets from an Excel list. Learn the wiring once and the third graph takes an afternoon. If you want the broader picture of what is worth automating and what is not, the overview of Dynamo for repetitive Revit tasks covers the decision.

The natural next step on the grid itself is dimensioning it, which the video flags as its own follow up. Grid dimension strings are the other job nobody wants to do 40 times, and the follow-up graph in dimensioning a Revit grid with Dynamo picks up exactly where this one stops, reading the grids this script created and dimensioning the whole run in one pass.

If you would rather learn this in order, with the project setup, families, documentation and coordination workflows in sequence rather than as scattered tutorials, the full Revit course on Archgyan builds the same skills against a real project model.