When 3Dsolid are created from a script they appear just fine, but when the script is rerun the originally created 3Dsolid disappear. Is there a way i can fix this?
2 Likes
This behavior is a result of element bindings. From @Paolo_Emilio_Serra1âs AU 2019 class:
When the Dynamo application is visible and the graph creates objects in the DWG, the trace of the Dynamo owned objects can be serialized in the Dynamo file itself. For each node that creates objects from Dynamo into the DWG, Dynamo stores their âfingerprintsâ in the Bindings section of the Dynamo JSON structure, so that if the inputs change, Dynamo can confidently update only the objects that are owned by the graph accordingly.
I believe that this was changed with Dynamo for Civil 3D Update 2, where the bindings are now serialized in the DWG itself (see release notes below).
All that being said, you can try running the script with Dynamo Player. I think this is a âfire-and-forgetâ method, meaning that new solids will be created instead of updating old ones. If you donât have Dynamo Player yet, you can click the âRun Scriptâ button in the Manage tab to accomplish the same thing.
Here are some more resources about element bindings:
1 Like
Can you try running it on a different DWG?
Element binding in Dynamo for Civil is now an odd duck. Anything which applied to the same concept in Revit is not the case in Civil 3D, as there are a bunch of issues on that front.
In Revit, bindings would serialize the Globally Unique Identifier of the element which is created. THis means that that ID will be unique to that element. If you open another file (unless it was a copy of the first file) the GUID will not match in any way. Therefore bindings can work with specific elements, no matter what.
In Civil 3D that is not the case, as there is no GUID and Object ID is consistent. So serializing into the file doesnât work by itself (earlier Dynamo for Civil 3D did this, and objects could be âswapped outâ unknowningly as a result - see the âknown issuesâ page of the first release for more info - Help). To prevent this, there is now also element binding data saved into the DWG (see the release notes for Dynamo for Civil 3D 2020.2 - Help). As a result of this change, Dynamo Player will NOT circumvent bindings and alternative methods will need to be found.
Trying another DWG and coming back to this one would maintain the binding (to some extent anyway). Likely a new dyn (save as) would be a requirement to avoid them. Unfortunately this is a low priority for me as the customers I support design buildings and primarily leverage Dynamo for Revit with some sandbox mixed in.
1 Like
Dynamo is a great and powerful tool but it has two major design flaws: geometry scaling and persistent element binding. I think this will people hold back from using Dynamo, especcially because of the latter.
Element binding as a feature is not bad, but not how it is designed now. The first version of Dynamo only had session based element binding and that is ok. It would even be better if Dynamo leaves the generated geometry when you choose another alignment or surface or whatever, and only update geometry if parameters change like stationing or so. I can understand that this is really difficult to design so session based element binding is the second best.
Persistent element binding however is a really, really bad designed feature. It is an unpleasant surprise for users when somewhere in the drawing geometry will disappear when you perform a task on another alignment or surface or corridor. Users need scripts that can run on other objects in the drawing as well. How would we react if AutoCAD removes the just drawn polyline if you draw a second one? That is wat persistent element binding does. So I really hope the designers will remove this feature and keep it session based.
Meanwhile I am glad the element binding data is saved in the NOD of the drawing (and not in the script anymore) so it is easy to remove it with just one line of Lisp:
(DictRemove (namedobjdict) "DYNAMO_TRACE_DATA")
Dynamo does not use this data during the session, it only saves it after running the script, so it will not help deleting the data while Dynamo is open. It only works when Dynamo is closed and reopened. The workflow is this:
- Run the script and close Dynamo
- Delete the binding data from the drawing with the lisp call
- Open Dynamo and run the script on other objects
Another one, even better (@GvdB: this is your solution):
- Prepare the script for use in the Dynamo Player
- Run the script from the Player
- Delete the data with the lisp call
- Rerun the script from the Player (it does not have to be closed)
Now you can design your script so that you can select a single object, run the script and do that process on another single object without accidentally deleting the generated geometry.
Hope it will help other people to get faith in Dynamo again 
8 Likes
Cool! Even better! Can you show how you added the lisp to your script? Is it done with Python?
I didnât examine such a thing because I was convinced Dynamo saves the data when the complete script has finished, so deleting it while in the running process probably does not help.
1 Like
I have used a custom node from Clockwork to wait for the script to finnish.
The python script i have used is to send a command in autocad. The command can be used to run the LISP.
6 Likes
Nice solution! 
Now you have first loaded a Lisp routine in the drawing with the name DDD, but instead of an external Lisp you also can pass the Lisp line mentioned above. You need to escape the quotation marks in a Code Block or use the String Node.
Then you are fully independend of external lisp files.
Maybe you need to use the (vl-load-com) call for that function, but Lisp is easy. Pass this as a Command Line call instead with a String Node:
(vl-load-com)(DictRemove (namedobjdict) "DYNAMO_TRACE_DATA")(princ "Dynamo data removed from drawing!")(princ)
To make it even better, you can create a Custom Node of this 
5 Likes
FYI @nigel.peters
Anton,
Thanks for your feedback, bindings are a major area of investigation and under review inside Dynamo for Civil 3D. How and when they are sorted very much depends on the use case. Scrips can be used for a lot of workflows, for some like the video above it probably makes scene not to sore any bindings (either in the script file or the dwg) for others bindings are extremely useful.
You agree that there are user cases where binding is absolutely not useful. But Dynamo does not provide a solution for such situations.
I canât think of any case where persistent element binding is necessary in a Civil 3D project, so I wouldnât mind if this feature becomes session based, as it was in the beginning. But if not, make it at least optional (per script or as user preference). Then you serve both situations.
2 Likes
Thank you for this. We ended up adding a button to our custom ribbon to run this. Then the user has the option of when/if they want the bindings purged. Itâs too bad this is all or nothing per dwg at this point. There needs to be a way to keep bindings for some scripts, but not others.
1 Like
Iâll take a stab at this using a real example from when I was still practicing, but we didnât have Dynamo at the time.
Imagine a graph for placement of a pair of polygons sent by the building architect for building outline and an associated driveway into a wooded site. Every tree within 30â of the building and 5â of the drive needs to be demolished, all other trees can stay as they are, but for each demolished tree a new one is to be planted using a somewhat randomized logic routine in the graph.
You then layout the utility connections, dimensions and all the rest of the work by hand as usual, including annotations and the like. Three weeks after your DD set goes out the architect has a new layout which effectively requires a complete rework of the design - the changes are minor from an architectural perspective - the building rotates and has some fairly minor massing adjustments, but itâs quite complex from your standpoint. Some amount of trees marked for demo will now need to not to be, some other amount will need to be, and most importantly all your new trees will also need to be recalculated and redistributed about the site.
If you have persistent binding you can run the same graph with confidence the counts will be correct, and you can concentrate on finishing the other outstanding work from this change and general development of your work.
If you donât have binding you get to spend some time doing the work by hand, or âresettingâ your data set to be in line with where you were before the prior graph was used so you can truly âstart from scratchâ.
All that said if you are âautomating a simpler but tedious taskâ in small sections of a design, there is admittedly less value here.
Thanks Jacob for the example. So it might be handy to have persistent binding, in some cases.
But there is no solution for all the other workflows were persistent binding is absolutely unuseful. I hope the binding will become optional as soon as possible.
4 Likes
I agree wholeheartedly.
6 Likes
Count my vote for being able to turn off binding. Perhaps it just needs to be a new node that we can chose to include in our script so my end users donât have to change settings between running different scripts. It looks like people here have already done a good chunk of the development for the dynamo devs.
In my case - I have a script that generates a coordinate grid with labels for plan drawings in civil3D, from a polygon representing a viewport. Some drawings have more than one viewport that needs to be gridded. Run it for a second grid - and you lose the first grid. Sigh.
I create the features on separate layers for each viewport. The binding is so strong that if you lock the layers holding the results of the first run, a new run of the script will fail despite the script not being told (by me) to use anything on the locked layers.
Likely the best solution will be a âcopy created elementsâ method which circumvents the bindings. Such a method via the Revit methodology is quite simple (see my AU course in element binding for Revit), but I am not familiar with the Civil3D API so how such could be similarly achieved isnât clear.
Yes, for the script Iâm working on, it could be run by copying the starter polygon into a blank file, then copy results into production drawing. Repeat in a new blank drawing for another viewport. But itâs extra steps my users shouldnât have to do.
Iâm playing with the Python method that was described above - but itâs been 15 or so years since I touched python