(If not, please check if the script is running in Automatic mode.)
Case 2: I edit the script and change the run mode from automatic to manual and run the script from the Player again. Now it does not remove any of the previous placed texts!
When I run the script directly from Dynamo it works fine, both in Manual and in Automatic mode.
Two issues here:
The player does not cleanup every previous generated geometry in automatic mode and differs from running directly in Dynamo,
The player does not cleanup at all in manual mode.
It’s not the binding that is the discussion here, it is the player. I would like (and expect) that the player gives the same result as running from Dynamo.
Actually it is. Bindings do not occur until you save the graph and close it. There is no way to circumvent binding in player for civil 3D, as such each run will remove previously created elements.
Try the in-Dynamo test again but close Dynamo between runs. This will show the binding behavior persisting even in a Dynamo environment.
The behavior of the player is the discussion here. As you read in my first post the player has different result if a graph was set to run manually or automatically, and there is a difference between the result of the player and running from Dynamo directly.
Yes, and I am pointing out that the first issue is 100% related to how bindings are being mismanaged by Dynamo for Civil 3D in ANY environment (headless via Player or in the D4C3D environment).
To illustrate that this is bindings I put this example together - the same would happen with automatic run but that’s more difficult to show as I’d have to edit the graph in textural form first (which while doable isn’t necessarily intended use).
Thanks Jacob for the clear example. I can reproduce it. This behavior makes the whole situation even more unpredictable and unreliable.
If I run the graph from Dynamo, and it is set to run automatically, Dynamo removes every generated geometry first before recreating the new geometry, also when I close Civil 3D and save the drawing in between. So the persistent binding works as designed (that non-optional persistent binding is an undesirable solution is another discussion but it works as expected).
If I change the run mode to manual, save the graph, close and restart Civil 3D and rerun the graph from Dynamo in the saved drawing, then Dynamo only removes as many of the previously generated geometry as it will recreate. So in my example, it now leaves ten texts to the rightmost line, where it removed them in automatically mode. But! While in a session Dynamo will cleanup all the generated entities, even if you recreate less new entities in a new run!
Running the manually graph from Dynamo has the same behavior as running the automatically graph in the player!
With the player you can’t mimic the behavior of Dynamo in combination with the automatic graph and with Dynamo you can’t reproduce the behavior of the player with a manual graph.
I really don’t know how I can still enthusiastically advice my customers to use Dynamo in their workflow
Me: “Dynamo could have been a great solution to do anything you ever wanted. But be aware of persistent binding so you can’t use the graph more then one time in a drawing. Oh, and don’t ever set the run mode to manual if you want to rerun the graph later! And please, never use the player! Really. By the way, if your IT manager complains about fuzz maps and cache files everywhere on the server, it comes from Dynamo. Don’t worry.”
We are looking at improvements and more user control over how the bindings are handled. Placing binding data in the dwg is a requirement for a lot of people and supports shared workflows. We are hoping to support full control of how the data is stored allowing for the flexibility to handle all the issues reported
This entire thread points out the absolute need to be able to control Binding within the graph itself.
It’s definitely a problem if the behavior is inconsistent between run methods, but there cannot be an absolute preference.
There are some graphs where you need persistent Binding, and others where you cannot have it.
I ran into almost the identical issue when I was making a graph to lay out theater seating.
I needed the graph to NOT have binding if I was laying out unique rows, but I also wanted binding ON if I was experimenting with different options for a single row.
Also, if binding is persistent, it can make debugging really hard. Again, there are times you want binding, and other times when it gets in the way
Here’s a temporary workaround that I’ve found that seems to have consistent results. I’ve only tested this on scripts that have inputs. Also note that this seems to only work in conjunction with deleting the DWG trace data dictionary at the end of the script as described here.
After running the script, go back to the main Dynamo Player screen and click “Refresh”. Then go back to the script and it should create new objects on the next run.
I’m not sure if that is the solution of the difference between player and application. The player already removes previously added geometry but not as much as the application.
A few weeks ago I had a meeting with the product owner of Dynamo for Civil 3D and we spoke about the trace data, or binding. I have a little hope every issue with object binding will be solved in a future release. Then this issue is probably solved too.
"