Revit mit Dynamo automatisieren, ohne das Modell zu beschädigen

Was Dynamo im Modell tatsächlich anstellt

Dynamo läuft innerhalb der Revit-Sitzung und arbeitet über dieselbe Programmschnittstelle, die auch Zusatzmodule benutzen. Was der Graph schreibt, ist deshalb keine Sonderform von Daten, sondern eine ganz normale Änderung am Modell, so als hättest du sie von Hand vorgenommen. Das ist die gute Nachricht, weil alles, was Revit sonst kann, auch für diese Änderungen gilt. Und es ist die schlechte, weil ein Fehler genauso echt ist wie eine Änderung von Hand, nur eben tausendfach.

Autodesk beschreibt Dynamo als Werkzeug, um wiederkehrende Aufgaben zu automatisieren, komplexe Entwurfsfragen zu untersuchen und Abläufe im Modell zu verkürzen, und liefert dazu Beispielgraphen mit, die genau diesen Zuschnitt haben. In der Sammlung für Dynamo Player finden sich etwa Graphen, die eine bestimmte Zahl von Geschossen über einer gewählten Ebene anlegen, die Belegungszahl eines Raums rechnen, alle nicht beschrifteten Elemente der aktiven Ansicht auswählen oder Blattnamen in Großbuchstaben umschreiben. Das ist ein guter Maßstab für die Größe einer Aufgabe: eine Sache, klar begrenzt, mit einem nachprüfbaren Ergebnis.

Wichtig ist der Unterschied zwischen dem, was du im Vorschaufenster siehst, und dem, was im Modell steht. Die Vorschau zeigt das Ergebnis der Berechnung im Graph. Ob dieses Ergebnis auch dort angekommen ist, wo du es haben wolltest, steht in den Eigenschaften des Bauteils oder in einer Bauteilliste. Der Blick dorthin ist der einzige Nachweis, der zählt, und er dauert eine Minute.

Die Stellen, an denen ein Lauf ein Modell beschädigt

Die häufigste Ursache ist eine zu weite Auswahl. Wer alle Elemente einer Kategorie einsammelt, bekommt in einem echten Projekt regelmäßig mehr, als er meint: Bauteile aus verknüpften Modellen, Elemente in Gruppen, Bestandteile von Familien, Objekte in Konstruktionsbereichen, die längst nicht mehr aktuell sind. Deshalb gehört hinter jede Kategorieabfrage ein Filter und dahinter eine Anzeige der Anzahl. Wenn dort 4.812 steht und du mit rund 300 gerechnet hast, hast du gerade einen sehr teuren Fehler abgefangen.

Die zweite Ursache ist die Verwechslung von Exemplar und Typ. Ein Typparameter beschreibt eine Eigenschaft, die für alle Bauteile dieses Typs gilt. Schreibt ein Graph dort hinein, weil der Zielparameter zufällig denselben Namen trägt wie ein Exemplarparameter, verändert er das Projekt an einer Stelle, die niemand im Blick hat. Sichtbar wird das oft erst Wochen später, wenn die Auswertung nicht mehr aufgeht. Deshalb gehört vor jedem Schreibvorgang die Frage geklärt, an welchem der beiden Orte der Parameter sitzt.

Die dritte Ursache ist das Löschen. Ein Graph, der Elemente entfernt, ist schnell gebaut und richtet mehr Schaden an als jeder falsch gesetzte Wert, weil die entfernten Bauteile keine Spur hinterlassen. Behandel solche Graphen anders als schreibende: Lass sie zuerst nur ausgeben, was sie löschen würden, sieh dir diese Liste vollständig an, und führ das eigentliche Löschen erst in einem zweiten Lauf aus.

Und schließlich der Betrieb: In einem Modell mit Worksharing leiht sich ein Lauf über viele Bauteile diese Elemente aus. Bis zum nächsten Synchronisieren kommt niemand anderes an sie heran. Bei einem Graph, der über ein ganzes Geschoss läuft, kann das für ein paar Minuten das halbe Team ausbremsen. Das ist kein Fehler, sondern das erwartete Verhalten, aber es gehört angekündigt.

Wann Dynamo die falsche Antwort auf die richtige Frage ist

Ein großer Teil der Graphen, die in Büros entstehen, löst Aufgaben, für die Revit bereits ein Werkzeug mitbringt. Für das Zählen, Summieren und Gruppieren ist die Bauteilliste gebaut, und sie hat den entscheidenden Vorteil, dass sie mit dem Modell mitläuft, statt einen Stand von gestern einzufrieren. Für das Einfärben oder Ausblenden nach einem Wert gibt es Ansichtsfilter. Für abhängige Maße gibt es globale Parameter. Wer diese Wege überspringt, baut sich eine Automatisierung, die er ab sofort pflegen muss, obwohl das Programm die Aufgabe von selbst erledigt hätte.

