AR20422 Everyday Dynamo: Automating Simple Solutions That ...aucache.autodesk.com/au2016/sessionsFiles/20422/12226/handout... · Everyday Dynamo: Automating Simple Solutions That

Updated Handout Download (Click to Download) Page 1 of 1

AR20422

Everyday Dynamo: Automating Simple Solutions That Bridge Workflow Gaps Within Revit Josh Moore, Design Applications Manager Perkins+Will Justin Benjamin, Design Applications Manager Perkins+Will

DESCRIPTION Are you a Building Information Modeling (BIM) manager seeking to increase the efficiency of your company and project teams? Are you a model manager struggling through workflow issues? Or maybe you’re neither of those, but you work in Revit software every day and want to learn ways to work smarter. This class will focus on using visual programming in the Dynamo extension to bridge everyday workflow gaps within Revit software. The class will provide a brief overview of Dynamo and the many available packages that the Dynamo community has already created that can be used to automate many tasks. The class will also go over some basic tips and tricks you can use when setting up Dynamo, and we’ll go over basic troubleshooting tips. The remainder of the class will focus on specific examples that bridge workflow gaps and/or increase automation within Revit software. Example scripts will include the following: finding annotation styles within legends for model cleanup; coordinating dummy view tags across linked models; slab edit floor to match topography; as well as samples of other scripts such as swapping ceiling-based lights for face-based lights. This session features Dynamo Studio and Revit. AIA Approved

LEARNING OBJECTIVES • Increase awareness and familiarity with Dynamo visual programming nodes

and packages • Learn some tips and tricks when working with Dynamo and troubleshooting

techniques on scripts that fail • Recognize when Dynamo can save you valuable time on projects • Discover simple and innovative ways to bridge workflow gaps in Revit

https://www.dropbox.com/s/b5amk5tgpz2tl20/AR20422-Moore-AU2016.pdf?dl=0


YOUR AU EXPERT(S) Josh Moore is a design applications manager at Perkins+Will, where he is responsible for support, training, and development of all design applications in use. In particular, he is regularly engaged by design teams and leadership for his expertise in executing successful Building Information Modeling (BIM) / Revit software projects. While at Perkins+Will, his efforts have focused on implementing and improving Revit software content and workflows. He is passionate about understanding the process of architecture and translating it into practical and successful uses of design technology. Josh earned a bachelor’s degree in architecture in 2007, and is a CSI Construction Document Technologist (CDT) and a Revit Architecture Certified Professional. He has spent more than 11 years in the architectural industry, including 8 spent performing project work and BIM management. Additionally, he is the owner and operator of revitinfo.com, and he enjoys visual scripting with the Dynamo extension. Josh resides in Plano, Texas, with his wife and 3 children and teaches Design Applications at Wade College Interior Design Program as an adjunct professor. Justin Benjamin has been the Design Applications Manager in Perkins+Will Washington, DC office for over 3 years. He has an additional eight years of experience in the architecture and engineering industry (combining his design studio experience with design applications expertise). He has been Autodesk Revit Architecture Certified Professional and guided project teams through their required applications in all phases from programming through construction. Justin also has extensive expertise in Building Information Modeling and Computer-aided Facility Management systems. He works with various types of clients in integrating models and data within their organizations. In addition, Justin teaches Construction Documents at Marymount University as an adjunct professor.



INTRODUCTION There is so much information to consider when looking at the design and construction of a building, it's really quite mind boggling. The design team is challenged with not only considering aesthetics, but also managing and acting on a vast amount of additional information/requirements. Additionally, pile on the technology associated to accomplishing all of those things. With so many technology options and the speed at which they change, it becomes more and more difficult to keep up and we are constantly looking for ways to help automate some of the more repetitive and monotonous (but necessary) processes so that there is more time in the design process to add value and tackle the vast amount of considerations that go into a building. Enter Visual Scripting with Dynamo. While a large portion of the community has focused on how visual scripting can be used for computational designing/complex form finding, there is a huge untapped potential in using visual scripting to bridge everyday workflow gaps when using Revit. At Perkins+Will, we call this Process Automation, a subset of our Computational Design Efforts. At first glance, learning how to use visual scripting can seem to be a daunting undertaking. After all, one of the hardest things to learn with visual scripting is the “language”. Outside of the example scripts and process insight this class will provide, it will additionally attempt to help lessen the learning curve by providing useful examples of how to “speak the language” in Dynamo.

SETTING THE CONTEXT I should preface the following few sections with a disclaimer. I am not a computer programmer and have no formal education in this area. However, in the research and time I’ve spent trying to understand it for myself, I’ve found ways to understand Visual Programming that seem to make sense to me and other folks I’ve attempted to explain it to. Thus, when trying to explain visual programming to designers with no “coding” or computer science experience like myself, I like to try to give pop culture examples that help us understand.

WHAT IS PROGRAMMING?

THE MATRIX



When thinking about programming, I like to compare it to the movie “The Matrix”. The Matrix was a dream world created by machines, really a big program that machines used to trick people into believing it was their reality. The Matrix (code) was “all around them”. When we are writing a program, we are writing in a “language” (code) which tells a computer what we want it to do. Additionally, we are defining the process by which the computer will perform tasks.

ALGORITHMS When I first heard the term algorithm, I thought it was a complex term meant for super smart computer science guys, hackers, programmers, etc. However, it’s actually a very easy term to understand and apply.

On an episode of the Big Bang Theory, Sheldon needs to gain access to a university computer, which happens to be controlled by his nemesis, Kripke. In an effort to gain access to the computer, Sheldon decides to write an algorithm which would define his

process for becoming friends with Kripke. In this case, Sheldon really just diagrammed a process of “if this, then that” to help him solve his problem.

This is sometimes referred to as a PROCESS MAP.



ANY ALGORITHM, IN THE MOST BASIC SENSE, IS A PROCESS MAP. In the most basic sense, when programming, we are doing the same thing. We are defining algorithms, or a series steps, by which the computer can evaluate and perform a task(s). WIKIPEDIA DEFINES THE TERM “ALGORITHM” AS “A PROCESS OR SET OF RULES TO BE FOLLOWED IN CALCULATIONS OR OTHER PROBLEM-SOLVING OPERATIONS, ESPECIALLY BY A COMPUTER.” (WIKIPEDIA, 2016). Our bodies are incredible examples of programming and algorithms. Our bodies are constantly processing input information and responding to that information in an output of some sort. This happens at the macro and micro scale. The steps our bodies take are embedded into our very existence and crucial to the proper function of our body. Another way to think about the programmer’s role in the process, is to think about how a parent often “translates” for their children.

When you are writing a program, you are interpreting the problem, process and desired outcome in a way that a computer can understand and solve, in the same way that I have to translate what my son is saying for other people to understand.

My son would say all kinds of things that I could understand, but not everyone else would immediately be

