Dynamo strange behavior in complex graph (Gives null value)


Hi all,

I’m working on a complex graphs with number of heavy custom nodes. What I’ve noticed that dynamo behave differently each time. I was trying to track what the problem is, and realized that some time the flatten nodes gives a null value even though the input is valid.

Here an example of the weird behavior, see how the data-shape node gives null although it shows a list in the watch node. Any idea why dynamo behave like this?

Any advice and suggestions will be highly appreciated

Thank you


Here’s another example of the weird null output. Notice how the first graph (the one i’m working on) shows a list of elements, but after couple of nodes it shows “no item exist”. However, when I copy these couple of nodes into a new file, it run smoothly.


Could you maybe explain WHAT the graphs are trying to do? Are you placing families? Getting geometry? Why is the graph so complex? Some of this additional info might help those that can help you.

Any possibility of posting the whole DYN?


So basically the whole graph is detecting intersected element and run couple of solutions to solve the clashes ( custom nodes to move, rotate and route the MEP system when intersects with beam or other MEP elements). The part showing in the pictures above tries to find the two intersected and sort it in a way that it will look for a beam, and then output the beam as output[0] and the MEP element as output[1]. This process will check first for beam, if not it will search for duct, then a pipe.

Here’s a graph of the whole sorting of element:

I can post the whole graph but i think it will be hard to read the nods since it’s large and complected. My only problem is why dynamo behave like this? When I copy and paste some the nodes into a new file it runs perfectly! Is it a bug in my original file or it’s corrupted in some way?


Paste the whole graph by using the camera export feature. Zoom so you can read one of the nodes and then use it to export the entire workspace as an image.

In the second ‘example’ the value is failing much earlier in the graph than you identified, actually back at the pass through node. You may need to post not only your dyn as an image but also the dyn itself, and perhaps the troublesome rvt for us to be able to fix this.

Note that if you’re resolving these clashes automatically, then on a subsequent run they may not actually clash anymore, causing nodes which updated due to revised input to trigger revisions but not the prior nodes with no revised inputs.


Question:. Does. It behave differently every time you run it the first time or on subsequential runs?

I have had the experience mutiple times with a variety of nodes including the Excel export nodes that the memory of the previous input is still stored and run on a second run, however the problem is that this behaviour is inconsistent between nodes and it is hard to tell which nodes are being fully refreshed on a second run and which ones are not. … For those who want to say you can have the orange run preview of which nodes are recalculated … I know, but what I am talking about is a regular issue that seems like a general bug that many people have reported.

Not sure this helps, but may provide some context to your issue.


Also, I just remembered there is a know issue that if the first item in you list is a full some nodes won’t process the full list. See github., I think it got resolved in one of the later versions, but I can’t confirm that right now.