Die Faustregel dafür ist einfach: Dynamo lohnt sich, wenn eine Aufgabe wiederholt anfällt, viele Elemente betrifft und in Revit nur über viele gleichartige Handgriffe zu lösen wäre. Es lohnt sich nicht für einen einmaligen Eingriff an zwanzig Bauteilen, weil das Bauen und Prüfen des Graphen länger dauert als die Handarbeit, und das Ergebnis ist obendrein weniger sicher.

Ein Sonderfall ist das Untersuchen von Entwurfsvarianten. Dafür gibt es in Revit die Generative Design genannte Funktion, die im Reiter Verwalten sitzt und Studien auf Grundlage von Dynamo-Graphen rechnet. Autodesk weist ausdrücklich darauf hin, dass sie in Revit LT nicht zur Verfügung steht. Wenn deine Frage lautet, welche von hundert Anordnungen die beste ist, ist das der passendere Weg als ein Graph, den du hundertmal mit anderen Zahlen startest.

Packages: die Abhängigkeit, die du dir mit einem Klick einhandelst

Sobald ein Graph einen Node aus einem fremden Package benutzt, hängt er nicht mehr nur an Revit und Dynamo, sondern zusätzlich an einer Sammlung, die jemand außerhalb eures Hauses pflegt. Das ist völlig in Ordnung und spart oft viel Arbeit, es muss nur jemand wissen. Dynamo Player zeigt fehlende Abhängigkeiten in einem eigenen Dialog an, und genau dort landen Kollegen, wenn sie einen geerbten Graph zum ersten Mal starten.

Deshalb gehört zu jedem Graph eine Notiz, welche Packages er in welcher Fassung braucht. Ohne diese Notiz beginnt jeder Fassungswechsel mit Raten. Praktisch bewährt hat sich, die Zahl der benutzten Packages bewusst klein zu halten und im Zweifel den umständlicheren Weg mit mitgelieferten Nodes zu gehen, wenn ein Graph im Team laufen soll und nicht nur auf einem Rechner.

Für den Fassungswechsel selbst reicht eine kurze Liste. Nimm die Graphen, die tatsächlich benutzt werden, führ sie in der neuen Fassung an einem Testmodell aus und hak sie ab. Autodesk dokumentiert auch bekannte Eigenheiten, etwa dass ein Graph mit einem älteren Node für die Eingabe von Fuß und Zoll in Dynamo Player einen neuen Wert zwar anzeigt, ihn aber nicht verarbeitet, und dass dann der Austausch gegen den neueren Node hilft. Solche Fälle findest du nicht durch Nachdenken, sondern nur durch Ausprobieren.

Node Autocomplete: was ein Prozentwert bedeutet und was nicht

Beim Bauen des Graphs hilft dir Dynamo mit Vorschlägen: Ein Doppelklick auf einen Ein- oder Ausgang zeigt dir Nodes, die dort passen. Für die Reihenfolge gibt es zwei Verfahren. Das eine sortiert schlicht nach dem Datentyp, den der Anschluss annimmt. Das andere heißt Recommended Nodes, arbeitet mit einem Empfehlungssystem auf Grundlage von maschinellem Lernen und ist standardmäßig eingeschaltet.

Autodesk beschreibt dieses Verfahren ungewöhnlich offen. Die Empfehlungen beruhen auf der Auswertung, welche Nodes in tausenden Beispielgraphen zusammen benutzt werden, ausdrücklich nicht auf einer Auswertung deiner eigenen Arbeit. Für die Nutzung musst du einmalig einer Vereinbarung zustimmen, und wer das nicht möchte, arbeitet mit dem anderen Verfahren weiter. Jeder Vorschlag trägt einen Prozentwert, der angibt, für wie wahrscheinlich das Modell diesen Node an dieser Stelle hält.

Wichtig ist, wie dieser Wert zu lesen ist. Autodesk schreibt selbst, dass diese Werte Vorhersagen sind und deshalb nie vollständig zutreffen werden. Ein hoher Prozentwert heißt: In vergleichbaren Graphen kam dieser Node an dieser Stelle häufig vor. Er heißt nicht, dass der Node deine Aufgabe löst. Für die Arbeit ist das trotzdem nützlich, weil es die Suche in einer sehr langen Liste abkürzt. Es ersetzt nur nicht den Blick in die Beschreibung des Nodes, bevor du ihn an einen schreibenden Zweig hängst.