able to understand. He would say “No-wee” which means “Another one”. He would say “Tutu-shew”, which

would mean “Ninja Turtle Shoes”.



THE DYNAMO/REVIT RELATIONSHIP When working with and learning Dynamo, we have found it extremely useful to understand the how objects are assigned on the “back-end” of Revit. For example, the difference between a Loadable Family and a System Family, Family Type and Family Instance, Category and Element Type, etc.

DATA BASICS In addition to that, it is very helpful to have a basic understanding of “programming” data types. Some of the basics are below (all of the definitions below can be found in the dynamo primer). This is not a complete list of data types but a starting point to establish some of the language used in visual programming/dynamo and in this course.

String a sequence of characters representing a literal constant or some type of variable. Informally, a string is programming lingo for text.

Number (Double) Number which may include decimals Integer Whole Numbers Boolean True or False, Yes or No, 1 or 0 Nulls represents the absence of data Lists A list represents a collection of items placed into one

structure of data Geometry Points, Lines, Circles, etc.

There are nodes for the common data types. You can also use a code block and type in values with a certain syntax to get the same result (see image “Using Code Blocks” shown below). If you want to go crazy, you can also use Design Script in Code Blocks to do many things. Personally, I like to keep it simple. For me, the whole point in Visual Programming is to stay visual. The more design script you use, the less clear it can be for other people to make sense of the logic of the script.


http://www.dynamoprimer.com/


USING CODE BLOCKS

CONVERTING DATA TYPES In Dynamo, it is important to watch the input and output data types and be sure to pass the type of data that is needed. In some cases, you might want to do some converting between data types to ensure you pass the right type of values and also to perform certain types of tasks.

CONVERT A STRING TO A NUMBER



CONVERT AN OBJECT TO A STRING

MANAGING DATA STRUCTURES One of the most challenging things about programming is learning to manage streams of data so that they match up properly at various parts of the script. In the next few sections, you will find some topics to watch for when trying to manage data in lists.

LIST LENGTH & STRUCTURE There are several things to consider when validating your data and one of them is ensuring that separate lists that come together to perform a function are the same length. It is a common problem to get lists of unequal lengths or different structures and often times this has to do with how the data was manipulated earlier in the script.

BOTH LIST CONTAINS SAME VALUES, WITH DIFFERENT DATA STRUCTURE



For example, you may input a list of data into a node, but the output may be a list of lists. If you do not flatten that list or otherwise structure the data in a way you intended, the results you get might not be what you expected or in some cases the data streams might be mismatched enough to where the script will fail downstream entirely.

BASIC EXAMPLE OF PASSING DIFFERENT DATA STRUCTURES YIELDS DIFFERENT RESULTS



It is also pertinent to note the importance of Node Lacing (Short, Long, Cross Product). I am not going to spend very much effort describing this here, as there are ample resources on the web and in the dynamo primer, but it absolutely affects how the data in list is looked at.

Below is are a few examples of list management nodes and how they affect the data going into them. Dynamoprimer.com has some great examples of list management and manipulation.


http://www.dynamoprimer.com/


LIST.CYCLE

CAN TAKE A SINGLE PIECE OF DATA OR DATA STRUCTURE AND COPY OR EXTEND IT TO A SPECIFIED LENGTH.

LIST.FLATTEN VS FLATTEN

FLATTEN REMOVES ALL NESTED LISTS. LIST.FLATTEN ALLOWS THE USER TO SPECIFY HOW MANY LEVELS OF THE LIST TO REMOVE.



DEALING WITH NULLS & EMPTY LISTS It can be very important to clean lists of data that contain null values or empty lists. There are situations where maintaining the list length is critical to ensure all of the data matches up properly. In those cases, replaces the null value or empty list can be a useful method.

EXAMPLES OF DEALING EMPTY LISTS AND NULL VALUES

We could then use List.Clean to clean the null values out of the list of parameter values, and thus have a clean set of element and parameter data to pass to excel or further down into the script.



EXAMPLES OF FILTERING LIST BASED ON NULLS OR EMPTY VALUES FROM ANOTHER LIST

When dealing with multiple streams of data, it may be necessary to “filter” the null values out. For example, when trying to get a parameter value for objects, it may be that certain families contain a parameter that others do not.

When using the Element.GetParameterValueByName, it will return null values for families you pass into it that do not contain data for the parameter you are looking for. This can

then be used as criteria for other tasks down the road, but the null values can cause problems. After generating a list of true/false by determining which objects are null or

empty, we can use List.FilterByBoolMask to filter another list of data such as an element list based on that mask, thus removing elements that contain null values for the specified

parameter.



MOST USED/USEFUL OUT OF THE BOX NODES FOR PROCESS AUTOMATION We queried about 100 scripts via (primarily geared towards process automation) and found the following Results. How was this done efficiently and reliably, you ask? Via a Dynamo script set, of course. Using Pivot tables, the results are filtered to only nodes that were used 25 times or more.

Core Node Name Number of Times Used Code Block 1664 List.FilterByBoolMask 313 List.GetItemAtIndex 221 List.Create 172 Flatten 160 String from Object 150 Element.GetParameterValueByName 142 Categories 132 Watch 131 Element.SetParameterByName 130 List.Flatten 114 == 82 List.Count 81 String.Contains 78 String 74 List.Transpose 66 List.Map 63 Point.ByCoordinates 59 All Elements of Category 57 String.Length 56 String.Remove 47 List.Cycle 45 String.Replace 45 List.Chop 44 List.AddItemToFront 41 List.UniqueItems 37 Boolean 37 If 32 String.ToNumber 31 Geometry.Translate 26



MOST USED/USEFUL CUSTOM NODES FOR PROCESS AUTOMATION Using the same dynamo file xml parsing script used to isolate the most used core nodes, we were able to generate a list of the most used Custom Nodes. Any Package whose total use was greater than 10 and within those packages, any node whose use was greater than 1. The result is below:

Package/Node Name Number of Times Used Clockwork for Dynamo 1.x 416

List.SortListOfLists 68 Element.Name (Universal) 57 List.RepeatItemsByLengths 33 List.SublistLengths 32 List.CountOccurences 24 List.SublistsContain 22 List.AnyTrue 19 Element.Location 11 Element.Type 11 All Family Types Of Category 10 Element.Level 9 Element.Workset 9 String.FindRegularExpression 8 Element.ID 8 DetailComponent.ByCurve 7 Document.Phases 7 Level.Plane 7 String.ReplaceRegularExpression 6 Element.Phases 6 Element.OwnerView 5 List.GroupListOfListsByKey 5 View.Phase 5 List.ReplaceItemAtIndex 4 Element.ParameterExists 4 Document.Views 4 Material.Duplicate 3 View.SetPhase 3 List.IsNotEmpty 3 List.ReplaceEmptyLists 3 Element.SetName 3 TextAlignFlags.Left 2 View.DuplicateWithDetailing 2 Document.Worksets 2



