Script Delay

Replies to This Discussion

Permalink Reply by Benjamin Golder on December 10, 2009 at 2:00pm

maybe try having the output of VB step 1 alternate between true and false? Have it switch to False for as much of the loop as is possible, and to only switch to True for a single step, before switching back to False?
just guesses . . .

Permalink Reply by Suryansh Chandra on December 10, 2009 at 4:05pm

Im not sure I completely follow what you mean... But since its a runtime compilation, I think the slider (when animating) will not step to the next value until GH is done solving the definition completely from the previous run...?

Permalink Reply by David Rutten on December 10, 2009 at 4:43pm

What will happen is this:

[boring]

1) Windows detects a mouse move and informs Grasshopper about it.
2) If Grasshopper is idle, the event is processed immediately, otherwise it will be queued and processed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.

[end boring]

Pretty involved for a small 3-component setup, but there you have it.

To answer somewhat more directly your questions:

- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.

--
The Man from Scene 24

Permalink Reply by kermin chok on December 10, 2009 at 8:23pm

Ok. I have to think about this. What has happened so far is that when I move the slider manually (no animation), VB step 2 gets called in sequence. This is good.

However, when I use the animation to loop over a few inputs, VB step 2 sometimes gets called before step 1 is done. This may be due to the fact that VB step is executing an external program and VB step 2 is accessing the results of that external program. The problem happens when VB step 2 tries to access the results before step 1 is done. Maybe VB step 1 returns a completion before the external program is done executing.

In other words, I might need a way to let the external program "catch up" with GH.
I probably need to track the progress of that external program somehow.

Permalink Reply by David Rutten on December 11, 2009 at 2:31am

Hi Kermin,

that could be the problem. If you execute the other application in a different thread (are you?), that part of the solution will be processed in parallel, and then you will run into synchronisation issues.

Adding a delay to fix these is a pretty lame approach, since it doesn't guarantee you will actually solve the problem, but it does guarantee your solution will take longer to complete.

What you should do is make sure that the other application has finished before you exit your custom script in [VB Step 1]. Is there a way for you to tell when the external application is finished? How are you poking it / communicating with it?

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by kermin chok on December 11, 2009 at 11:05am

David,
I have little idea about threading. What I am doing is just an external program (say RunAnalysis) and it does its thing. I need to see if I can figure out how to track the progress of the external program. This might be a question for the API team of the external program.

Thanks.

Kermin

Permalink Reply by David Rutten on December 11, 2009 at 11:16am

Hi Kermin,

the threading will be done for you by Windows if you start that program via certain methods. If however you are tapping into that remote SDK directly, there probably are no threads involved.

Can you paste a few lines of code here that show how you communicate with the remote exe from within your Grasshopper script?

--
David Rutten
david@mcneel.com
Poprad, Slovakia

ps. did we look at a similar/the same thing at the Acadia workshop? If so, then I doubt threading is involved.