You would never do it with a timer, we are not measuring any constant interval across time for this, we are measuring an input change unrelated to time. You can use the import time with time.sleep(1). A pause is not a “timer”. It is a pause, and we only need it one time when an input is changed, we do not need intervals of it. Please show me how you would do that with a timer component and not code.
Also to track that change to output I believe some output may need to be out of the solve instance.
Btw, wouldn’t time.sleep(1) lock the python engine for 1 sec? You may need this 1 second for the other calculations happening meanwhile.
That’s why the output needs to be out of the solve instance so you can still output the change while it’s paused and so you can output before the script is finished. When the pause is finished the output will switch back.
Man, Grasshopper really doesn’t like code generated timers. It locks everything for the duration of the timer. It doesn’t even pass the outputs properly. It doesn’t matter if it is Time.Sleep() or counting with Time.Time().
btw @Michael_Pryor, my original idea with the timer was: if you modify the toggler function such that it will count up. Remove the time_trigger and hook up the timer-component.
Set it to 1 millisecond and while the value of the toggler is less than 1000 it will change the value of a
I believe (not tested it) that at least this way you will actually get the toggled value of a during the counting. Unfortunately you can’t be sure that 1 grasshopper second is equal to 1 real life second. As a matter of fact most certainly it will not be true.
It’s not a really direct solution, it should be like how anemones trigger works, keeping time seems a bit excessive for this problem. I’ll script something when I get a chance but it won’t be in python.
Thank you @Michael_Pryor and @ivelin.peychev for the discussion. Michael perfectly described the issue that I have. This script doesn’t really do the trick. In the recorded data each time I change the input x there should be both True and False values consecutively coming out from ‘a’ with a slight lag. As you can see we are getting only one value now.
The trick works but GH has a problem when launching other apps (in this case the python interpreter). GH locks, waiting for the interpreter to finish all its tasks (in this case the waiting). This is a known issue (at least I consider it an issue). I think GH and Rhino and the Python Engine should all run on separate processes transmitting data between them. Currently everything runs in a single process. So in order for plugins to transfer data between each other, they have to lock themselves.
check the second script I have added. adjust the script for 20 milliseconds or so. Then you will see it True and false.
There’s one more solution but then you will need additional component. It cannot happen with just one component. Unless that component is compiled and written in c# I guess. To run natively inside grasshopper. And one more solution is if you implement the updating (expiring) mechanism from inside the python component by running it in SDK mode.
You could simplify things by also scripting the GHPython component to update itself (i.e. instead of using a timer and plugins). This function should do it:
import Grasshopper as gh
def updateComponent(interval):
""" Updates this component, similar to using a grasshopper timer """
# Define callback action
def callBack(e):
ghenv.Component.ExpireSolution(False)
# Get grasshopper document
ghDoc = ghenv.Component.OnPingDocument()
# Schedule this component to expire at interval
ghDoc.ScheduleSolution(interval,gh.Kernel.GH_Document.GH_ScheduleDelegate(callBack))