Element.SetWorkset 2 List.ReplaceNull 2 Document.ActiveViewFromCurrentDocument 2 View.IsViewTemplate 2 Floor.SlabShapeByPoints 2 All Families Of Category 2 Group.Members 2

archi-lab.net 50 Get All Views 14 Delete Elements 8 Current Document 7 Elements on Sheet 6 Set BuiltIn Parameter 6 Get Documents 5 Get Worksets 4

LunchBox for Dynamo 27 LunchBox Level Element Collector 9 LunchBox Mass Addition 6 LunchBox Wall Element Collector 4 LunchBox Sheet Collector 3 LunchBox Remove Null Values 3 LunchBox Room Element Collector 2

SteamNodes 23 Tool.Eraser 6 View.GetViewport 5 Viewport.SetBoxCenter 4 Tool.GetRevitSelection 2 Tool.CreateRoomAtPointAndLevel 2 Tool.CreateEmptySheet 2 Element.GetFromLinkedFile 2

spring nodes 19 ElementType.Duplicate 8 Collector.LinkedInstanceElements 3 ViewSet.ByViewsName 2 Collector.ElementSketch 2 Collector.ElementsInView 2 Doc.DeleteElements 2



OPPORTUNITIES FOR ADDITIONAL AUTOMATION One of the biggest challenges in using Dynamo for Process Automation is primarily centered around ease of portability. With reliability on specific custom nodes and the time it can take to find and open a script to run it, it can be a little intimidating for less experienced or less confident users to use dynamo. That said, there are some opportunities to make this much easier in the future, and the infrastructure to do this is already in place.

DYNAMO PLAYER This is a fantastic addition to Revit 2017.1 by Autodesk particularly for scripts with simple process automation or even project specific computational design scripts. Right now, the software looks into a folder and shows all the scripts in that folder. After the scripts are loaded in, it is very easy to simply hit run on a script to get the results. No need to open Dynamo or manually search for the script.

Dynamo Player can be found on the “Manage” tab in Revit 2017.1, right next to the new location for Dynamo.

IMAGINIT CLARITY – DYNAMO AUTOMATION Perkins+Will was fortunate to be able to work with Imaginit in providing feedback on their newly released “Scripting” Feature in their automation tool Clarity. This is an excellent addition to an already great automation tool, and opens up a world of opportunity to run custom scripts before other exports or tasks happen, or even on their own. The new clarity scripting features works with Macros as well, but in this brief summary, we will focus on the dynamo part of the feature. Below is a basic overview of what is required and how to set it up.



On the Task Server, you must tell clarity where to look for your scripts. Clarity will read the dynamo scripts for inputs, watches and output files and will make a web-configurable Clarity Task There is some node naming that must be done to cause clarity to read those nodes as inputs, but when done so, those inputs can be configured on a per task basis!! Scripts can be run on a “live model” and those changes can be synchronized back to central as a part of the automation. Be Careful with this and be sure to test this out! There is a new Task type, called a “Super Task” which can contain multiple tasks to be run on the same session of Clarity Automation. This could allow you to run a Dynamo Script before performing a PDF Print task.



THIRD PARTY PACKAGES – TOP 5 ROUNDUP

#5 – SPRING NODES

DIMITAR VENKOV @5devene badmonkeys.net

Installed: +8600 Spring Nodes focuses on enhancing Dynamo's interaction with Revit and exploring any means that can help accelerate BIM work-flows. https://github.com/dimven/SpringNodes

#4 – STEAM NODES

JULIEN BENOIT @Jbenoit44 badmonkeys.net

Installed: +9000 A set of various nodes to implement a dynamo workflow in your job. Some unique nodes for schedules, parts, groups and many various “tool” nodes such as Export DWF, Aligning Views on Sheet from Template, and Intersection Checking.

#3 – LUNCHBOX

NATHAN MILLER @archinate TheProvingGround.org

Installed: +35000 A collection of reusable geometry and data management nodes. Includes nodes for surface paneling, geometry, revit data collection, and more. Some additional unique nodes for dealing with nulls, doing mass addition/multiplication, and Element Collectors

#2 – ARCHI-LAB

KONRAD K SOBON @arch_laboratory archi-lab.net badmonkeys.net

Installed: +23000 Set of practical nodes. Includes nodes for many various tasks/elements

#1 – CLOCKWORK

ANDREAS DIECKMANN @a_dieckmann badmonkeys.net

Installed: +26700 Clockwork is a collection of 360+ custom nodes.

HONORABLE MENTIONS: Rhythm – Lots of interesting utility nodes, in particular List.AllindicesOf and UI.UserMessage. Others for deleting backup .rfa, package install checks, Unicode, Annotation Collectors. Plissken – Good Collectors of Unique items, Model Organization Nodes (workset management) Bumblebee – amazing Excel Interoperability, but I’ve found it can be unreliable around version upgrade time which can put you in a bind Hot Gear – Element overrides in View, Export Families to RFA (Only certain categories), Dynamo to/From Revit Conversions (Color, Point, ID)


http://www.badmonkeys.net/


https://perkinswillinc-my.sharepoint.com/personal/josh_moore_perkinswill_com/Documents/TheProvingGround.org

http://archi-lab.net/




TIPS & TRICKS Like with any application, over time you learn some of the things that make it sing. You also learn the things that will make you bang your head against the wall for hours over something you didn’t realize was an issue. In this section, we will address many of the things that we have learned over time that will help you in your Dynamo journey.

REFERENCE WEBSITES dynamobim.org

The best website at the time of writing this, by far, is dynamobim.org. The forum and folks that participate in the forum and help answer questions is second to none. It is filled with great examples and screenshots of scripts that can help generate understanding as to the language, context and various methods for solving similar problems. It is also full of great examples of things that don’t work!

dynamoprimer.com

The dynamo primer is a great place to get started with your dynamo journey. It has some very good examples of some of the basic data types and nodes that are common place and also has a great basic explanation of visual programming and dynamo.

revitforum.org/dynamo-bim/

As dynamo grows, we will continue seeing sites like revitforum.org add Dynamo forums (which has had a forum for some time now). This has always been a great community of Revit users and that community is now extending to Dynamo.

mydynamojourney.com This brand new website, founded by Josh and Justin, is our opportunity to continue to promote dynamo and contribute to the dynamo community. We anticipate launching periodic podcasts, lessons learned, forum for Q&A, etc. Soft opening at AU2016, and formal launch January 2017.

VERSION CONTROL When I first started using Dynamo, version control was the last thing I thought about. I was just struggling through getting the language and understanding how to make it do what I wanted. As I am beginning to push Dynamo to our staff at Perkins+Will, I am starting to see how versioning is a critical component of safe guarding against issues and keeping “backups”. There are different methods to deal with versioning and certainly some commonly adopted approaches to software versioning. I have found it makes the most sense to me and other staff using the sciprts to version the dynamo files in conjunction with the version of dynamo. As


