As mentioned in a recent post, I’m currently working on a project using Dynamo Studio. It’s fun getting back into Dynamo and DesignScript: I helped prototype the initial implementation of DesignScript inside AutoCAD about a decade ago, and I love seeing how the technology has evolved in the meantime.
There are a few of us from Autodesk Research working on the project, which is also fun, but in a less literal way. Dynamo doesn’t work especially well with source control, as far as I can tell, so there’s a fair amount of manual merging of nodes into the master graph. One way to mitigate this – and to simplify the overall graph – is to use custom nodes. These are sub-graphs with inputs and outputs that can encapsulate repeated operations, hiding complexity.
To give you an idea of what we’re talking about, here’s a quick view of the overall graph we’re working on:
There are some limitations when working with custom nodes, however. So far I’ve found that it’s not straightforward to debug problems with custom nodes, so it’s probably best not to use heaps of custom nodes until the logic problems have mostly been ironed out. For instance, I’m going through a highly complex graph and creating custom nodes for patterns of graphs that show up multiple times – with the intention of reducing maintenance effort – but so far I haven’t created custom nodes just to make the overall graph simpler: groups of nodes is mostly good enough for that.
Creating a custom node for a sub-graph in Dynamo Studio is very simple: you select the nodes you want to pull out, right-click the workspace and select “Create Custom Node”. Once you’ve entered a few fields of metadata – name, description and category – the new node definition will be opened in a new document tab and an instance wired into the main graph.
If all is well the graph should execute in exactly the same way as before. I was hitting a gnarly issue, though: it would work initially, right after creating the new custom node, but in a new instance of Dynamo Studio the saved and reopened graph would fail. The outputs from the custom node would either be null or a list of nulls. As soon as I edited the custom node – even doing something simple, like changing the type annotations for one of the input parameters from var to int (or vice-versa) – the graph would suddenly start to execute properly. Until I saved and reopened, of course.
After a few days of struggling with this, Colin McCrone kindly pointed out the likely problem: he suggested the custom node might contain some DesignScript code that calls a globally defined function. On closer inspection I found he was exactly right: there was a “ListToPairs” function defined in a global code block. Once I extracted this into its own custom node – and then changed the outer custom node to call this – everything worked perfectly. If you find a newly extracted custom node is returning null and causing your graph to fail, be sure to check whether you’re hitting the same problem!
