Emergency Stop for solution calculation

Say you have a solution set up and you forget to dis-able a few components before you change one of the parameters. once changed, the solution would be ridiculously huge as a calculation if the components were not disabled . . . this happens & it tries to calculate & you wish you could hit a button or escape or something to say "stop that calculation" so it does not go into a lock-up for your session of Rhino/GH.

Is there anything like that?

Just FYI for more specifics, I have a gear maker set up that calculates the tooth profile using an involute form & then it creates a 3d gear based on input parameters. Well, I set it up & test with like a 20 tooth gear, 1" Dia. It mates with a section of a curved gear with 2,708 teeth, but I mean to turn off the final section of the solution where it creates solids from the forms & I keep forgetting & it tries to solve the whole thing & I basically have to shut it down from Win.Task Mgr. & lose unsaved Rhino info.

Any thoughts, or plans to add a "StopThatCalculation!" Button?

Replies to This Discussion

Permalink Reply by Nik Willmore on May 10, 2015 at 10:11pm

If Data Dam would actually *work* as a dam, it would be fine, but the following example still runs the main program beyond it each time things *behind* the dam are updated. It runs with the old data (and the preview in Rhino blinks to indicate a new solution) unless I push its button to grab the new data:

I don't want to hold old data and have it run again downstream. I want to STOP the damn thing from running again until I tell it to. It's what every Grasshopper user wants to be able to do, the very most basic 101 control over behavior.

Can a Python script fool Grasshopper down the line into not *seeing* a Pipeline update until I push a "Go!" button connected to my Python script? Or will Grasshopper narc on the Pipeline update to the downstream program? I'll have to try to find out, lacking any manual.

I can get around losing my latest Grasshopper preview upon disabling the solver, by just baking a preview to a spare layer, but this is all just terribly confusing and disabling is a menu item, not a button.

I just want the most basic Pause And Hold button for Grasshopper, akin to my old programmable calculator not running a program until I tell it to, only *after* I have changed several input variables, not run every time I change just one variable!

Permalink Reply by Nik Willmore on May 10, 2015 at 10:34pm

Yup, Grasshopper sneaks right through a Python script too, invoking updates of downstream objects no matter what I do in the script. If it's connected to even a dead output, it still updates when any Python input updates.

Permalink Reply by David Rutten on May 11, 2015 at 1:19am

Yes, it is possible to make a component which does not propagate expiration waves, but that requires Visual Studio, it's not possible though python or C#. The data dam should do this, if it doesn't that's a bug that should be easily fixable. I'll have a look after breakfast.

Permalink Reply by Nik Willmore on May 11, 2015 at 5:00am

This is the first time the phrase "expiration wave" has appeared on this forum, let along any manual. So I'm not crazy, thanks! The "automatic propagation of expiration waves" is the core of why I don't feel in control of Grasshopper from Python, to clarify my original exasperation. I certainly want to control the Data Dam or new component dam from Python via low level Grasshopper commands, then, so I do feel in control finally. It feels like Windows 7 telling me I have no permission to move a file on my home computer, which is why I have to use the Unlocker extension to save me via the right click pop-up menu.

My mental block was not thinking to switch to Solver Disabled mode for one-shot Grasshopper program runs. I even already knew the Recompute was now active anyway in that state. Lack of a manual means it often takes me weeks to just formulate a useful question instead of merely suffer utter confusion.

Python needs God Mode to vastly simplify the ability for entry level programmers to make Grasshopper do tricks. But if I have power to command events, I also need clear and documented ability to wait until any given command I issue has completed so my script doesn't lurch ahead of events. Using timer delays is just too tweaky and will break.

Permalink Reply by David Rutten on May 11, 2015 at 3:32am

So looking into this it turns out the bug is not with the data dam, but with the fact that the data is referenced. Non-referenced data is properly blocked by the dam, but somehow the components on the right side of the dam get expired if they contain referenced geometry as input.

I think that's a bug, though I vaguely remember fine-tuning expiration logic for referenced geometry for one reason or another.

Either it's a bug in which case I can probably fix it, or it is supposed to behave this way in which case I can provide a new component which removes referencing data turning the referenced geometry into static geometry.

Permalink Reply by David Rutten on May 11, 2015 at 4:21am

I changed the expiration logic so that parameters that contain referenced geometry yet have at least one source parameter do not register themselves as expiration targets for those Rhino objects.

This fixes the issue with objects to the right of Data Dams updating with stale data, it shouldn't affect normal solutions as those objects would expire anyway.

It does break cases where referenced data is made from non-referenced input data. I think this only happens in vanilla GH when you plug an object name text into a geometry parameter*. I'm not sure yet I'll be able to detect these cases reliably and take appropriate action.

Edit: I think I managed to fix the bug without breaking anything else. I'll need to do some more testing but hopefully the Grasshopper1 version that ships with the next Rhino WIP will behave correctly when dealing with referenced geometry and data dams.

* Which incidentally was broken for Extrusion objects, I fixed that as well.