Stop running script after a certain amount of time

Share
,
1

Hi,
when I program scripts, it often happens that I create a loop that runs infinitely. The script can not be canceled. The only solution is to completely close Revit. For large Revit projects, restarting Revit and Dynamo consumes a lot of time.
That’s why I’ve built a script that runs only a predetermined working time and then breaks off.

The idea is not new, but I did not find a good solution in this forum.

image
image.png1023×516 30.9 KB 

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

import time
start_time =time.time()

sec = IN[0]

i=0
result=[]

ss=time.time()-start_time
while ss<sec:
	result.append(i)
	i+=1
	#do something
	ss=time.time()-start_time
OUT = ss,result

Any other ideas are welcome:)
Merry Christmas

2

Hi @Fiesta

Did you see this?

3

Hi Kulkul,
i did not see that.
But this is also a nice idea to use the running time, if a node needs to wait for other nodes.

5

This is a really good idea :slight_smile:

If only it’s functionality could be added to other nodes somehow?

I might add OUT = 'Runtime of %s seconds before exit' % int(ss), result

It would be ideal to use it with a data shapes input so that we could be prompted how long we want it to run?

Happy Christmas!

Mark

6

@erfajo
Your are right - the “wait for time” would be not the best method for a lot data, but if you have a realy small script and this script has a normal processing time less than 10sec. I think in this case “wait for time” is a good idea.

But actually I wanted to stop the Skirpt from a certain second, not start. Only for testing the script and i don’t wanted to restart Revit if my script fails.

@Mark.Ackerley
Unfortunately, I do not know how to connect the script to another node.

8

I’ve just seen Erik’s post…

@erfajo Hi Erik, of course you are right in what you say.

Ideally Dynamo would have more built-in catcher’s for this kind of thing, but it’s all manual right now…

But I think it’s useful to have this in the toolbox as an option. Having adaptability is a big reason why I use Dynamo. But I appreciate it doesn’t work for all graphs. I have an autosave in my batch plotting for similar reasons :slight_smile:

Your await and circuit nodes are fantastic, but if you accidentally write something which will take 5 years to run, the nodes will never finish.

Cheers.

Mark

10

We might have to agree to disagree on this :slight_smile:

I would be able to see it still was running and not finishing…
This is incorrect, you can’t know that it is not finishing… You would only know that it was still running… You wouldn’t know if it will finish in an hour, or at the end of the universe…

You could kill the programme, but then maybe you lost all of the computation of the nodes running up to the python?

Maybe something simple in the final python node was wrong and by exiting and quickly fixing that you save your 2 weeks work rather than losing it…

then I would end up with the result in a very unpredictable manner
This is incorrect, the node will tell you that it was stopped by time.

there is no options for any computational aspects should be “time-driven”.
I think this could be phrased better :stuck_out_tongue: Absolutes are unlikely :slight_smile:

As I say, the nice thing about Dynamo is that I can choose to add this and you can choose not to :slight_smile:

Have a good Christmas!

Mark

12

Put me in camp @erfajo on this as I’d exercise some extreme caution here. If your graph usually takes 10 seconds, and it’s taking more than 10x the time, there is a reason which needs to be evaluated. Could be n^2 testing, overly large data set, element binding issue, or complex relationship with other elements in the Revit model, or anything really. Stopping said actions mid-way though will either cause you to have to start the ‘long’ process a second (third, nth) time (saving you nothing). Or worse yet could lead to failed updates on the second run so you’ll think you finished, but because the part which was timing out didn’t re-run you’ll get mis-matched lists and easily process the remainder of the content, missing out of processing a sizable chunk of data.

13

Hey Jacob,

Thanks for the feedback :slight_smile: Who would of thought this would be quite such a contentious issue?! I feel quite the first year student getting grilled by the heads of school :smiley:

The big point here is that there is no Dynamo ‘stop run’ button… If you kill it, you lose everything.

I’m suggesting using this code to avoid killing Dynamo when stuck in an infinite loop or if I accidentally created a graph/code which would take unreasonable amount of time to run.

If your graph usually takes 10 seconds, and it’s taking more than 10x the time,
I don’t think that’s the problem, if it executes in a ‘short’ time I can live with that. It’s if killing Dynamo is quicker that letting it finish.

I would be very interested in tips to make python or graphs more efficient, perhaps we should start a dedicated thread?

Could be n^2 testing, overly large data set, element binding issue, or complex relationship with other elements in the Revit model, or anything really
If this was accidental, then you want it to stop, you’ll get to see how far through it went and you can re-evaluate. If it was what you wanted and it took too long, at least you (have a crude) way of narrowing down which was the slow bit. Maybe initially you set it to 10 seconds, then 100, then 1000… you can see where the bottle necks are, but heck, maybe it does just need 2 weeks, just like Erik’s students. You’d only be running it if it saved you a few months worth of manual work, or was just impossible without Dynamo.

Stopping said actions mid-way though will either cause you to have to start the ‘long’ process a second (third, nth) time (saving you nothing).
As stated above, perhaps the final python had a simple mistake and the entire rest of the graph has executed, now you can see how far that node got, fix it and run to completion. Quite a saving.

Or worse yet could lead to failed updates on the second run so you’ll think you finished, but because the part which was timing out didn’t re-run you’ll get mis-matched lists and easily process the remainder of the content, missing out of processing a sizable chunk of data.
I would suggest integration of a window which pops up to tell you that a node did not run to completion.

If you are forced to kill it, perhaps the bit you thought was broken isn’t and you rerun to have the same error force you to kill, open, run again… let’s imagine that process takes you hours… that’s painful.

Let’s imagine that you did actually fix it in one of those attempts, only for a second error to occur. in this workflow there’s nothing to tell you that, you keep trying to fix the first problem.

If it exits of its own accord you get feedback which you can use to inform your process… That’s why this is useful.

But yeah, I’ll use it and just not tell you :stuck_out_tongue: (that’s my strategy when told to use Autocad or Sketchup) I’ll let you know how I get on, if it turns out to be a dumb idea, I’m quite happy to tell you all!

Have a great Christmas,

Mark

15

Thanks Erik, I was only joking, I know this is all about process :smiley:

I’d really love to know more about the projects your students do, do you have a webpage (in English sorry)?

I really don’t think everyone is going to use this all the time, but I will find use for it, without it breaking my parametric Snowman.

Have a good evening,

Mark

1 Like
17

@erfajo
Happy to see you back in the forum discussing stupid trivial things. :slight_smile:
Enjoy the comming days with friends and family

19

I think I’ve posted something similar before, but this is usually called the halting problem:

3 Likes
21

Maybe I am thinking about this wrong, but since Dynamo is list based, wouldn’t you be able to predetermine the number of iterations a node should preform based on the input length? If so, couldn’t you program a stop in the try statement to break when that number of iterations was exceeded?

2 Likes
23

I think my post was meant to be more in line with the original intent of the post, which I read as a way to break infinty loops when you had programmed them incorrectly, not so much about making the graph complete in an ordered way. I have used a “wait” node in various forms for sequence, but what I thought @Fiesta was wanting was a way to break out of a death loop.

3 Likes
24

Ahh, so as one is tinkering with their Loop-based script, weather in DS or Python, they could use their own estimate to determine a maximum number of iterations. And if/when they get it working, the max count could be removed (or retained as an optional input). Everybody wins! :yum:

1 Like