Trigger Block Unstoppable Loop

[themarcosutra]

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?

[Joseph_Oster]

“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.

[themarcosutra]

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.

[Joseph_Oster]

@themarcosutra

Data Dams are similar but I’m using triggers as I find them cleaner to work with.

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

@themarcosutra

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.

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

[themarcosutra]

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.

[Joseph_Oster]

@themarcosutra

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?

Data dam toggle/trigger

Yes, it would be nice to have a ‘trigger’ input for Data Dam. But I don’t agree that either of the proposals in the thread you refer to are a solution. The one in testDataDam.gh using VB Script appears to trigger all data dams? The one using Metahopper appears to be more selective using its “Get objects in group” feature but it’s a little obscure. The connection is only “explicit” in the sense that Data Dam and ObjFromGroup (and only those two components?) must be in the same group, a condit…

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.

Going large: advice/resources for optimising

Hi @jeremy5, There is one thing you need to take note when using data dams. Even if they are set to Never they are calculated when you open (re-open) a gh definition. This leads to a long wait (depending on the definition). Along with data dams I use a python script with a Togglethat my wire goes through before entering the data dam. This script sets the output of my ghpython, respectively the input of the datadam to Null. I turn this off when saving the gh file. I use this wherever I have a…

[themarcosutra]

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.