Originally created object disappears when i rerun the script

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… :face_with_symbols_over_mouth:

That’s scary…

Hi @keith.sowinski @Anton_Huizinga

Try using Dynamo player:

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:

  1. Run the graph to create a bunch of stuff
  2. Save the graph to serialize the bindings into the DYN
  3. 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 :slight_smile:)

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.


Despite your belief that this binding mechanism is a good thing, we as users don’t have any choice if we want to use binding or not, we are forced to use it. But there are lots and lots of situations where persistent binding is not desired, especcially the way it is designed now.

If I create things along Alignment 1 and want to do the same (maybe with a few changed parameters) along Alignment 2, I have to create a new graph or duplicate a bunch of nodes, even if it is months later, or I have to design the graph in such a way that Alinment 1 and 2 are both processed taking different parameters into account. It makes the whole process more complex, and the removal of previously generated geometry months later can be an unpleasant surprise if we forgot that we runned the graph earlier. It would already help if the binding is limited to the original source objects and not to the whole drawing, but having a choice is much better (we are not all silly users that never heard of CRUD or don’t want to know :slight_smile: ).

A few months ago I had a meeting with the D4C3D Product Owner to show situations where binding is undesired. I hope it will lead to better insights and that the binding system will be redesigned.

Further I am still not convinced that a graph should bind to a certain drawing. If so, why not force saving the graph in the projectfolder of the drawing. Or forbid running the graph in another drawing. The way it is designed now is terrible (from a programmers view) and will lead to unexpected situations (from a users view):

  • The graph saves the binding but still can be runned in other drawings. Why if a graph should have bond to a certain drawing? After a rerun the binding data in the graph is overwritten so there is no connection to the first drawing anymore. This already shows the uselessness of saving inside the graph.

  • The binding is saved in the drawing and in the graph. Why duplicate data?

  • The Dynamo application and the Dynamo Player give different result. The Dynamo Player leads even to very unpredicted situations because it leaves geometry that should have been removed from a binding view.

If the graph should not save the binding data, then it is useful for a lot more situations and I would have possibilities to remove the data from the drawing if I need to. It might not be your opinion. I respect that but I strongly hope some day Dynamo will become useful for situations where binding is not needed or wanted.

These issues are only due to the implementation of Dynamo and Dynamo Player in AutoCAD/Civil 3D.
This is different, and for no good reason, from other hosted Dynamo implementations.
You always had the possibility to run your commands from a Python Script node to skip bindings so it’s not at all true that we did not have any choice.
It could have been more discoverable for sure but if every integration has its own rules is not good.

The subject of linking is interesting when you do code tests, but when you work permanently it is not a good thing. Anyway, I have solved the issue with Lisp, as discussed in that post earlier. Despite this, I do not understand that sometimes it is linked and sometimes that does not happen. For example, in a routine I have created Feature lines and those remain fixed, they are not deleted when you rerun the code with another element from the Player. I don’t know what the premise is for some to be linked and others not.

1 Like

Because the Civil 3D team which implemented this thought they could do bindings better when they built their integration. They were incorrect.

This sums up the issue entirely. By forcing serialization into the DWG you can’t circumvent bindings, ever, without stepping away from the OOTB tools. Had the bindings continued to be managed in the DYN:

  1. It’s easy enough to clean manually (you can automate it via DYN or write a view extension).
  2. You can chose to maintain bindings (save the dyn as a new version for each dwg in each project - difficult sure but a highlight of the failure of 40ish year old DWG concept rather than a problem with Dynamo).
  3. You can choose to circumvent bindings via Dynamo Player.

These are the three things which users of Revit have and make use of daily. Why the C3D team decided to go off script and make everyone’s life so difficult is beyond me. To make things more complex, I believe that the Dynamo team is looking into bindings at some point in the nearish future to make them easier to manage for everyone except the C3D integration which will we’d to revisit their off script effort.

This is true and by design. Imagine that graph you write to make objects along an alignment. Are you 100% certain that as you write the graph you will only ever need to hit run once? Bindings are the tool which prevents all of our intermediate “studies” which occur as we author a graph from being pushed into the dwg permanently. Yes you can do a save as of the dwg and build the graph in there (and maybe you should) every time, but that will be a new save as for each and every edge case you discover as you go (which is often a lot on the AE world). Overall bindings are good for most uses, but the way they are implemented is important.

All in it isn’t a perfect system, but it works for everything but D4C3D. Currently a save the dyn per-use-per-dwg or bulk cleaning both the dwg and the dyn and planning on our long term binding is likely the best solution. Hopefully the release with 2022 will resolve some of this.

1 Like

I do hope with you that the 2022 version will resolve the issues.

There might be some confusion so to make clear: I am not against binding as a mechanism. Session based binding is great. Geometry that updates while you are finetuning the graph is perfect. I wrote hundreds of nodes in C# and they all are hooked up to the binding mechanism. The issue here is the forced persistancy and especially the binding data saving in the graph. As a user I want the option to lose the connection when I’m done finetuning. And I am not convinced the binding data should belong to the graph, unless the graph is inseparable connected to one drawing.

So, if the develop team decide that the binding belongs to the graph, make it optional at least. I am not alone in this. Just do a search on ‘element binding’, ‘disappear’, and so on. Just reread this topic and you see others struggle with this too. Just a few other topics about this:

1 Like

A node can be programmed to hook up with the binding mechanism but it does not have to. Maybe the node you use to create Feature Lines behave like that: fire and forget.