https://perkinswillinc-my.sharepoint.com/personal/josh_moore_perkinswill_com/Documents/dynamobim.org

https://perkinswillinc-my.sharepoint.com/personal/josh_moore_perkinswill_com/Documents/dynamobim.org

http://dynamoprimer.com/

https://perkinswillinc-my.sharepoint.com/personal/josh_moore_perkinswill_com/Documents/dynamoprimer.com

https://perkinswillinc-my.sharepoint.com/personal/josh_moore_perkinswill_com/Documents/revitforum.org/dynamo-bim/

https://perkinswillinc-my.sharepoint.com/personal/josh_moore_perkinswill_com/Documents/revitforum.org

http://www.revitforum.org/dynamo-bim/

http://www.mydynamojourney.com/


dynamo continues to change, I would highly recommend saving a new copy of the script with the dynamo version number at the end. For example, this might look like: Push Scope Box Name to Element v1.2.0.dyn Shape Edit Floor to Match Topo v1.1.0.dyn The first two digits, separated by a “.” are the version of dynamo that have been tested in as working. The last digit, could be used to version additions or changes you have made over time, within that version of dynamo. Over the past several 1.x releases of Dynamo, I have not noticed significant issues of running scripts created in one version or the other, except for obvious functionality changes that can affect the script. As dynamo scripts are updated, ensuring previous versions are put into an archive folder can be very useful. Additionally, there are often times issues with external packages you might be relying on, which in my experience, is one of the main reasons to version your scripts. This leads into the next tip/best practice, keeping versions of packages in a shared location.

SHARED LIBRARIES I have found using shared libraries a crucial part of making our dynamo scripts “reusable” for design staff. All of the vetting, version management, etc. becomes a little more centralized, as opposed to the staff installing versions of the packages on their local machines. In the following sections, I will describe in further detail the reasons using shared libraries can useful and how to deal with some of the problems external packages can present.

External Package “New Features” can cause existing scripts to Fail As external packages get updated, sometimes what the developer thought of as a new feature, actually causes a failure in your script. A good example of this, is when several developers introduced “run me” inputs to their nodes. It was a simple fix, but nonetheless, the update would cause existing scripts to stall out until fixed.

Updated Revit and Dynamo Versions can cause compatibility issues with External Packages When dynamo and/or Revit versions change, you want to maintain a separate folder that staff can point to for packages that have been updated for compatibility reasons. Often times, there is a delay for most of the developers to update their code. When this happens, and you rely on scripts to get projects done, you’ll want to ensure you can access the previous version of dynamo and the packages that worked with that version.

Here is a sample structure to consider when using a shared library:

{mapped drive}:\Dynamo\Packages\{Dynamo Version}\ For example: O:\Dallas\Dynamo\Packages\1.2\



Inside of each “Dynamo Version” folder, the external packages will exist that have been tested and vetted by those writing the scripts and would also be a shared location for staff to use and feel a higher level of confidence in packages that will work for them when writing scripts.

UPDATING THIRD PARTY PACKAGES AND DEALING WITH DEPENDENCIES There are many external packages available on the package manager. As described in this course, there are a handful that most script writers can’t do without, as they do a great job of extending functionality in Dynamo. That being said, some of the packages rely on nodes from other packages to work, and this can be a pain. For example, if one developer updates their package, Package A, and you try to install it and are greeted with a message that says that another package. Package B, has to be uninstalled before you can install Package A. This is usually because Package A requires and is dependent on an updated version of Package B. And conversely, you are trying to install Package C and it is depending on Package D, but the version you have installed of Package D is newer than the one being referenced in Package C. Needless to say, this can be a pain, and I’ve found that even if you go through the steps to close and reopen dynamo, it doesn’t always seem to perform the uninstall and reinstall, and you may not want to do that anyway. In some cases, you may just want to try the package and leave the dependency in its current state. The way I have addressed this issue, is to manually download the new package through the package manager website, as opposed to inside of dynamo. This will allow you to download the new package, place it in the correct folder, and then test it without changing any of your other packages that it might depend on. This is also great because it makes it a little easier to download previous versions of packages without uninstalling the current version. I will then close dynamo and Revit, place the current package in an archive folder, and drop the previous version in for testing.

CLOSE AND REOPEN SCRIPT TO RESET DATA There are many times, especially when testing scripts during the creation process, that closing and reopening the script is critical to ensuring proper function. Process Example: Run Script> Undo Dynamo Transaction in Revit> Close Script> Reopen> Repeat I’ve found this process invaluable when trying to validate how the data is streaming through the script. There are times when rerunning a script that has been run previously in that Revit Session causes Revit and Dynamo to not communicate the way you would expect.


https://dynamopackages.com/


For example, sometimes certain creation steps will repeat on top of one another. Or, when dynamo script fails to do what you wanted, Revit and Dynamo think it already happened so even making tweaks to the script doesn’t reset Dynamo’s “attachment” to what it already did (read or write) in the Revit file. Unfortunately, at the time of writing this, there hasn’t been an exact science to this, but I commonly find that closing and reopening the script can save me major headaches.

SAVE OFTEN, CRASHING, AND BACKUPS One thing I realized when first starting my Dynamo Journey, is to save often. When you are first learning, or even learning something new, you don’t always “wire” things up in an efficient or correct way and hitting run in that scenario can cause Dynamo to perform, possibly tens of thousands of, calculations you may not have intended. In some cases, waiting it out is ok, but in other cases you might have to force close Dynamo, which in turn closes Revit. I always advise staff starting to use Dynamo to ensure their Revit model is synchronized/saved BEFORE running the script. This is for several reasons:

• It ensures that is something goes wrong and you can’t properly undo the work in a way that ensures you have undone the right things, you can close your Revit model and not save the changes, while also ensuring that you haven’t lost work previous to starting the dynamo effort.

• If something in Dynamo locks up or crashes, you are able to force close without losing your previous work.

One thing I didn’t realize until well into my Dynamo journey, is that Dynamo does a good job of making backups of scripts, upon clicking run, right before actually running the script. These files are generally saved into your user appdata folder at: C:\Users\{username}\AppData\Roaming\Dynamo\Dynamo Revit\backup Or %APPDATA%\Dynamo\Dynamo Revit\backup



RUN MANUAL When dealing with the sort of scripting that is the primary scope of this class, I highly recommend setting all scripts to Run in Manual mode. I can’t stress how important this is. As mentioned previously, when learning, you may wire things up that you didn’t intend to, and run manual gives you one extra level of safety before committing to the run.

NO COMMANDS ACTIVE IN REVIT Ensure, when running a script, that there are no active commands or dialog boxes in Revit. I have spent so many hours trying to figure out why nothing is happening in my Revit file, when it turns out I had a move command active or an open dialog box.

