How to ensure GH script running 24/7?

Grasshopper
1

Hi all.

I have 5 Rhino instances , each with a .gh script running.

2025-09-24 15_44_21-Window
2025-09-24 15_44_21-Window339Ă—182 31 KB

  private void RunScript(string search, bool ON, ref object matches)
  {
    this.Component.Message = "searcher V01";
    if(ON){
      string scriptpath = this.GrasshopperDocument.FilePath;
      string parent = Directory.GetParent(scriptpath).Parent.FullName;
      string JOBSfolder = Path.Combine(parent, "JOBS");

      matches = Directory.GetFiles(JOBSfolder, search, SearchOption.AllDirectories);
    }
  }

.. a c# script component simply searching for files from local drive. A simple task…
It is working. Hours and days.
I need this to be on 24/7/365 …

Today it happened it simply just stopped “refreshing”!
The Trigger component just wasn’t triggering the c# script.

I cannot replicate this.
Ideas of what is going on?
How to prevent so?
There are means to use some sort of handler to address this problem from an external .exe to check if the script is not refreshing and eventually re-triggering it?

Any insight is useful, thanks.

2

Sounds like by leaving your process running a long time you are eventually hitting a counter limitation, a memory leak or some such in the grasshopper environment. One solution would be to stop that happening by restarting the Rhino app/Grasshopper script at a shorter interval, perhaps from a powershell or power automate script.

3

Sometime it works fine for days, but this time it stuck after a couple of hours from a machine reboot.

Of what? The c# components itself? The Trigger component?

@Gijs @dale … sorry for tagging you in. Any ideas?

4

I have no idea why that might stall. Do you really need this to run inside Rhino/GH, what’s the end goal?

5

No that’s different. If it sometimes runs for days but also fails after just a couple of hours, the cause lies elsewhere.

6

why don t you use

:red_question_mark:

7

This!

I would approach it differently. You create a Windows Service in the language of your choice and observe a folder using a FileSystemWatcher. Once the service notes a change on the folder, you trigger a Rhino batch job.
An alternative is creating a Cron-Job. An OS scheduled execution of a script which reads a folder and starts Rhino as a batch job.

But I would always start and close Rhino for a couple of reasons. Memory, CPU consumption, stability etc….

8

I would agree… if I didn’t experience this:

The trigger is connected to the c# script.
When it happened that the Trigger wasn’t expiring the c# component, I connected another component to the trigger, and that one too wasn’t expiring at all!
I had to pause and restart the trigger…

9

I have the 5 .gh script processing dozens of files in the span of few minutes, the output is sent to a webapp and the result ideally is expected “realtime” or “with as little as possible delay”.
Restarting Rhino is not an option.
It worked fine for days. No memory leak or else.

10

Okay, maybe you open more than one Rhino process in delay and determine which one is ready to use. You could then close and start them without a downtime. But this becomes complicated. At least this is scalable.

11

Yeah, incredibly more complicated.
Also, I have already 5 different scripts running… opening more instance of each will become unmanageable… and it’s even worse in W11 where the UI was simply left to its demise: see here
(I already tried to minimize the amount of scripts …)

12

I’m not sure what you mean.

2025-09-25 08_59_03-Window
2025-09-25 08_59_03-Window1050Ă—370 67 KB

There are about 35 c# scripts … many with some hundreds rows of code.
Where I could run this?
Doing this completely in a .exe app using Rhinocommon would become a task too big for me, the same as trying to achieve the same result by using only standard GH components.
Hybrid visual-programming-language and typed scripts is the best solution for me.
Management and maintenance is possible “live”.

I just need to be sure to the script to fully run whenever new files appear in a set of folders.

13

Is there no option to run Rhino headless using the GH Player?

Maybe even using (Windows) Docker containers if you can execute the script headless with the GH Player. You can then instantiate as many containers even on multiple machines. Then you can create a Kubernetes cluster and you don’t have to deal with detecting which script is online.

In any case this use-case is probably hitting uncharted terrain on multiple levels. I don’t think McNeel is even testing this.

14

As far as I’ve used GH Player in pasyt… I wouldn’t use it for such complex things…
… also, my scripts need to take screenshots from the Rhino viewport, “encapsulating” my .gh in some way might prevent me doing the screenshots. … likely…

I’m thinking maybe of a way to call a IGHComponent.ExpireSolution() of a Rhino+GH instance from outside Rhino, from a .exe … is this possible?

15

I was only commenting on if the file watching needed to be done from within GH

16

The file watching can be done by whatever mean … but then the processing of such file must be done by a Rhino+GH instance.

17

The way approached similar problems is to create a “middleware” running in Rhino. So essentially a plugin which is just there to delegate certain commands. The heavy part is then in a entirely different application. A tiny TCP server basically.

18

I may not fully understand the ask here, but isn’t this use case basically the business model for the ShapeDiver software? Realtime cloud / web based instances of Rhino / GH scripts?

19

I have never tried shapediver.
But I have some reasons Shapediver is not suitable in this project:

  • my customer prefer of not having any third party accessing the algorithms i’m developing.
    (and this alone is enough… )
  • I’m doing most of the compute-intensive parts inside c#scripts (Rhino 7) with frequent code change. I’m not sure how that would impact the readiness (as shapediver “manually” verify each scripted component) Currently I can change the code and push it ready for execution from the webapp in less than a minute.
  • the execution needs to be quick, realtime. Buying a dedicated machine with a monster CPU and giving it a dedicated fiber connection is inexpensive compared to the final appreciable performance. What are the actual true specifications of the CPU running in Shapediver cloud?
  • Lastly the machine executing the .gh scripts is the same machine doing some .php task with the local webserver, to shrink the transfer and computation time…
20

Depending on what you’re reading, one can also set up a dynamic file reader using the native File Read component. Just in case you missed this option: