Hi @mparks8G2XN,
This has been a point of confusion for a lot of folks for quite awhile, so let’s take the time to do a deep dive.
Here’s an example. I’m using Civil 3D 2023 with Dynamo Core 2.13. Below is the test graph, about as basic as you can get - create a circle on layer 0 at the model space origin.
(click to expand/collapse)
Case 1: No Binding Data Retained
Disconnecting/reconnecting input ports
If you disconnect and reconnect any of the ports on the Object.ByGeometry node, a brand new circle will be created every time.
Changing input values
Similar to disconnecting/reconnecting a port, a brand new circle will be created every time an input value is changed.
DYN file behavior
No binding data is saved in the .dyn file.
DWG file behavior
No binding data is stored in the DWG file.
Dynamo Player behavior
A new circle will be created every time the graph is run through Dynamo Player.
Summary
Use this setup if you want your Dynamo script to function similar to a LISP command, i.e. “fire and forget”. You can use the .dyn on any drawing in any situation and it will create new objects every time.
Cases 2-4 below will all have the same behavior when disconnecting/reconnecting input ports and changing input values. The differences between them occurs when saving the graph, running the graph on different DWG files, and running the graph through Dynamo Player.
If you disconnect one of the ports on the Object.ByGeometry node, the circle will disappear from Model Space. If you reconnect the port, the circle will reappear. However, it technically isn’t the same circle that is reappearing. When you disconnect the port, the original circle is actually deleted, and then reconnecting the port creates a new circle. It’s a subtle thing, but it’s important to understand because it could have implications if you’ve somehow linked other entities in the drawing to that original circle. Disconnecting/reconnecting the port would break those links.
Changing an input value (e.g. the layer name) doesn’t erase the circle and create a new one on a different layer. Instead, it will update the layer of the original circle, which is what you would expect to happen.
(click to expand/collapse)
Case 2: Store in Graph For Dynamo
DYN file behavior
If we save the graph, you’ll see in the .dyn file that there is a big nasty section for “Bindings”:
If you close/reopen the graph and run it on the same DWG, then everything should work the same as you left it. If you run the graph on a different DWG, then it will obviously create a new circle. However, as soon as you run the graph on the new DWG, the binding data will be removed from the .dyn file. This means that if you go back to the first drawing and run the graph again, a new circle will be created on top of the old one.
One more important thing to note here. Let’s say you save the .dyn and close Dynamo, and then modify the circle somehow, say move it to a new location. When you reopen and run the Dynamo graph, the circle will move back to where it was originally. This is important to understand because it could lead to unexpected results if other users aren’t aware that an object was originally created by Dynamo.
DWG file behavior
No binding data is stored in the DWG file.
Dynamo Player behavior
A new circle will be created every time the graph is run through Dynamo Player.
Summary
Use this setup if you want your Dynamo script to “remember” what stuff it created the last time it ran on a particular DWG. However, be aware that this only works if there is a one-to-one relationship between the DWG and the Dynamo graph. As soon as you start running a graph on multiple DWG files, you’ll lose this capability.
Case 3: Store in Drawing For Dynamo
DYN file behavior
No binding data is saved in the .dyn file.
DWG file behavior
Binding data is stored under-the-hood in what is called the Named Object Dictionary (or NOD). The dictionary is called DYNAMO_TRACE_DATA and looks very similar to that big nasty mess that gets saved in the .dyn file from Case 2. So if you close Dynamo and then reopen and run the same graph, then everything should work just how you left it. But here’s the small difference with this mode versus saving the bindings in the graph: if you run the graph on a different DWG, the binding data is still preserved in the original DWG since it is saved in the drawing and not the graph.
Dynamo Player behavior
A new circle will be created every time the graph is run through Dynamo Player.
Summary
Use this setup if you want to use the same graph across multiple DWG files and have it “remember” what it did in each one.
Case 4: Store in Drawing For Dynamo Player
The first thing to note with this setting is that it really has no effect on how the graph interacts with the DWG when running the graph through the main Dynamo window. This setting only kicks into effect when the graph is run through Dynamo Player.
DYN file behavior
No binding data is saved in the .dyn file.
DWG file behavior
Like mentioned above, running this graph through the main Dynamo window will not result in any binding data being saved in the DWG.
Dynamo Player behavior
If you run the graph through Dynamo and then close out and run the same graph through Dynamo Player, it will create a second circle on top of the one created through Dynamo. However, once Dynamo Player has run through the graph once, it will write binding data under-the-hood in what is called the Named Object Dictionary (or NOD) of the DWG. The dictionary is called DYNAMO_TRACE_DATA and looks very similar to that big nasty mess that gets saved in the .dyn file from Case 2. So if you run the graph multiple times through Dynamo Player, it will update objects instead of creating new ones. If you run the graph through Dynamo Player on a different DWG, the binding data is still preserved in the original DWG since it is saved in the drawing and not the graph.
Summary
Use this setup if you want to use the same graph though Dynamo Player across multiple DWG files and have it “remember” what it did in each one.
Cases 2-4 can be combined, but I’m not going to go through all of the permutations.
Recommendation
Personally, I think there are basically two main scenarios that you might want:
-
You don’t want Dynamo to “remember” anything about what it has done previously and just create new stuff every time in runs, regardless of the DWG it is being used with. If this is true, then Case 1 is the way to go.
-
You want Dynamo to “remember” everything about what it has done previously and use the same graph across multiple DWG files. You also want to be able to run the same graph through the main Dynamo window and/or Dynamo Player and have it keep track of objects in both scenarios. If this is true, then the combination of Cases 3 and 4 should work.