PAY ATTENTION TO ACTIVE VIEW IN REVIT Some scripts run on the current view opened in Revit. Keep that in mind when using scripts and writing scripts. If this is functionality in a script you write, be sure to note that in the notes section that others should see upon opening the script.

DEALING WITH OBJECTS IN GROUPS When trying to push data to objects in groups, it may be necessary to create a new parameter with the “Values can vary by group Instance” button selected. This will allow dynamo to properly iterate through those objects and avoid grouping errors. Note that this will only work with “Text” type parameters, which can be where it may be necessary to do data type conversions if you are working with Numbers.

USE OUT OF THE BOX NODES AS MUCH AS POSSIBLE Over time I’ve realized, for reusability purposes, doing your best to stick with Out of the Box (OOTB) nodes is much better in the long run. There are many packages out there that provide some “shorthand” nodes to things that dynamo can do on its own, but with a few extra nodes. Due to the issues that can occur with updates, pointing to the right packages, etc. I always recommend using as few external packages as possible. Another way to help with this issue is to embed custom package python scripts into your script using the Python node. This can be done with many external packages where the python script isn’t locked down. Always remember to provide credit inside the script as to who/where the python script was gotten.



SCRIPT ORGANIZATION, GRAPHICS, AND COMMENTING

It is always a good idea to be consistent in anything that is done in a team atmosphere, and Dynamo is no different. When writing scripts that other people need to use or even edit, it is imperative to organize it and comment it. There is a great method already suggested that we have used. It involves a simple color coding of nodes, and a consistent method for providing instructions and comments to anyone that may open the script and try to run it. Doing script “clean up” is crucial to the success, understanding and reuseability of other people in your company. Whether or not this exact implementation is used, there are items that anyone writing scripts should consider:

1) Created by and When 2) Script Version 3) Last Edited Data 4) Dynamo Version (last known use/compatibility) 5) Required Third Party Packages 6) Notes/Instructions


http://dynamobim.org/dynamo-graphic-standards-at-white-arkitekter-ab/


SCRIPT EXAMPLE #1 -EXPORTS VIEWS TO EXCEL CONTAINING CATEGORY

SCRIPT SUMMARY This script was created to be able to find certain placed instances of annotation types like dimensions or text in a model. It’s primary intended use is for model cleanup, and often we use it for template cleanup as well. This is especially useful for Legend views, since select all instances in entire project doesn’t work for annotation elements in Legends. The Revit model you run this on must be workshared. Perkins+Will used .rvt files that are already workshared as our “template”, but that’s a topic for a separate AU class ; ) since the logic of the script gets the workset of the annotation element, which happens to be the view name in a workshared file. It will export this data out to excel and you can then run an easy pivot table on the data to determine what types live in which views. Note: this script will not find nested dependencies, like text styles in Schedules.

SCRIPT OVERVIEW USER INTERFACE – DIMENSION EXPORT



SAMPLE EXCEL EXPORT FOR DIMENSIONS

USER INTERFACE – TEXT NOTES EXPORT



SAMPLE EXCEL EXPORT FOR TEXT NOTES

PIVOT TABLE SORTING

MORE PIVOT TABLES OF DATA



DETAILED SCRIPT BREAKDOWN

USER INTERFACE - DETAILED



GETTING THE NAME OF THE VIEW BY THE ELEMENT WORKSET

GETTING THE TYPE NAME OF ALL PLACED INSTANCES OF THE SPECIFIED ANNOTATION CATEGORY



GETTING THE VIEW NAME AND THE ELEMENT TYPE NAMES

EXPLAINING THE LIST.CREATE FOR PASS TO EXCEL



EXPLAINING THE LIST.CREATE & TRANSPOSE FOR PASS TO EXCEL

PASSING DATA TO EXCEL



SAMPLE EXCEL OUTPUT

DISCONNECTED SECTION OF SCRIPT THAT CAN SORT THE DATA BEFORE PASSING TO EXCEL



SCRIPT EXAMPLE #2 - SLAB EDIT FLOOR TO MATCH TOPOGRAPHY

SCRIPT SUMMARY The intent of this script is primarily for getting an object like a floor to slope with a topography (surface) in Revit. This is especially useful for floors representing curbs and other areas of landscape/hardscape where you need some visual offset from the primary topo surface. The script is primarily broken up into three parts. 1) Getting/Setting points for the floor edge, at a desired spacing. 2) Getting/Setting points for the floor corners 3) Getting/Setting a points for the floor field, at a desired “resolution”. Currently the script only works for one floor object at a time, but could probably be tweaked to be able to do multiple objects at once. Additional Notes: This script does not work on topo surfaces with subregions applied and it also does not like sharp corners in the floor objects.

SCRIPT RUN-THROUGH USER INTERFACE - OVERVIEW



3D VIEW – BEFORE DYNAMO RUN

3D VIEW – AFTER DYNAMO RUN ON MAIN FLOOR, SHOWING THE PREVIEW GEOMETRY (POINTS)



3D VIEW SHOWING AFTER DYNAMO RUN FOR CURBS, AND SHOWING HOW TO REMOVE TRIANGULATION



SCRIPT BREAKDOWN USER OVERVIEW - DETAILED



CONVERTING THE REVIT GEOMETRY TO DYNAMO GEOMETRY AND PROJECTING THE BOUNDARY CURVES OF THE FLOOR TO THE POLYSURFACE REPRESENTATION OF THE TOPOSURFACE

CREATING THE NEW SURFACE REPRESENTING THE FLOOR PROJECTED TO THE TOPOSURFACE



CREATING THE EDGE, CORNER AND FIELD POINTS FROM THE SURFACE

PREVIEW OF HOW THIS POINTS WILL LOOK WHEN APPLIED TO THE FLOOR OBJECT



COMBINING THE POINTS INTO A SINGLE LIST AND ENSURING THERE ARE NO DUPLICATES



PASSING THE POINTS TO THE CLOCKWORK NODE TO EDIT THE SHAPE OF THE FLOOR



SCRIPT EXAMPLE #3 - COORDINATING DUMMY VIEW TAGS ACROSS LINKED MODELS

SCRIPT SUMMARY The Goal of this workflow is to be able to solve a fundamental problem that Revit has always had; the ability to link view references to views in other models. The workflow is broken down into three primary parts: 1) Script 1 – Push all views and associated information from model(s) to excel, including a

unique identifier that will be used as the reference 2) User Interaction – Using the excel file and copying and pasting the unique identifier to a

dummy view tag 3) Script 2 – Read all the excel files in a folder that are generated with script 1, and

find/compare the dummy tag values with ones in the excel files to push the view number/sheet number.

SCRIPT RUN-THROUGH

PART 1 USER INTERFACE FOR SCRIPT 1 – THE DATA PUSH TO EXCEL



SAMPLE VIEW OF THE RAW DATA EXCEL FILE OUTPUT

