Build your own Revit – Einstieg in die Revit-Erweiterung Autodesk Dynamo für programmierte Planungsprozesse Tim Hannewald tim.hannewald@nupis.de

Class summary Autodesk Dynamo bietet das Potenzial Ihre Modellerstellung in Revit zu automatisieren. Verschaffen Sie sich einen Überblick darüber, welche Möglichkeiten und Grenzen Autodesk Dynamo bietet und wie das Zusammenspiel zwischen Autodesk Revit und Autodesk Dynamo erfolgt. Darüber hinaus lernen Sie das Konzept der visuellen Programmierung kennen und erstellen ein erstes einfaches Dynamo-Skript.

Key learning objectives/Agenda Was ist Dynamo? – Möglichkeiten und Grenzen von Dynamo Dynamo-Grundlagen – Aufbau der Oberfläche, Definitionen und Funktionsweisen Analysen und Konzeptionen zum Skript Dynamo feat. Revit – Das Zusammenspiel zwischen Revit in Dynamo Und nun? – Zusammenfassung und Ausblick Frage wer hat Erfahrung mit Dynamo? Wer hat Erfahrung mit klassischer Programmierung? Ziel: Überblick über Dynamo Abgrenzung Visuelle Programmierung, Klassische Programmierung Best Practice Vorgehen bei der Erstellung Zusammenspiel Revit Dynamo Erstellung eines ersten Skriptes zum Export von Revit Parameterwerten nach Excel

Was ist Dynamo? – Möglichkeiten und Grenzen von Dynamo

Visuelle Programmierschnittstelle für Revit Was ist Dynamo? Visuelle Programmierschnittstelle für Revit Nutzung der Revit-API ohne Kenntnis einer Programmiersprache Generische, parametrisierte Konstruktion Regelbasiertes Arbeiten Open Source Mehrsprachig verfügbar, Blockbezeichnungen jedoch Englisch relativ schnell drüber gehen -> sollte bekannt sein, ggf. sogar weglassen Nutzung der Revit-API ohne Kenntnis einer Programmiersprache -> Programmintern wird vorgefertigter Code abgearbeitet, nach außen hin wird der Code durch Blöcke repräsentiert Generische, parametrisierte Konstruktion -> In Dynamo gibt es Blöcke die Daten Eingabe, Verarbeitung und Ausgaben ermöglichen -> Über Parametrisierung können verschiedene Konstellationen angewendet werden Regelbasiertes Arbeiten -> alles was in Regeln gefasst werden kann, kann in der Regel auch mit Dynamo realisiert werden (auch wenn teilweise eine eigene Programmierung notwendig ist) -> Beispiele: - Alle Tragswerksstützen müssen in einem bestimmten Abstand platziert werden - Sanitärräume sind innerhalb eines bestimmten Zeitintervalls zu reinigen - Als Inneneinrichtung für ein Gebäude (Mensa, Theater, …) ist das Inventar wie folgt zu platzieren…! (Abstand, im Halbkreis, ….) Open Source: -> große Community, die z.T. kostenlos Skripte bereit stellt bzw. sich zu Dynamo Themen austauscht. -> Eigene Anpassungen von Dynamo sind theoretisch möglich Mehrsprachig verfügbar, Knotenbezeichnungen jedoch Englisch -> Großteil der Anwender/ Entwickler sind im englischsprachigen Raum angesiedelt -> Englisch als die Sprache für Entwicklungen -> Beim erstellen von Dynamo Skripten sind grundkrenntnisse in English vorteilhaft, teilweise wurden die Beschreibungstexte auf deutsch übersetzt.

