It will abort when you select “Select none”, and still give you the “dashboard”,
Until you select “set values” ,then the script continues
Maybe define a Watch node as Output in a Dynamo Player scenario
If you can put your script in one python block then progress bars can be made. As far as i know it cant be made to work with normal nodes.
In pyrevit there is a progress bar tool I use in most of my scripts also, which is in its forms library. Its great as the user has confidence the script is actually working.
I am not sure this is accurate anymore. It’d take some work, and it might fail for reasons I can’t foresee, but someone who’s ambitious enough could try:
At the start of your graph initiate a virtual server of sorts
Look into the TuneUp view extension which tracks node execution time, reporting live as long running nodes execute
Pass the node names to the virtual server
Have the server display a UI illustrating ‘last node executed’, and a percentage of nodes executed on canvas.
This UI could be left open until a ‘finished’ result was pushed to the external server.
Additional data (ie: elements created, warnings produced, etc.) could also be gathered at this point.
Some caveats:
You cannot assume that the percentage of nodes executed is a percentage of runtime (see any graph which takes 15 seconds to produce results from one node, but 1 second to run the 200 other nodes on canvas). As such whatever you report will be inaccurate in terms of overall runtime.
You cannot list what node is executing at any moment (as far as I know anyway)
All of this will slow things down, as most integrations are in-process which means you’d be unable to pass data to the virtual server until any given node is finished, and you can’t start processing the next node until the data is transferred to the virtual server.
Cancel a run once it’s underway. Once the rocket takes off it’s too late to stop without resetting the whole situation.
Producing this would be a VERY big lift (I say that a few times a year, but this one may take the cake… But for someone with the right experience it could be the simplest thing ever).
Build such a tool once and not have to plan on a big lift for maintenance each year.
Any given firm update to Windows, or AV/ASW/Infosec may nuke the entire portal on occasion, so long term reliability might not be swell.
Utilization of taht tool in the context of Dynamo player or any other RestDynamoCore instance would be limited if not impossible without significant retooling beyond what TuneUp exposes (no view extensions in those environments).
Because you’d need a front end (Dynamo Client), back end (server), UI for each, and likely other tooling/logging… this would likely best be tackled as a team. Perhaps a POC would be a super interesting hackathon project…
Edit: TuneUp code base for anyone interested: GitHub - DynamoDS/TuneUp: A profiler for Dynamo graphs
I guess a hackier but simpler version of that could also be putting a flow node at bottlenecks in a script and sending those moments to a virtual server as well.
Soooooo… I am currently authoring a bit of Python to create a framework for this via HTML. This removes the need to author a back end, as your browser (chrome or edge or firefox or whatever) will just do the trick. By placing the ‘initiate’ node on canvas, and the subsequent ‘update’ nodes at desired points in your graph you can inform the user of whatever you’d like along the way.
It’s honestly so easy to build that I wonder why it hasn’t been done before, leading me to question what roadblock I haven’t found yet.
Assuming it all works out, when done I’ll share the content when complete.
Happy to share some code later, but I won’t be booting up the hobby machine until my weekend chores are done.
I’m at the point of writing the HTML display, as simple text didn’t see to be functional enough. Once that is done I’ll have shareable code. Winds up making HTML based dashboard displays with only a text editor (what I have available on the laptop I’ve got with me) is cumbersome, and why we have specialists for this stuff.
Already done getting the browser to open and refresh display data periodically; getting RAM info (% in use, available RAM, available VM); getting the workspace name (without requiring Dyamo for Revit); and getting object counts by type (expecting dictionaries, so I may revisit this later). I also had CPU load being pulled, but I didn’t trust the number being returned, and it required either an extra dependency or triggering a brief console window pop up which I didn’t like so I scrapped it for now.
Got a good way to go still, but I hope to finish tomorrow.
A few web things to fix still
Extra scroll bar pops up if the page is too short
Flickering which results from the forced refresh method I’m using isn’t desirable so I might revisit that.
Font sizes and boarders aren’t ideal
I’m not sold on the layout overall…
On the Dynamo side there are a few bits to go as well:
It completely breaks if fed infinity (which is an edge case sure, but one worth handling)
My method for overwriting the HTML isn’t very clean (likely i should write out a JSON instead and read that in rather than forced text, but having the data in one spot felt useful to me for some reason)
CPython and IronPython compatibility needs to be fleshed out.
Testing in older versions will have to happen to (currently working in 2.12+; not sure how far back it’ll work).
Will share the nodes and external resources via a package (too many moving parts otherwise) sometime tomorrow.
Getting this to move between systems is proving a bit of a challenge… By no means will this be an ‘easy’ bit of data to work with. I’m definitely second guessing my reporting method too. Likely going to scrap directly writing out HTML entirely tomorrow (to make scalability much easier), but going to review the idea with a few colleagues before I do so.
Think about writing to json(or a database) and then having something else read the json data. This should make it scalable and readable via most applications
I am intrigued at how you are getting the data out
An example just with a console (a RichBoxText) and a progress bar to see the global progress of the script execution.
It’s not perfect (Exploring and discovering the DynamoCore API is not easy ) and not compatible with the Dynamo Player
That was why I moved away from the view extension. I also wanted the capability to let users know more then just “what node ran last”, and expose stuff like object counts by type, messages from the author (expect this next section to go slow because ____), and to leave a record on the system when done. This moved me to the HTML solution posted above (in non-GIF format), but it’s too ham fisted. The external service would be way more useful and compact… ideally as a view extension for player and Dynamo core… That’s a VERY big ask though as the two systems aren’t necessarily speaking the same language.
In this case they are saying it only works if running within Dynamo itself. Some alternatives to this could be using timer nodes to report time elapsed at various stages of the script if you want to at least see how long each part took when finished, or could trigger windows form messages to appear at various stages which happen before end of the run.