Wat zijn Object Bindings in Civil 3D Dynamo

Wie veelvuldig Dynamo gebruikt, zal weleens nagedacht hebben over Bindings. Object Binding is een methode in Dynamo om een koppeling te behouden tussen het script en de gemaakte objecten. Zo zal het je waarschijnlijk zijn opgevallen dat als je objecten plaatst in Civil 3D, en je wijzigt wat parameters, dat daarna de gemaakte objecten verdwijnen en nieuwe objecten tevoorschijn komen. Wat natuurlijk superfijn is, want zo kun je van alles finetunen voordat je de definitieve geometrie laat staan in de tekening.

Instellingen

Bindings worden apart van de instellingen ingesteld, en dat gebeurt via het menu. 

In dit voorbeeld is aangevinkt dat de Binding opgeslagen moet worden in het script en in de tekening. Op twee plaatsen dus. Maar is dat logisch? Of wat zijn de gevolgen als je dit doet? Eerst maar eens kijken wat die Binding data dan is.

Binding data in de tekening

Als voorbeeld kun je Civil 3D objecten plaatsen in de tekening, in dit geval een setje Cogo Points.

Met behulp van een Inspector kun je de tekening doorspitten om te kijken wat er allemaal in zit. Dynamo Binding Data wordt opgeslagen in de NOD (Named Object Dictionary) van de tekening.

De Result Buffer bevat data, als je hier op klikt dan opent een nieuw venster.

Een lekkere brei van karakters. Nu moet je een beetje een programmeur zijn om te zien wat voor data dit is. Het is Base64 Encoded tekst, en om het werkbaar te houden is de tekst in korte brokjes (chunks) opgedeeld. Tot zover het nerd-achtige hiervan. De data in de Graph, of script, is beter te lezen.

Binding data in het script

Het script met de extensie DYN is feitelijk een JSON bestand. Dit is tekst volgens een bepaalde opmaak wat computers eenvoudig kunnen lezen. Open je de opgeslagen Graph in een tekst editor, dan zie je dit:

Hier zie je dezelfde Binding data terug, maar dan niet opgeknipt in stukjes. Een beetje programmeur kopieert nu deze tekst naar het Klembord, bezoekt een website waar je Base64 code kan decoderen en kijkt wat er achter die tekst zit.

Base64 Decode

Het bovenste deel is de encoded tekst, het onderste deel is decoded tekst. Dit laat zien dat het XML data is met allerlei properties. Een van deze elementen bevat opnieuw encoded tekst. Ook dit kun je kopiëren en decoderen.

Nu ben je eindelijk beland bij de belangrijke data, namelijk de Binding naar een object, door middel van een Handle. Een Handle is een opvolgend nummer die toegewezen wordt aan elk object in de tekening en daarmee teruggevonden kan worden. Als je de gemaakte Cogo Points langs gaat en met het commando LIST de eigenschappen opvraagt, dan kom je vanzelf bovenstaande Handle tegen.

Bizar veel data voor één koppeling…

Effect van Bindings

Dynamo gebruikt deze Binding om het eerder gemaakte object te verwijderen of aan te passen bij wijzigingen. Handig toch? Zo wordt je tekening niet gevuld met honderden Cogo Points of Alignments bij elke finetuning. Of is het niet zo handig? 

Om te beginnen, de Binding is op deze manier erg stevig. De data wordt zowel in het script als in de tekening opgeslagen. Persoonlijk vind ik niet dat de Binding in het script thuis hoort, want een script wil je vaak vaker kunnen draaien in andere tekeningen. Het gebeurt maar zelden dat je een script specifiek maakt voor één tekening. Ook komen Handles met hetzelfde nummer voor in andere tekeningen, want AutoCAD begint altijd zo laag mogelijk op te nummeren. Wat gebeurt er dan met de objecten in een andere tekening?

Bij een test blijkt dat de objecten in een andere tekening met dezelfde Handle en van hetzelfde type, domweg worden verwijderd als het script opnieuw wordt gestart. Ik heb nog niet geconstateerd dat andersoortige objecten maar wel met dezelfde Handle verwijderd worden. De kans is natuurlijk erg klein dat dit optreedt, het risico is dus beperkt in een andere tekening. Maar het kan voorkomen, en dat maakt het gevaarlijk! In de andere tekening bestaat zo’n object niet voor niets, je wil niet dat Dynamo dit object ongemerkt laat verdwijnen.

Want dat is wat gebeurt, het oorspronkelijke object verdwijnt gewoon. Ook na lange tijd, zeg bijvoorbeeld over een half jaar. Ook in de oorspronkelijke tekening. Stel dat je een pracht van een Alignment hebt ontworpen met een script. Daarna heb je deze in je workflow gebruikt om andere Alignments op aan te sluiten, een Corridor gebouwd, Profiles gemaakt, en noem maar op. Na een maand of wat wil je hetzelfde script nog eens gebruiken in dat project om op een andere plek eveneens een Alignment te plaatsen. Je past de parameters aan, zoomt in op de plek waar het moet gebeuren, je runt het script, voila, een mooie Alignment als resultaat. Trots en tevreden sla je de tekening op. En pas veel later kom je erachter dat de eerste Alignment spoorloos is, en niet alleen dat: alle gekoppelde objecten zoals Profiles, Offset Alignments, Corridors, Surfaces, noem maar op. Allemaal weg! Als dat overigens wel de bedoeling is, dan is Binding data in de tekening inderdaad de beste plek om op te slaan.

Optimale instelling

Kun je dan beter geen Bindings gebruiken? Of geen Dynamo? Jawel, en het kan zelfs probleemloos. In vrijwel alle gevallen is de beste instelling het afvinken van alle Binding opties, dus zo:

Geen data in de Graph (of script), niet in de tekening en ook niet voor de Dynamo Player. Nu blijft de binding alleen onthouden tijdens het uitvoeren van het script. Je kunt dus naar believen finetunen en de gemaakte objecten zullen tijdens de sessie voortdurend verdwijnen of verplaatsen. Maar eenmaal Dynamo te hebben afgesloten of een andere tekening te hebben geopend, zal de Binding kwijt zijn en kun je probleemloos met een nieuwe set objecten werken. De oude blijven behouden en raak je niet zomaar kwijt.

De bovenste optie: ‘No Binding Data Retained’ kun je beter ook niet aanvinken. Deze optie zorgt ervoor dat zelfs tijdens de sessie, bij elke Run, de Binding al kwijt is. Elke finetune actie zorgt dan weer voor nieuwe objecten.