SAMPLE VIEW OF THE FORMATTED EXCEL FILE FOR STAFF TO REFERENCE



MORE DETAIL ON THE STEPS STAFF WOULD TAKE TO FIND THE APPROPRIATE REFERENCE

TAKING THE UNIQUE ID FROM EXCEL AND PASTING IT INTO THE CUSTOM “DUMMY” VIEW TAG FAMILY



SHOWING THE UNIQUE ID FROM EXCEL COPIED INTO THE PROPERTIES OF THE DUMMY VIEW TAG



Part 2 USER INTERFACE FOR SCRIPT 2 – UPDATING THE TAGS FROM THE EXCEL OUTPUT OF SCRIPT 1

SAMPLE OF THE EXCEL FILE INDICATING THE DUMMY VIEW TAGS THAT WERE CHANGED FOR VALIDATION

SAMPLE OF TAGS (MATCHES, NO MATCHES, AND NO IDENTIFIER)





SCRIPT BREAKDOWN Part 1

GETTING THE NAME OF THE REVIT FILE AND PATH, FROM THE REVIT CENTRAL FILE



GETTING ALL THE VIEWS IN THE PROJECT AND FILTERING OUT SCHEDULES, LEGENDS, AND SHEETS



BUILDING THE UNIQUE ID THAT WILL BE THE REFERENCE FOR EACH VIEW



USING A CODE BLOCK TO COMBINE THE VALUES FROM THE PREVIOUS STEP



GETTING OTHER PARAMETER DATA FROM THE VIEWS; COMBINING SHEET NUMBER AND SHEET NAME REFERENCE TO A SINGLE VALUE



BUILDING A COMBINED LIST WITH ALL THE DATA TO PASS TO EXCEL

BUILDING THE DATA REFERENCES FOR THE FORMATTED EXCEL TEMPLATE



CONTINUATION OF BUILDING THE DATA REFERENCES FOR THE FORMATTED EXCEL FILE



PERFORMING THE FINAL STEPS, COPYING THE TEMPLATE, AND WRITING DATA TO THE RAW DATA AND THE FORMATTED EXCEL FILES



Part 2

DATA STREAM 1, GETTING THE PLACED INSTANCES OF THE DUMMY VIEW TAGS

BREAKING DOWN THE ABOVE SCREENSHOT INTO PIECES



PARSING THE EXCEL FILES GENERATED FROM THE 1ST SCRIPT





PULLING DATA FROM THE EXCEL FILE INTO TWO DIFFERENT STREAMS; 1) DETAIL NUMBER/SHEET NUMBER 2) GUIDS



PULLING APART THE SHEET NUMBER AND DETAIL NUMBER REFERENCE



BRINGING ALL THE DATA BACK TOGETHER AND SORTING IT BY GUID



PULLING AND COMPARING THE GUIDS FROM DATA STREAM 1 AND 2 (EXCEL COMPARED TO ACTIVE REVIT FILE) AND SETTING

SETTING THE VALUES OF EACH DUMMY VIEW TAG (MATCHES ON THE LEFT, NO MATCHES ON THE RIGHT)



REFORMATTING THE DATA TO PUSH THAT DATA TO AN EXCEL FILE FOR PROJECT TEAM VALIDATION/TROUBLESHOOTING

SENDING THE DATA TO THE EXCEL FILE. TOP PORTION IS BUILDING THE FILE PATH/NAME DYNAMICALLY



COURSE EXTRAS: ADDITIONAL SCRIPTS Note: Direct links to scripts are below. If you would like to download the folder of scripts, you can used this link: https://www.dropbox.com/sh/ho0a8c5ofrmvv4m/AACwqqWzO_BWMN6_NznvRxh8a?dl=0

PUSH LEVEL NAME INTO OBJECT Link to Script Script Status: Commented and working, may not be optimized Required Packages: Clockwork & Lunchbox Written by: Josh Moore, Perkins+Will Summary: This script can be used in several known instances where Revit doesn’t properly schedule objects by level. A few examples of this are: 1) Face based families such as parking

spaces hosted to sloped parking ramps

2) Doors, when scheduling from linked models, needing to be grouped by level (Revit doesn’t allow using the Level field when scheduling across linked models)

3) Doors in Curtain wall, that sometimes do not properly report their level

4) Etc…

REPLACE CARRIAGE RETURNS IN ROOM NAMES Link to Script Script Status: Commented and Working Required Packages: Clockwork Written by: Josh Moore, Perkins+Will

Summary: This script has a small use field, but when needed, has a huge impact. We had a project where a junior staff member put carriage returns (CTRL+Enter in the parameter field) in a bunch of Room names in order to force the room tag to wrap where they wanted.


https://www.dropbox.com/sh/ho0a8c5ofrmvv4m/AACwqqWzO_BWMN6_NznvRxh8a?dl=0

https://www.dropbox.com/s/1jhl1vu4x3q8dhv/Push%20Level%20Name%20into%20Object%20v1.2.0.dyn?dl=0

https://www.dropbox.com/s/4lnozcym024g2kw/Replace%20Carriage%20Returns%20in%20Room%20Names%20v1.2.0.dyn?dl=0


This caused undesirable results in room schedules and other data exports downstream. A very simple dynamo script was written to rip through all of the rooms in the model, and find any carriage returns using regex and replace them with a space character.

REPLACE CEILING HOSTED WITH FACE HOSTED FAMILY Link to Script Script Status: Commented and working, Requires Dynamo 1.2 Required Packages: SteamNodes Written by: Josh Moore, Perkins+Will Summary: This script could have many uses. The particular use in mind when this script was written was to replace ceiling based lights with a face based equivalent. We generally encourage face based lights, but sometimes staff will not get the right family and we will have a mish-mash of hosting methods, which can cause confusion and inconsistent behavior. To use the script:

1) Select the fixtures in the Revit files you want to replace. Feel free to do a “Select all Instances”.

2) Be sure to set the family name and type name in the script with the name of the replacement family

3) Toggle the True/False for post placement rotation and set the rotation. 4) Generally, this script will be done in cycles for each fixture type you have in the project.

After running the script for one set of objects, suggest closing and reopening the script before running the next set of objects.

KEYPLAN SETTER Link to Script Script Status: Commented and working, may not be optimized Required Packages: Clockwork, Archi-lab_Grimshaw Written by: Andy Ilges, Perkins+Will Summary: The intent of this script is very simple. Map the suffix of a sheet number (i.e., A10-01A), where the suffix represents an “Area” plan in a set of drawings, to a key plan parameter so that staff don’t have to open each sheet and check boxes for hours. To use the script: 1) Set the Titleblock that contains the keyplan from the drop down in the User Interface (Start

Here) section. The script assumes the parameter for checking of the keyplan exists inside the titleblock family.

2) Set all of the names of the Parameters that need to be checked that exist in the titleblock family (script assumes instance parameters) in the “Titleblock Keyplan Parameter Names” Code block. Ensure required formatting is met.

3) Based on firm standards or project requirements, set the search string for “Overall” plans to whatever name is used in the Sheet name for Overall Plans. There is a filter that will grab these sheets and ensure that all the keyplan boxes are checked


https://www.dropbox.com/s/ufxg7ypg3bkff88/Place%20Face%20Hosted%20Light%20Based%20on%20Ceiling%20Hosted%20Light%20v1.2.0.dyn?dl=0

https://www.dropbox.com/s/23pih30su31vlgm/Keyplan%20Setter%20v1.2.0.dyn?dl=0

https://www.dropbox.com/s/23pih30su31vlgm/Keyplan%20Setter%20v1.2.0.dyn?dl=0


4) Lastly, set the typical length of sheets without a suffix. For example, at Perkins+Will, our standard overall sheet would be A11-01. That is 6 Digits. With the suffix, for an Area plan, that would be A12-01A, which is 7 digits. We would want to set the digit value in dynamo to 6 digits, so Dynamo only looks at the sheets that are “Area/Partial/Segement” (however you call it) plan sheets.

DELETE SELECTED SHEETS AND VIEWS ON THOSE SHEETS Link to Script Script Status: Commented and working Required Packages: Spring Nodes, Steam Nodes Written by: Josh Moore, Perkins+Will Summary: This is a file cleanup/purging utility. Deletion of sheets AND views on those sheets has been a pain. This utility allows you to select sheets from the project browser and delete those sheets WITH the views on those sheets. To use the script: 1) Set the first true/false toggle to false to simply verify

what sheets/views will be deleted. Set it to true when ready to actually do the deleting.

2) Set the next true/false Toggle to true to delete the SCHEDULES found on the selected sheets out of the project (this would in turn delete them off any sheets not selected).

3) Set the third true/false Toggle to true to delete the LEGENDS found on the selected sheets out of the project (this would in turn delete them off any sheets not selected).

4) The last open view cannot be one of the views you are trying to delete.


https://www.dropbox.com/s/jkvmboyvudrbv74/Delete%20Selected%20Sheets%20and%20Views%20on%20Those%20Sheets%20v1.2.0.dyn?dl=0

https://www.dropbox.com/s/jkvmboyvudrbv74/Delete%20Selected%20Sheets%20and%20Views%20on%20Those%20Sheets%20v1.2.0.dyn?dl=0


INDEX OF NODES USED IN SCRIPTS PROVIDED BY THIS CLASS (BY NODE NAME, ALPHABETICAL) Package/Node/Script # times used archi-lab.net 3

Elements on Sheet 3 Keyplan Setter v1.2.0 3

Clockwork for Dynamo 1.x 20 All Families Of Category 1

02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1 Document.Views 1

01 - Push View GUID to Excel v1.1.0 1 Element.Name (Universal) 1

Export Views To Excel Containing Category v1.1.0 1 Element.OwnerView 1

02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1 Element.Workset 1

Export Views To Excel Containing Category v1.1.0 1 Floor.SlabShapeByPoints 1

Shape Edit Floor to Match Topo v1.1.0 1 List.CountOccurences 1

Keyplan Setter v1.2.0 1 List.GroupListOfListsByKey 1

Export Views To Excel Containing Category v1.1.0 1 List.RepeatItemsByLengths 2

01 - Push View GUID to Excel v1.1.0 2 List.SortListOfLists 7

Export Views To Excel Containing Category v1.1.0 1 Keyplan Setter v1.2.0 2 Push Level Name into Object v1.2.0 2 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 2

List.SublistLengths 1 Push Level Name into Object v1.2.0 1

String.ReplaceRegularExpression 1 Replace Carriage Returns in Room Names v1.2.0 1

View.IsViewTemplate 1 01 - Push View GUID to Excel v1.1.0 1

Core Dynamo 462 - 4

Keyplan Setter v1.2.0 2 Push Level Name into Object v1.2.0 2

> 2 Keyplan Setter v1.2.0 1



02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1 + 3

Push Level Name into Object v1.2.0 2 01 - Push View GUID to Excel v1.1.0 1

== 2 Delete Selected Sheets and Views on Those Sheets v1.2.0 1 Keyplan Setter v1.2.0 1

All Elements of Category 4 Export Views To Excel Containing Category v1.1.0 1 Keyplan Setter v1.2.0 1 Push Level Name into Object v1.2.0 1 Replace Carriage Returns in Room Names v1.2.0 1

All Elements of Family Type 2 Keyplan Setter v1.2.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Boolean 12 Delete Selected Sheets and Views on Those Sheets v1.2.0 3 Export Views To Excel Containing Category v1.1.0 1 Keyplan Setter v1.2.0 3 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1 Push Level Name into Object v1.2.0 3 01 - Push View GUID to Excel v1.1.0 1

BoundingBox.MinPoint 2 Push Level Name into Object v1.2.0 2

Categories 5 Export Views To Excel Containing Category v1.1.0 1 Keyplan Setter v1.2.0 1 Push Level Name into Object v1.2.0 1 Replace Carriage Returns in Room Names v1.2.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Code Block 147 Shape Edit Floor to Match Topo v1.1.0 5 Delete Selected Sheets and Views on Those Sheets v1.2.0 4 Export Views To Excel Containing Category v1.1.0 6 Keyplan Setter v1.2.0 14 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 2 Push Level Name into Object v1.2.0 16 Replace Carriage Returns in Room Names v1.2.0 3 01 - Push View GUID to Excel v1.1.0 40 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 57

Cuboid.ByCorners 1 Push Level Name into Object v1.2.0 1

Curve.EndPoint 1



Shape Edit Floor to Match Topo v1.1.0 1 Curve.PointAtSegmentLength 1

Shape Edit Floor to Match Topo v1.1.0 1 Curve.StartPoint 1

Shape Edit Floor to Match Topo v1.1.0 1 Directory.Contents 1

02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1 Directory.FromPath 1

02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1 Edge Point Spacing (inches) 1

Shape Edit Floor to Match Topo v1.1.0 1 Element.BoundingBox 1

Push Level Name into Object v1.2.0 1 Element.Faces 1

Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1 Element.GetLocation 1

Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1 Element.GetParameterValueByName 16

Export Views To Excel Containing Category v1.1.0 1 Keyplan Setter v1.2.0 2 Replace Carriage Returns in Room Names v1.2.0 1 01 - Push View GUID to Excel v1.1.0 5 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 7

Element.Id 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Element.Name 2 Export Views To Excel Containing Category v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Element.SetParameterByName 9 Keyplan Setter v1.2.0 3 Push Level Name into Object v1.2.0 1 Replace Carriage Returns in Room Names v1.2.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 4

Element.UniqueId 1 01 - Push View GUID to Excel v1.1.0 1

Excel.ReadFromFile 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Excel.WriteToFile 4 Export Views To Excel Containing Category v1.1.0 1 01 - Push View GUID to Excel v1.1.0 2 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Family.Name 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1



