What's New for Dynamo in Civil 3D 2022.1

[mzjensen]

Civil 3D 2022.1 was just released this morning, and there are a few minor updates to Dynamo that flew under the radar. The first one is that Dynamo Core was updated to v2.12, which is a huge update! You can read about all the new features here and here. One of my personal favorites is the ability to add graph properties:

Another favorite is node autocomplete, which can help figure out how to connect nodes together by just double-clicking on a port:

Also, new nodes were added that allow more control over element binding. There is a new “ScriptBinding” shelf under AutoCAD → Document:

There is also a new “ObjectBinding” shelf under AutoCAD → Objects:

Although in my preliminary testing, I haven’t been able to make these work. They seem to pretty much return null every time. Has anyone else been able to make them work?

[Anton_Huizinga]

The new Binding nodes only work when the data is saved in the drawing (Binding Preference). Also there are several issues with these nodes. Some of the nodes only update when the graph is reopened and other things.

In my opinion the implementation of the Binding control nodes is horrible, not tested well and nothing more than useless. The Binding Preferences works better but why oh why can we set the preferences only when Civil 3D runs as administrator…

[mzjensen]

Ah, I see it now. Thanks @Anton_Huizinga!

And you may see this if you try to change the settings:

[mzjensen]

But if you run Civil 3D as administrator, then the options can be set:

[jehart]

Interesting! The AutoComplete is nice.

I wonder if they broke this node? Worked just fine until this update…

[mzjensen]

Interesting…does the output of the node on the left have anything in it that wouldn’t work? Maybe an arc or something?

[jehart]

@mzjensen Nope, nothing out of the ordinary. I am just getting the geometry of a layer in an external reference. I then take the geometry start/end and do what I want with it.

It worked just fine until this update unfortunately. I might have to roll it back.

[jehart]

And there is nothing useful in the log, or I would post it. Just CPython3 which I have since set the default to in preferences

[mzjensen]

What is the item at index 5 from the ‘In’ output of List.FilterByBoolMask?

[jehart]

Hmmmm It is the following…

Object(Handle = B0FB66F)

[mzjensen]

There’s your answer. Whatever those objects are, they aren’t supported by the Object.Geometry node.

[jehart]

Thank you @mzjensen I just grabbed a Proposed Base file and assumed that team had cleaned it up. I tested it on another file and it worked just fine! I was scratching my head on this one for FAR too long! Grrrrr

Thanks again!

[mzjensen]

No problem. Glad that node didn’t change, because it’s a pretty important one!

[Anton_Huizinga]

That it. Dynamo saves a JSON settings file in the Program Files location and needs write access to that location. This way it is not a user setting but an application setting. I wonder why the development team made this choice. Not every user is allowed to run Civil 3D as administrator, and not everybody understands the red message, how to solve it.

[Anton_Huizinga]

Two new nodes to write and read Excel without the need of Microsoft Office:

Keep in mind this node does not add the xlsx extension to the filename so you have to include it.

Also it is great to set a default Run mode and Geometry Scaling in the Preferences:

[Anton_Huizinga]

@mzjensen

Although in my preliminary testing, I haven’t been able to make these work. They seem to pretty much return null every time. Has anyone else been able to make them work?

A short introduction: these nodes only work when the Binding Data Storage is set to Drawing. When this is not, or when the Graph is selected as storage, you don’t have access to the binding object. Also you receive errors:

When the Binding Data Storage is set to Drawing then you need to make changes in the script AND reopen the graph in Dynamo, else the nodes will not show the correct data. When that’s done, you can read the ScriptBindings and ObjectBindings.

The ScriptBinding refers to the binding of one or more graphs to the drawing and each ScriptBinding refers to one or more ObjectBindings, which are actually the results of a geometry creation node. I created a polyline and a bunch of circles, in the image above you see one ScriptBinding with two ObjectBindings which refer to the polyline and the circles.

As said before, the nodes do not show the actual information, but only after reopening the graph. If you change the amount of circles, the ObjectsByBinding only update after closing and opening the graph again, else it will show the previous objects:

If you freeze or delete nodes that creates geometry then the ObjectBindings still show the previous binding data. When you also delete the previously generated geometry from the drawing it returns an empty list item.

You can read the ScriptBinding by object, probably to see if the object is included in a ScriptBinding. It returns the Document ScriptBinding for each object. Don’t use this list because it duplicates and squares the lists of objects and reduces the speed of Dynamo dramatically:

It is better to work with the Document ScriptBindings node.

You can delete the generated objects and the binding. I am not sure why one would delete the objects. Delete the binding is doing something magical because all ObjectBinding lists are empty, but the geometry still act like there is a binding. Deleting objects only work when you add the node to the graph, after reopening the node does nothing.

After a full day of testing I really don’t know what to do with these nodes. Out of the box they don’t work because the Binding Data Storage is not set to Drawing and these nodes only work when that is set. Further the nodes only update when the graph is closed and reopened (I can understand the process but it is not how nodes in Dynamo should work). Maybe somebody else can show a workflow where these nodes are valuable but I really can’t imagine such.

[mzjensen]

Thanks for the thorough summary, Anton!

@Anton_Huizinga

Not every user is allowed to run Civil 3D as administrator, and not everybody understands the red message, how to solve it.

I agree that it isn’t ideal, but at least it’s a first step. There is more flexibility now than there used to be. Even if you do have administrator access, you have to close everything down and reopen for a setting change to take effect, which is little cumbersome. But it was flagged as a known issue by the development team, so that’s a good sign that the process will be refined.

@Anton_Huizinga

Maybe somebody else can show a workflow where these nodes are valuable but I really can’t imagine such.

If you’ve created a graph where the binding setting was set to “No Binding Data Retained” from the start, then these nodes aren’t applicable (as they shouldn’t be). But what about the scenario where you’ve created a graph with binding data retained in the drawing, but you decide that the function of the graph needs to change (maybe it is only to be used in Dynamo Player and not in automatic run mode). Then you need a way to get rid of the binding data, and it seems like these nodes would be the only way to do that.

[mzjensen]

@Anton_Huizinga

Dynamo saves a JSON settings file in the Program Files location and needs write access to that location. This way it is not a user setting but an application setting. I wonder why the development team made this choice.

Perhaps an assumption was made that most of the people that would care about controlling trace data are BIM/CAD managers or other power users, in which case they probably do have administrator access.

[Michael_Kirschner2]

Thank you all for the great feedback in this thread, we have let the dev team know about it.

[Anton_Huizinga]

That might be the assumption but on the other hand, simple users who do not have a clue why objects disappear must be able to set this setting easily, not the hard way.

At least it is a Json file so a CAD Manager can roll this out