I may be beating a dead horse here but I’ve been looking into a way to, essentially, toggle a data dam on/off. I want to be able to change input data on a component without changing the existing output data until it is toggled. Once toggled, the new data is output once and remembered until the component is toggled again… so on a so forth. This means no resending the same existing data when the input is changed, no sending nulls, no nothing that would trigger a re-computation of the script down the stream.
This does not work with data streams, cull patterns, record, or anything else in native grasshopper. Data dam works perfectly except you have to press the component so this doesn’t work well on larger scripts (time consuming), doesn’t work in the grasshopper remote panel, or in HumanUI. I’m very interested in using this for all three of these situations. The other thing is that data dam remembers saved information when you re-open the file, I don’t not care about that function much.
This thread mentions data dams having some memory issue:
This thread mentions using metahopper in combination with data dam but in my testing it is very glitchly and unreliable:
I’ve looked through many threads and done some testing of my own to find a solution. I’ve tested tricks with metahopper, C#, and native grasshopper and only one method works… kinda.
Native grasshopper: (failure) Using a cull pattern/stream etc, sends out nulls/repeated data which cause a recalculation
Metahopper: (failure) Works but will randomly seem to reset and release a new set of data, causing a recalculation, you can see in the screen shot how the panel has a red time on it because it keeps receiving data, scary as it can quickly escalate to huge amounts. The screenshot shows one way to connect objects in methopper, the other way doesn’t require the wires to be connected but the issues remain the same
C# (method 2): (semi-success) This is the only one that I think works but it is a pain to setup for multiple inputs and it seems a bit hacky as it seems to allow loops/break grasshopper logic. For this one to work you need to connect the top Data component into the ID which will (no idea why) not keep the wire. Then the C# component will update the Data with received data once triggered. C# also unreferences the geometry (not super important).
I thank anyone for any help/advice on the matter. If any McNeel empolyee see this, having this function directly in grasshopper would be EXTREMELY useful and I can see from the many threads around the community that I am not the only one with this desire.
In the last post you reference, you’ll see that i found the solution using scripts.
If you don’t want to script it yourself, I made a plugin that includes this function
look for melanoplus in package manager
in the plugin, use the component Idempotent Components · lin-ycv/Melanoplus Wiki (github.com)
It looks like one just needs to expire a data dam to pass data through it (i.e. simply recomputing a definition will also work). Here’s a quick GhPython script that appears to work as expected. I usually target specific components on canvas via their NickName when using this coding pattern (i.e. iterating all components on canvas by type, followed by nick name). But it doesn’t seem possible to edit this directly on data dams, so here I’m targeting by names of the first input parameter instead:
Hi Anders, this solution works perfectly. Simple to implement, no plugins, works great. Thank you.
I do have one more question though, maybe you could help me with it. When you start a grasshopper script, data dams instantly pass through whatever data is connected to them. This isn’t ideal as I would rather have it run when I press the button that you setup above. I’m wondering if there’s a way to instantly disable the data dams at the beginning of the script, and then enable them only once I press the button.
Hmm, I never actually noticed that. I wonder if that’s the intended behaviour, feels like a bug,
Here’s a quick hacky workaround, where we lock/disable the targeted data dams on the first canvas run, and then unlock/enable them again when the transfer button is pushed. This requires that the GhPython must compute first, which is solved here by sending it the back with Ctrl + B (see this great article):
Edit: Unlocking the dams appear to raise an expiration error when you first run the script. You can choose to ignore those warning and it should work as expected, but obviously we should code that out. I’ll have a look when I get a moment.
I don’t like how these functions operate on globals variables (not sure if the scheduling callback function can take input parameters), but this appears to work without raising any errors and such:
