I´m looking for a node/python script, that stops the complete running graph, if it gets a TRUE value.
After creating bigger and more complexe dynamo graphs lately, I started creating in-dynamo error testing measures to prevent running with mistakes like wrong/null inputs or python scripts giving traceback.
Currently I´m using Passthrough nodes to stop the TRUE value for RunIt inputs of nodes by the event of error, but that´s not a good solution, as a lot of nodes don´t have a RunIt function.
So even if the error is detected and the Passthrough closes, there are still a lot of nodes working and paths completing until the graph finally stops.
This is a big waste of time, as a run with an error takes as long as the error-free run but has not the wanted results.
My goal is, to have a node, that instantly stops the whole dynamo graph (every node+function, even if they are not in the same path) as soon as it gets the TRUE value.
From what I understand, Dynamo doesn’t (necessarily) execute serially, making flow control largely impossible. I think the ScopeIf is perhaps an exception and intended only for custom nodes?
The only other effective means of flow control is Imperative blocks in CBNs because they force linear execution, though only within the block itself.
I believe the developers are looking at other flow control possibilities but as yet there’s no other way to stop execution in its tracks…
I’d temper that by stating “without some effort wiring some degree of planning input control to each branch of the graph.”
This node definitely works better with custom nodes than in most graphs.
This is only partially true…
A custom node with content grouped inside of it will not process much of anything if you properly wire a Boolean to control the run state. Most libraries are chalk full of this type of control.
Just to set this clear, apparently there is no easy way, like e.g.
"create a Python script node and type ‘dynamo.quitrun’ blablabla (or something like that) "
to stop the whole run instantly. Correct me if I`m wrong.
So what would be a good solution to stop the graph from running the remaining nodes? (After error detection)
As far as I know Boolean Switches, if, passthroughs, etc. are not stoping the connected paths. They are just sending null data, which still makes the following nodes start operating.
And what´s that with this ScopeIf node? How does it work and how is it supposed to help me with my problem?
I tried to rebuild the test from @M.Perez , but i got a cyclic dependencies error on my nodes.
From what I got, the ScopeIf node will execute first, evaluate the boolean, and then compute all the nodes that are connected to the corresponding value. Then the result will be stocked in the result* output of the ScopeIf node. That is why, in @M.Perez graph, the watch node is outputing null.
That is correct @mellouze, to my knowledge that is by far your best bet, next to converting everything into a python/c#/designscript node and suppress stuff in there.
Correct, but sending null or an empty list to most nodes instantly returns null or an empty list… if your graph doesn’t execute in an instant with all null inputs across the board than it would likely never finish with a reasonably sized dataset.
So … I did some testing with the ScopeIf node, but sadly it didn’t work for me, as needed.
I tried several things like placing it directly in my graph, putting it within a custom node and even node within node, but I always got the same two results:
Either It made my complete graph go null from the beginning, so the error detection already got null inputs and making the whole graph useless.(doesn’t make any sense at all)
Or the ScopeIf didn’t effect the other nodes within the graph. (No matter if true or false input reached the scopeif)
Maybe I´m not using it correctly. … Dunno
So, to solve my problem, I decided to go for the flow control by a combination of Codeblocks and IF (Passthrough) nodes.
Suppressing the entire data stream through passthrough gates, directly after the error checks, made the graph stop within a few seconds, by the event of error.
At last I have to say, … let’s see, maybe in the future there are better ways to control the flow of a graph or even stop it mid run.
