FWIW the ‘ToDS’ line of most Dynamo for Revit graphs is all that has to be modified to remove cross session binding there. No idea if it is that simple in Dynamo for Civil.
Update on my case - I used the Python method described above, thank you for this! My only hold-up was realizing (“Autocad.Application”) was a continuation of the previous line. It’s been a long time since I’ve used any Python.
In my case to prevent the Python node from running until my features were finished being created in Civil3D, I just created a list from the outputs of those Autocad nodes feeding into a dead-end variable. Yes, I’m assuming that the Autocad Nodes don’t send to this list until Civil3D has actually finished, which may not be the case. But Civil3D seems to be getting the commands in the right order.
1 Like
Can you post the content in that group as a new dyn so that others can benefit from it?
1 Like
This is not working for me. Am I missing something?
Yes, you must reopen Dynamo before running the graph again.
Still doesn’t work. What’s even more unusual is that I drew the vertical line shown manually without Dynamo.
I can confirm it. It seems they ‘fixed’ this in the most recent Dynamo where the binding is ALSO saved in the graph.
I am at a point now where I really start to hate Dynamo… 
That’s scary…
With Dynamo player, I’m getting no bindings. In fact, I don’t even have to remove the bindings from the DWG. They aren’t even created. So, it appears that if you want binding, you need to run from Dynamo. If you don’t want bindings, you have to run from Player.
Disregard that. I re-tested with a fresh session and drawing and I do get the bindings with Player unless I remove them from the DWG.
What’s your C3D Version?
I confirmed your results. Now we just need consistent results between Dynamo and Dynamo Player.
The player has it’s own issues:
I have created a lisp routine with just this line of code
(DictRemove (namedobjdict) “DYNAMO_TRACE_DATA”)
Then I load it into Civil3d-Autocad and it loads fine … Now, then I try to execute it with the command “file_name.lisp” but it doesn’t work for me. It says it is not a command …
Am I missing something?
Thanks for the support
You should define a function in that lisp.
But it would not help you much since the binding is also saved in the graph file (nobody knows why the programmer thought that was a good idea).
the function is not "(DictRemove (namedobjdict) “DYNAMO_TRACE_DATA”) ??
What else does the lisp code need?
GvdB It seems that it works, although I don’t understand how it does it.
1 Like
The goal was to have a DYN workflow which wouldn’t require ‘delete and try again’ every time the base input (ie: building massing/ corridor) was revised.
So the concept behind bindings becomes this:
- Run the graph to create a bunch of stuff
- Save the graph to serialize the bindings into the DYN
- Later when you need to adjust the bunch of stuff to match the new schematic, simply open the graph which contains the bindings, and the previously created graph WITH ALL OF THE ADDITIONAL UPDATES moves to the new location.
The mark values which were done by hand? Maintained. The dimensions which were associated to the element/object? Still there. Less data is lost (even no data if you’re really managing things well). obviously this saves time by removing the need for having to build a second version of the graph which grabs all the downstream changes from the first set of created elements/objects, and pushes them into the correct 2nd stream of elements/objects, and then deleting the first set of elements/objects.
Ok, so with the ‘why it exists’ set in place, let’s review the 'why save it into the DYN file bit. This is pretty common sense when you think about Dynamo beyond the context of any one integration, but hear me all the way out.
Since Dynamo was always intended to be integration agnostic, relying on an aspect of a single file type (ie: RVT via extensible storage, or DWG via… whatever aspect of the file is used) isn’t an option. Thus far I’ve only talked about Revit and Civil 3D examples, and I haven’t mentioned the integrations for FormIt, Alias, Advance Steel, Fusion, and all the others which are out there already or will be some day. Imagine having to write a single application which could serialize data to an unknown format using an unknown aspect of the file which could require a complete rewrite at any given year. Sounds tough, right?
As such, things have to live with the file, and record the data in whatever format the integrating application needs. The data needed to write is already available via the integration (otherwise we wouldn’t be able to write it), but the method of storing it in the various file types isn’t. So instead it is saved in the DYN - the software authors just have control over that format no matter what changes the integration file may have over the years.
Another way to think of it is like your standard details - they don’t live in the project folder, they live in the standards because it’s consistent across all uses. Dynamo’s DYN is that (in this case), while the DWG/RVT/RFA/AXN/WIRE/whatever is the project folder. Things you’ll use in EVERY project want to live in the standard (DYN), not the project folder (whatever format the file is).
The part which makes does not make any sense is attempting to circumvent the bindings in the C3D environment but not completely rewriting the Dynamo nodes so they don’t leverage the DYN session trace and instead rely on the DWG session trace. By leaving them in both the C3D integration made everyone’s life a bit more miserable by packing the same data into two spots, and it’s unclear how the two will interact without significant testing (in your specific Dynamo and C3D environment).
1 Like
Well, my post might sounded a bit sarcastic, but there is really no good reason to save the binding in a graph (despite your explaination). The drawing objects belong to the drawing and it is already possible to save bindings in the drawing. The graph does not and should not belong to a certain drawing, so there is really no reason to save such a connection inside the graph.
At this moment the binding is saved in the drawing AND the graph. This makes the graph part of the drawing and demotivates running the graph in other drawings. Also this technique result differently in the application and in the Dynamo Player, which is really bad behavior.
What if Lisp from origin saved a connection to a drawing inside the Lisp file, so it becomes unuseful to other drawings. Or what if a user draws a polyline with a Lisp function and a previous polyline would disappear. Without trying to compare Dynamo with Lisp if those are the same solutions.
Anyway, it is my (and certainly not only mine) opinion that the binding should not be saved in the graph, but in the drawing only, where I as user have my own reasons and possibilities to remove the binding when I want to. I found Dynamo becoming less useful since each release and I noticed I less and less use it since then. I strongly hope the next release will become useful again (and that is the moment the binding is not saved in the graph anymore 
)
1 Like
For people like me that were used to automate via LISP/Script/.NET macros and plugins, Dynamo was great because it was not “fire-and-forget”, it implemented CRUD by default, without the user knowing what was going on under the hood, using the very same graph and making the developer life much much easier. Also to democratize the access to automation you had to make some assumptions for the end user (that probably never heard of CRUD and doesn’t even want to know).
There is a catch though: the bindings and the session trace data, their lifecycle and how they affect performance.
The agnostic integration that Jacob mentioned is critical to understand why some choices have been made.
When I wrote CivilConnection I faced similar design decisions and I resolved to do the serialization of the elements created by CivilConnection (not by all Dynamo nodes) outside of the Revit document; I could have used hidden shared parameters or extensible storage but since I don’t like to deal with those as a user and I wanted to give visibility to check what was going on in a human readable format I opted for a very basic technology: external XML file named after the Revit model.
This brought the advantage of having the same CRUD behavior in Dynamo Player where instead this was not possible (at least on Revit based workflows).
In CivilConnection there is a catch: the workflows to create and update elements are separate, you have an update node that does only that, whereas in principle in Dynamo the same graph can be used to create and update the elements. Is it a good thing or not? I prefer to have full control of what is happening, maybe someone has a different opinion.
Also you have these XMLs popping up in the work folder, but it felt like an acceptable solution at the time, perhaps I will change how that works in a future release.
The other aspect is to consider Dynamo as something that extends the intelligence of the model and as such it was plausible to include the necessary hooks in the graph directly.
It was a differentiator from the “baking” approach of other visual programming platforms: the dynamic connection between an element and the logical rules that control it is the key feature that should be preserved. If it were possible to give more control to the end user I would, I know for a fact though that some companies do not want that.
3 Likes