Family.Types 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

FamilyInstance.ByFace 1 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1

FamilyInstance.FacingOrientation 1 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1

FamilyInstance.GetHost 1 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1

FamilyInstance.SetRotation 1 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1

FamilyType.ByFamilyNameAndTypeName 1 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1

File.Copy 1 01 - Push View GUID to Excel v1.1.0 1

File.FromPath 2 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

Flatten 22 Shape Edit Floor to Match Topo v1.1.0 4 Delete Selected Sheets and Views on Those Sheets v1.2.0 3 Export Views To Excel Containing Category v1.1.0 2 Keyplan Setter v1.2.0 6 01 - Push View GUID to Excel v1.1.0 3 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 4

Geometry.BoundingBox 1 Push Level Name into Object v1.2.0 1

Geometry.DoesIntersect 2 Shape Edit Floor to Match Topo v1.1.0 1 Push Level Name into Object v1.2.0 1

Geometry.Translate 1 Shape Edit Floor to Match Topo v1.1.0 1

If 5 Delete Selected Sheets and Views on Those Sheets v1.2.0 2 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1 01 - Push View GUID to Excel v1.1.0 2

List.AddItemToEnd 1 Push Level Name into Object v1.2.0 1

List.AddItemToFront 6 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 6

List.Chop 1 Keyplan Setter v1.2.0 1

List.Clean 2 Delete Selected Sheets and Views on Those Sheets v1.2.0 1



02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1 List.Combine 4

Keyplan Setter v1.2.0 4 List.Count 9

Keyplan Setter v1.2.0 7 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

List.Create 13 Delete Selected Sheets and Views on Those Sheets v1.2.0 1 Export Views To Excel Containing Category v1.1.0 2 Keyplan Setter v1.2.0 2 Push Level Name into Object v1.2.0 3 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 4

List.Cycle 1 Push Level Name into Object v1.2.0 1

List.FilterByBoolMask 14 Shape Edit Floor to Match Topo v1.1.0 1 Delete Selected Sheets and Views on Those Sheets v1.2.0 1 Keyplan Setter v1.2.0 4 Push Level Name into Object v1.2.0 2 01 - Push View GUID to Excel v1.1.0 3 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 3

List.Flatten 5 Push Level Name into Object v1.2.0 4 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

List.GetItemAtIndex 20 Export Views To Excel Containing Category v1.1.0 2 Keyplan Setter v1.2.0 2 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1 Push Level Name into Object v1.2.0 4 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 11

List.Join 2 Shape Edit Floor to Match Topo v1.1.0 2

List.LastItem 1 Push Level Name into Object v1.2.0 1

List.OfRepeatedItem 8 Keyplan Setter v1.2.0 8

List.RemoveItemAtIndex 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

List.Sort 1 Push Level Name into Object v1.2.0 1

List.Sublists 1



Push Level Name into Object v1.2.0 1 List.Transpose 9

Export Views To Excel Containing Category v1.1.0 2 Keyplan Setter v1.2.0 2 Push Level Name into Object v1.2.0 1 01 - Push View GUID to Excel v1.1.0 2 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 2

List.UniqueItems 3 Shape Edit Floor to Match Topo v1.1.0 2 Delete Selected Sheets and Views on Those Sheets v1.2.0 1

Number 1 Export Views To Excel Containing Category v1.1.0 1

Point.ByCoordinates 2 Push Level Name into Object v1.2.0 2

Point.Z 1 Push Level Name into Object v1.2.0 1

PolyCurve.ByJoinedCurves 2 Shape Edit Floor to Match Topo v1.1.0 2

PolyCurve.Curves 1 Shape Edit Floor to Match Topo v1.1.0 1

Python Script 1 01 - Push View GUID to Excel v1.1.0 1

Range 2 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 2

Select Model Element 2 Shape Edit Floor to Match Topo v1.1.0 2

SetIntersection 3 Keyplan Setter v1.2.0 3

Sheet.SheetName 1 Keyplan Setter v1.2.0 1

Sheet.SheetNumber 2 Keyplan Setter v1.2.0 2

String 5 Export Views To Excel Containing Category v1.1.0 3 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

String from Object 6 Delete Selected Sheets and Views on Those Sheets v1.2.0 1 Keyplan Setter v1.2.0 1 Push Level Name into Object v1.2.0 2 01 - Push View GUID to Excel v1.1.0 2

String.Contains 3 Keyplan Setter v1.2.0 1



Push Level Name into Object v1.2.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

String.IndexOf 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

String.LastIndexOf 2 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

String.Length 7 Keyplan Setter v1.2.0 3 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 3

String.Remove 8 Keyplan Setter v1.2.0 2 01 - Push View GUID to Excel v1.1.0 2 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 4

String.Replace 2 01 - Push View GUID to Excel v1.1.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 1

String.StartsWith 3 Keyplan Setter v1.2.0 1 01 - Push View GUID to Excel v1.1.0 2

Surface.ByPatch 1 Shape Edit Floor to Match Topo v1.1.0 1

Surface.Perimeter 1 Shape Edit Floor to Match Topo v1.1.0 1

Surface.ProjectInputOnto 1 Shape Edit Floor to Match Topo v1.1.0 1

Surfaces.DivideSurfaceUV 1 Shape Edit Floor to Match Topo v1.1.0 1

Topography.Mesh 1 Shape Edit Floor to Match Topo v1.1.0 1

Transaction.End 1 01 - Push View GUID to Excel v1.1.0 1

Transaction.Start 2 01 - Push View GUID to Excel v1.1.0 2

Vector.ZAxis 2 Shape Edit Floor to Match Topo v1.1.0 2

Watch 7 Delete Selected Sheets and Views on Those Sheets v1.2.0 1 Push Level Name into Object v1.2.0 2 01 - Push View GUID to Excel v1.1.0 2 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 2

If Equal Return Index 3



If Equal Return Index 3 Keyplan Setter v1.2.0 1 02 - Set Dummy Tag Parameter By GUID Value From Excel v1.1.0 2

LunchBox for Dynamo 1 LunchBox Level Element Collector 1

Push Level Name into Object v1.2.0 1 spring nodes 1

Collector.ElementSketch 1 Shape Edit Floor to Match Topo v1.1.0 1

Springs.Doc.DeleteElements 1 Delete Selected Sheets and Views on Those Sheets v1.2.0 1

Springs.Mesh.ToPolySurface 1 Shape Edit Floor to Match Topo v1.1.0 1

Springs.Sheet.Views+ 1 Delete Selected Sheets and Views on Those Sheets v1.2.0 1

SteamNodes 2 Tool.GetRevitSelection 2

Delete Selected Sheets and Views on Those Sheets v1.2.0 1 Place Face Hosted Light Based on Ceiling Hosted Light v1.2.0 1
