Kill Switch - Grasshopper Operations

Is Rhino/Grasshopper working on a potential ‘kill switch’ component or command to activate if an operation/script is taking too long or is unresponsive?

Grasshopper 2 will have UI elements and computation of data being separate tasks, so you will be able, for example, to continue editing and adding components while they are calculating… and so there will be better controls to stop what is currently calculating.

For current Grasshopper there is not much.
Sometime pressing ESC key shortly after a heavy component started computing will manage to kill it, but you shouldn’t rely on that.
If you are learning, consider saving often and killing rhino when it go unresponsive.
Program and test your code with smaller sets of data.

1 Like

This comes up quite frequently, but technically the way the system is designed, it is not possible to reliably abort a computation.

Grasshopper shares the same process and main thread („UI“ Thread) as Rhino. Often the cause is a long computation of Rhino code not GH code. Effectively you can only prevent that if both apps become dedicated and GH uses an own geometrical Rhino kernel instance and offers a different form of interface to Rhino.

As already mentioned, there are already mechanisms build in by e.g. using a „cancelation token“. But this requires that at some point the code can check if a user requested an abortion. Usually you get stuck by mistake, when you force Rhino into a heavy computation with lots of data.

The best chance to prevent GH from being stuck is to learn about the usual suspect components and implement a guard against mistakes. Either by manually checking the tree complexity and structure before connecting them or by perform checks on the data. You should also ensure to always work with clean geometry. Other than that always save your data so that killing Rhino becomes no problem.
There is a lot you can do.