Some of the things we do with Dynamo take a long time – on the order of hours. I’m going on about a 16 hour run with this definition and have no idea how much longer it might take. In the meantime, I’m running out of RAM (27.4 used out of 32). If there where a progress bar and/or and estimated time to completion I would have some idea how much longer it’s going to take and whether or not I should stop and retry with different settings to, in this case, lower the number of points I’m creating.
Is it possible to implement something like this?
7 years later I would like to revive this topic. Is there any chance to get the current status of execution/progress?
9 years later, is there any chance, that we can create that progress bar?
Hello @jayeshx.prashant.kas - While great on paper, there is a lot of nuance to a progress bar in the context of Dynamo.
- Dynamo, in the context of Revit (Which is in-process and has the same execution and UI thread) locks out your screen when Dynamo is executing. This also means the UI is locked, making it difficult to get around with an animated progress bar that isn’t faked (i.e. a GIF on a loop).
- A progress bar can be either faked (100 nodes / 100 chunks to “progress”) which is indicative, not real, or truly map to execution; In the context of Dynamo, typically one or two nodes are the “heavy” ones that mean the progress bar would go fast for a while, then stall out for 95% of the time, then move again.
In both cases we’re unsure how the value would actually manifest here comparative to spending time doing something else.
We do have the TuneUp extension now that allows you to track which nodes take time and how long they are taking, which we believe is a more accurate option. But we are very open to discussion!
2 Likes
give this a look. I used it a while back and i recall it worked quite well. Not sure if it suits netcore builds though.
How about a cancel button to save your work from a crash… ?
That toolbar supports that i think, but needs to be ran in a python node including cancellation checking during iterations as part of the python coded logic, after which the rest of the script would still execute. Cancelling and loading bars on the canvas arent possible to my understanding, unless there is some sort of hack that can be built using the dynamo API.
99% of the time i crash or freeze in dynamo is due to carelessness like setting up an automatic mode get/set parameter routine or using lengthy list levels accidentally. Over time you just learn to move slower and more intentionally before connecting, and automatic mode is risky unless you’re very careful so i often work in manual mode.
My usual crash culprits in my day to day work today:
- Doing something in the API which I shouldn’t be (50% in Civil 3D, 20% in Revit, 65% in core where the API really needs some documentation love).
- Loops in imperative designscript (20% in each).
- Dealing with corrupted data (5% in each).
- Triggered by something outside Dynamo (25% in Civil 3D, 55% in Revit, 10% in core).
IMO slow runs due to large data sets and incorrect list level and lacing structures are not a crash, have patience, get some coffee, and think about what you need to create next while the CPU chugs.
2 Likes