Node to stop / quit running dynamo graph

[dominikleuchter]

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.

Hope I explained it understandable.

[Jonathan.Olesen]

Have a look at using the OOTB “ScopeIf” node

You could be inspired by this post if you’d like:

Using ScopeIf to reduce calculation time by pulling results from previous runs (if already calculated)

Hi all Sparked by @Michael_Kirschner2 comment on this issue: I have a workflow that calculated the weight of a structure using Robot, this happens inside a custom node powered by a randomly created number of parameters. As I’m using a genetic algorithm I’m bound to end up having calculation that are dublicates of already completed calculation. But as Michael mentions then “ScopeIf” could mean that I can pull the information from a .csv file and not execute that calculation. (A calculation …

[Avz]

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…

[JacobSmall]

Dynamo doesn’t (necessarily) execute serially, making flow control largely impossible.

I’d temper that by stating “without some effort wiring some degree of planning input control to each branch of the graph.”

I think the ScopeIf is perhaps an exception and intended only for custom nodes?

This node definitely works better with custom nodes than in most graphs.

there’s no other way to stop execution in its tracks

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.

[M.Perez]

I just made a promising test based on @Jonathan.Olesen idea.

[mellouze]

Wow, didn’t even knew that node existed…
This may save me some valuable time on calculations ! Thanks @Jonathan.Olesen !

[dominikleuchter]

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.

Thy for the quick answers, btw.

[mellouze]

And what´s that with this ScopeIf node? How does it work and how is it supposed to help me with my problem?

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.

[Jonathan.Olesen]

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.

[M.Perez]

It also happened to me that the List.Create node gives me an error, but it is probably because your are preventing this branch to execute.

It is exactly like @mellouze descrieved.

If you change the boolean, it will resolve properly

[JacobSmall]

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.

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.

[dominikleuchter]

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.

[mellouze]

Hi there

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)

Did you make sure that the boolean you passed was independant of the two inputs (and that the two inputs were independant as well) ?