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 ).
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.
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:
It’s easy enough to clean manually (you can automate it via DYN or write a view extension).
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).
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.
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:
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.
UPDATE: For those that have come across this post, there are now some nodes to adjust the binding settings. See link below, the post talks about more than just bindings, so make sure to read the full post.
This was a gret life saver @Anton_Huizinga, made my evening after trouble shooting with element bining in C3D 2021… We have an old project that they don’t want to move to 2023 and then we where stuck with the binding issue…
).