Trigger Block Unstoppable Loop

Either I don’t know how to stop this or this is an overlooked error in the programming of GH:

I use trigger blocks to make the project more managable and always have them set to a manual mode so the solver can do it’s work when I decide. However, on this occasion I accidentally pressed it where it changes mode to scheduled mode, with the default set to 1 second…

This part of the project it takes more than 1 second for the solver to calculate (~15s) during which I cannot use the GH (or rhino) interface. And due to the scheduled trigger the solver retriggers to recompute that part every second (in this case, as soon as it’s finished).

So by accident I have ended up in an endless loop where I cannot turn off the trigger as it is being triggered immediately after solving. All I see is the note at the bottom of the window saying how long it took the solver to calculate which keeps updating confirming that GH is in an endless loop.

Does anyone know how to exit this loop?

“trigger blocks”? You mean Data Dam(s)?

Close Rhino, re-open Rhino and open Grasshopper, disable the solver and then re-open your GH file, disable the.Data Dam and then re-enable the solver.

Data Dams are similar but I’m using triggers as I find them cleaner to work with.
Yes, I gathered closing and reopening rhino with solver disabled would do the trick but is far from ideal, but thanks for replying. To be honest, I was assuming this is an overlooked glitch and was hoping this post would draw attention to it so the devs can fix it in next update.

Is that an R7 feature? I’ve never heard of “trigger blocks”.

Don’t count on it. What fix would you suggest?

Yes, R7.

Basically they serve the same function as data dams but in attaching them to the functions you don’t have to reorganise the data.
A fix would be to limit the solver to when inputs have changed. The timer on the trigger seems to trigger the solver regardless of whether the input data has changed. Quite a simple fix since that is how the GH normally works so it would be disheartening if the devs ignore it.

Good suggestion. But consider that the same flaw has existed for years in Data Dam (right?) without being fixed.

Do Trigger blocks also share the same ‘leak-at-starup’ defect as Data Dam, where the downstream code is executed once when the file is opened, regardless of the ‘Never’ (manual trigger only) setting?

And there is serious flaw with Data Dams, mentioned a few days ago by @ivelin.peychev in another thread: they leak and pass data once when a GH file is opened! Very bad. :man_facepalming:

To be safe from crashing I always startup with the solver locked as I used to use data dams and had noticed the “leakage”. Even when you press recompute, I noticed they leaked there too so I would (annoyingly) lock solver, “open” the dams, then unlock solver.

I just tested triggers now to see if they leak without the solver pre-locked and the triggers did not leak data. I also tested to see if they leak when pressing Recompute and they held strong still. Setting the trigger to “lock target object” just switches off the “enabled” switch so I am assuming it is that specific aspect that stops the flow of data on startup and on recompute. I think data dams are treated like other functions so they end up getting activated when GH activates everything else.