Mathematische Berechnungen Datamining und Auswertungen Was ist Dynamo? Möglichkeiten Erstellung von komplexer Geometrie durch generische, parametrisierte Konstruktion Mathematische Berechnungen Datamining und Auswertungen Variantenuntersuchungen Datenimport und -export Eigene Funktionalität einbringen Grob darüber hinweg gehen, sollte bekannt sein, ggf. sogar weglassen Erstellung von Geometrie auf mathematischen Grundlage (Bogenförmige Gebilde) Parametrisierte Konstruktion (z.B. Platzierung von Elementen in bestimmten Abständen) Mathematische Berechnungen (z. B. Längen, Volumen, Flächen, Winkel) Datamining (Zusammensuchen von bereits bekannten Daten (Parameterwerte, Flächen, Längen)) Auswertung von gesammelten Informationen Variantenuntersuchung -> Test eines Skriptes mit verschiedenen Parameterwerten Dateiimport/ -export -> z.B. in Excel, Txt, … Eigene Funktionalität einbringen -> eigene Blöcke auf Basis bestehender Blöcke zusammensetzen, eigene Blöcke mittels Python oder .Net (C#, VisualBasic, …) programmieren und bereitstellen

Skripte werden bei komplexen Anforderungen schnell unübersichtlich Was ist Dynamo? Grenzen Skripte werden bei komplexen Anforderungen schnell unübersichtlich Skripte laufen nur über Dynamo, es gibt keine Möglichkeit, die Dynamo-Skripte über einen bestimmten Button zu starten Beschränkung auf bestehende Knoten, sofern keine Programmierkenntnisse vorhanden sind Begrenzte Möglichkeiten bei der Fehlersuche Dynamo-Skripte laufen über Dynamo, kein Start via Externen Button (zur Info -> Es gibt erste Ansätze die dies Ändern sollen aber die Arbeiten direkt mit Anpassungen/ Verwendung von Quellcode) Fehlersuche -> Fehler werden zwar als Kommentar, über dem Block angezeigt, die Ursache kann jedoch oftmals nur über Trial and Error oder entsprechende Erfahrung ermittelt werden

Was ist Dynamo? Grenzen Dynamo-Skripte laufen über Dynamo, kein Start via Externen Button (zur Info -> Es gibt erste Ansätze die dies Ändern sollen aber die Arbeiten direkt mit Anpassungen/ Verwendung von Quellcode) Fehlersuche -> Fehler werden zwar als Kommentar, über dem Block angezeigt, die Ursache kann jedoch oftmals nur über Trial and Error oder entsprechende Erfahrung ermittelt werden

Abgrenzung zur klassischen Entwicklung Was ist Dynamo? Abgrenzung zur klassischen Entwicklung Anforderung Vergleich zur klassischen Programmierung Entwicklungszeit für Erstellung von Skripten Mitunter schneller als klassische Programmierung, da auf vorhandene Blöcke zugegriffen werden kann und der Code nicht geschrieben werden muss Fehlerbehebung Schwieriger als klassische Programmierung, da anders als bei der klassischen Programmierung keine Debugger zur Verfügung stehen Benutzerfreundlichkeit Begrenzte Möglichkeiten bei der Erstellung einer Benutzerschnittstelle, der Skript-Nutzer muss wissen, an welchen Stellen er Änderungen vornehmen muss Zeit für Abarbeitung von Skripten Dynamo-Skripte laufen i. d. R. langsamer als klassische Skripte, da mehr Verarbeitungsschichten durchlaufen werden müssen Entwicklungszeit für Erstellung von Skripten Mitunter schneller als klassische Programmierung, da auf vorhandene Blöcke zugegriffen werden kann und der Code nicht geschrieben werden muss. Es erfordert aber dennoch ein klares Verständnis darüber was man will und braucht (Anforderungsanalyse und Konzeption in beiden Fällen nötig) Fehlerbehebung Schwieriger als klassische Programmierung, da anders als bei der klassischen Programmierung keine Debugger zur Verfügung stehen Benutzerfreundlichkeit Begrenzte Möglichkeiten bei der Erstellung einer Benutzerschnittstelle, der Skript-Nutzer muss wissen, an welchen Stellen er Änderungen vornehmen muss Zeit für Abarbeitung von Skripten - Dynamo-Skripte laufen i.d.R. langsamer als klassische Skripte, da mehr Verarbeitungsschichten durchlaufen werden müssen -> Dynamo-Code wird in Dynamo-intern verwendeten Zwischencode gewandelt, dieser wird in Maschinen-Code gewandelt und dann erst abgearbeitet -> eine Schicht mehr

Dynamo-Grundlagen – Aufbau der Oberfläche, Definitionen und Funktionsweisen

Die Benutzeroberfläche Grundlagen von Dynamo Die Benutzeroberfläche Oberfläche grob erklären, evtl. die Anwender schon mitmachen lassen Menüleiste: Verschiedene Funktionen, wie sie auch von anderen Programmen bekannt sind. Interessant ist der Punkt Pakete. Hier kann sich der Anwender Zusätzliche Pakete mit Blöcken aus dem Internet herunterladen Rechts: Navigation -> Suche von zu nutzenden Blöcken via Navigation im Baum oder Suche im Suchdialog -> Suche greift auf Blocknamen und Beschreibungstext Innerhalb der Navigation sind Blöcke die zur Eingabe/ Erstellung dienen mit +, Blöcke die zur Verarbeitung dienen mit einem Blitz und Blöcke die zur Ausgabe dienen mit einem ? gekennzeichnet Links der eigentliche Editor und zugleich Vorschau für die Dynamo Geometrie (Interessante Pakete: Lunchbox und Clockwork stellen zusätzliche Blöcke für Revitanbindungen bereit, BumbleBee für Excelanbindungen, …) Ausführungsbereich: Hier kann bestimmt werden, ob ein Skript mit jeder Änderung automatisch neu berechnet werden soll, oder nur dann, wenn es manuell ausgelöst wird. PRAXIS –Suche und Navigation von Blöcken

Grundlagen Definitionen Knoten/Blöcke (Nodes): Blöcke kapseln bestimmte Funktionalitäten, z. B. Blöcke zur Dateneingabe und -verarbeitung Verbindungen (Wires): Stellen eine Verbindung zwischen Blöcken her und symbolisieren damit die Weitergabe von Daten zwischen den einzelnen Blöcken Schnittstellen (Ports): Sind die Schnittstellen zur Ein- und Ausgabe von Daten in Blöcke Kommentare (Notes): Dienen der näheren Beschreibung eines Vorgangs Gruppierungen (Groups): Dienen der optischen Zusammenführung von Blöcken zu einer Sinneinheit Begriffe mit dem Bild erklären Blöcke (Number, Point.ByCoordinates) Verbindungen (Linien zwischen Blöcken) -> Die Weitergabe von Daten ist stets von Links nach Rechts. Schnittstellen (Hellgraue Bereiche innerhalb eines Blockes ( >, x, y, Point)) Kommentar (Hellblauer Kasten) Gruppierung (Grüner bereich)

Grundlagen Blöcke Bezeichnung des Knotens Eingabeschnittstelle Ausgabeschnittstelle Informationen zum Verkettungsverfahren (Lacing) Inhalt Spezielle Eingabe- (Teils mit Vorbelegung) und Ausgabeknoten vorhanden -> Bsp. In Bildern (Slider und Number sind Eingabe (+), Point Verarbeitung (Blitz) und Watch (Ausgaben)) Blocken können einzelne Werte oder Listen mit Werten übergeben werden Lacing (Verkettungsverfahren) -> Bearbeitung von Listen, die in einen Block übergeben werden nach Prinzipien der Mengenlehre Falls Fehler oder Warnungen im Skript vorhanden sind, ändert sich die Farbe des Blockes (Warnungen gelb hinterlegt Fehler rot hinterlegt) Bei Selektiertem Knoten werden auch die Verbindungen markiert (Markierung blau) PRAXIS Block Point.ByCoodinates einfügen und Markieren, Wert für x, y oder Z zuweisen -> auf Änderungen eingehen, ggf. auch schon eine Liste via Sequence/Range Block erstellen und an Point Block übergeben

Analysen und Konzeptionen zum Skript

Anforderungsanalyse und Konzeption von Skripten Skripte arbeiten nach den E-V-A Prinzip Informationen werden in irgendeiner Form eingegeben (E) Verarbeitet (V) Und müssen in irgendeiner Form ausgegeben werden (A) Anforderungsanalysen stellen die Fragen Was habe ich?  Eingaben Was brauche ich?  Ausgaben KISS-Prinzip beachten Die Konzeptionsphase beschäftigt sich mir der Frage Wie komme ich zum Ziel? Bewährte Techniken sind z. B. das Top-Down- oder das Bottom-Up-Prinzip EVA – erklären Es lohnt sich in der Konzeptionsphase, d.h. schon vor der eigentlichen Entwicklung des Skriptes tiefgreifender Gedanken zu machen. Dies erleichtert später die eigentliche Erstellung des Skriptes Passend zu EVA -> KISS Bei der Entwicklung sollte stets das KISS- Prinzip (Keep it Stupid Simple) im Hinterkopf behalten werden. Stellen Sie sich zu Beginn nicht zu hohe Ziele und Anforderungen, sondern bauen Sie Ihr Skript Schritt für Schritt auf. Wenn erste Erfolge sichtbar sind, können Sie sich immer noch über mögliche Erweiterungen machen! Konzeption Wie komme ich zum Ziel??? -> Regeln zur Verarbeitung finden. - Dynamo arbeitet Regel basiert, was in Regeln gefasst werden kann, kann auch i.d.R. in Dynamo umgesetzt werden (Ausnahmen bestätigen die Regel ;)) In Konzepte nach dem Top-Down Prinzip erstellen -> vom Allgemeinen zum Speziellen (Was brauche ich?! Wie komme ich zum Ziel?) -> Bei der Skript Erstellung, kann es genutzt werden, um durch Betrachtung eines Eingabewertes im Zielblock auf den Ausgabewert des vorherigen Blockes schließen Realisierung im Buttom-Up Prinzip vom kleinsten Bestandteil zum Ganzen -> Eingabewerte müssen bekannt sein und verarbeitet werden bevor es zur Ausgabe kommen kann

Dynamo feat. Revit – Das Zusammenspiel zwischen Revit in Dynamo

Dynamo und Revit arbeiten prinzipiell unabhängig voneinander! Revit feat. Dynamo Dynamo und Revit arbeiten prinzipiell unabhängig voneinander! Dynamo und Revit können Daten untereinander austauschen. Dazu sind spezielle Blöcke (Kategorie Revit) nötig Der gemeinsame Nenner sind die intern verwendeten Objekte zur Darstellung von Informationen Prinzipiell arbeitet Dynamo unabhängig von Revit, d.h. Dynamo-Skripte könnten auch komplett ohne Revitdaten arbeiten. Ohne die Übergabe von Daten aus Revit nach Dynamo oder umgekehrt, wissen die Anwendungen nichts voneinander. Im Sinne von EVA ist es so, dass Revit-Daten in Dynamo eingegeben werden können, dort Verarbeitet werden und anschließend die Ausgabergebnisse aus Dynamo wieder nach Revit übertragen werden müssen! Während der Verarbeitung kennt nur Dynamo die verarbeiteten Daten. Revit bekommt lediglich Informationen über Endergebnisse und auch nur dann, wenn dies im Skript vorgesehen ist (es entsprechende Blöcke für die Übergabe gibt!) Der Gemeinsame Nenner sind Objekte. Revit stellt Informationen durch Objekte dar und Dynamo tut dies ebenfalls. Daten können nur dann ausgetauscht werden, wenn beide Anwendungen vom gleichen Inhalt sprechen. Beispiele: ein Punkt besteht aus 3 Koordinaten (x, y, z), eine Linie aus mindestens 2 Punkten,… Ein Parameter besteht aus einem Namen und einen Wert (eines bestimmten Types) oder auch die Revit-Hierarchie von Objekten siehe Bild -> Familien sind einer Kategorie zugeordnet und haben Typen bzw. Instanzen. -> Dieses Wissen kann bei der Selektion von Elementen in Revit für Dynamo genutzt werden.

PRAXIS – Erstellung eines Skriptes zum Export von Revit-Daten nach Excel Analyse Was habe ich? Revitparameterwerte je Element Was brauche ich? Eine Auflistung aller Elemente mit deren Parameterwerten in Excel Konzeption Export von Elementen einer bestimmten Kategorie/eines bestimmten Types Die Exceltabelle soll einen Tabellenkopf haben Die Exceltabelle soll folgende Werte haben Die Ausgabetabelle soll erst in Reihe X beginnen Umsetzung Schlagworte überlegen, die bei der Suche von Blöcken zum Ziel führen könnten Welche Knoten gibt es? Führen diese zum Ziel? Nutzung von Codeblöcken PRAXIS EVA Anwenden lassen (Inhalte ggf. erst Später einblenden.) Schlagworte überlegen, die bei der Suche von Blöcken zum Ziel führen könnten: Excel, Parameter, Elements, List Welche Knoten gibt es? Führen diese zum Ziel? „Excel.WriteToFile“, „All Elements of X“, „Element.GetParameterValueByName“ Codeblöcke sind ideal für Eingaben von Werten -> ein Doppelklick genügt und schon können Werte ohne große Umstände definiert werden (Texte in „“, Dezimalzahlen 1.0) Wenn ein Konzept steht lohnt sich bei der Entwicklung oft das eine Methode die an das Top-Down Prinzip angelehnt ist. (Ich nenne Sie „Das Pferd von hinten auszäumen“) -> Letzten Block (Excel.WriteToFile) zuerst einfügen und anhand der Eingabewerte Schritt für Schritt sich die Eingabe-Blöcke zusammen suchen Filepath, Sheetname, StartRow, StartCol, overWrite sollte klar sein, doch wie die zu exportierende Datenmenge zusammensuchen? Exceltabellen sind Listen (oder Mehrdimensionale Mengen -> hier: Elemente und deren Parameterwerte) Elemente können via Selektion oder Filterung zusammengesammelt werden -> Werte ansehen (via Watch der Vorschau) Parameterwerte können unter Angabe des Parameternamens angegeben werden -> Werte ansehen (via Watch der Vorschau) Der Block „Element.GetParameterValueByName“ gibt eigentlich zu jedem eingegebenen Element den Wert eines Parameters mit einem bestimmten Namen an. Dieser Block hat, wie jeder andere Verarbeitungsblock auch, die Möglichkeit die Verkettung (Mengenlehre) anzugeben. Wenn mehr als nur ein Parameter berücksichtigt werden soll, kann dies über ein Kreuzprodukt der Liste mit Elementen mit der Liste der Parameternamen realisiert werden -> Fertig ist die Ausgabeliste. Fehlen nur noch die Header Hier gibt es zum Glück einen Block mit dem Namen (List.AdditemInFront) -> Dieser kann genutzt werden, um die Parameternamen als Header an die Ausgabeliste zu setzen

Und nun? – Zusammenfassung und Ausblick

Und nun? – Zusammenfassung und Ausblick Frage: Was ist Dynamo? Aufbau von Dynamo Tipps und Tricks zum Thema „Erstellung von Skripten“ Zusammenspiel zwischen Revit und Dynamo Umgang mit Dynamo Ausblick Blogbeiträge zum Thema Dynamo zur Vertiefung (blog.nupis.de) Webcast zum Thema bei dem offene Fragen angesprochen werden können Schulung Kundenindividuelle Skripte Consulting

Zeit für Fragen Gern stehen wir Ihnen auch im Nachgang der Veranstaltung zur Verfügung Tim Hannewald Consultant AEC/BIM Telefon: +49(351)8471131-19 Mobil: +49(175)4351434 E-Mail: Tim.Hannewald@nupis.de