(Apologies for the lack of graphics with this post. I was getting too many errors when trying to upload the workspace png to the forums… in any case…)
The attached file shows the early development of a room data sheet script. After much searching I finally got the script to place the generated 3D views on the sheet (seen at the bottom). However, subsequent room ids when run through Dynamo overwrite the 3D views. I was expecting it to generate new 3D views and to place them on the new sheets without any inference with already created sheets and views. I even included error checking logic to make sure that wasn’t the case. Ultimately, I was not expecting this problem to crop up but my working assumption that I turn to the forums for feedback on is that the order the nodes are executing is now causing issues?
Did not even touch dynamo yesterday but finally had time to try the code this morning. I’m still learning about the wait/pass node as my dynamo projects slowly increase in size and complexity. Also noticed you changed how the initial Room id string was passed. I’m sure that will be helpful when I eventually wrap up this function for the player. Otherwise I didn’t see any other changes?
Ok. Worked on this a bit more and new 3D views (in pairs) continue to overwrite previous ones. I’ve stripped out even more code to try to narrow down the problem area:
Removed some of the 3D view processing go/nogo logic that checks previous views in case views were getting stuck there and then being overwritten. .
Updated the to the AxonometricView.ByEyePointAndTarget from the previous AxonometricView.ByEyePointTargetAndBoundingBox but problems persists.
Tried many different configurations of Tool.Runme and Passthrough to try and control the order of execution but that had no effect.
Tried to be in a different current view entirely in case the node that creates the 3d view overwrites the current view but new views continue to overwrite old ones.
What I’m expecting the script to do is create neat pairs of 3D views for any room id number entered into the script. If one ran the script for 5 room id numbers, 5 pairs of A+B views would be created.
The automated creation of 3D views can be a very powerful production tool but accidentally overwriting already processed views could be a disaster. I’d be very curious to know if anyone can shed light on the root cause of this issue. At least that could be a point to move forward from. Thankfully images appear to be working again today but the updated graph is also included for convenience. I’m on REVIT 2017.2 & Dynamo 1.3.2
It’s element binding (which is the other thing I did). It’s presence in the graph’s file indicates that you aren’t running this via Dynamo player, but via dynamo, and that you are not closing (without saving) the graph between runs.
An element binding issue? Interesting… Do you have any more information you can share about the mechanics of this issue? (Because, hehe, I’m suppose to be the Dynamo expert in the office. )
You are. I’m writing g up something more formal, but here are the basics:
You don’t want Revit to place a new smoke detector in the active room every time you hit run, resulting in 10,000 duplicate instances when you finally see the category is turned off in the active view… nor do you want to have to delete the previously created beams when you change the maximum spacing from 4 to 5.
So Dynamo has a mechanism for this called element binding. This updates lists previously created elements, moving them to the new location should the input change, adding new instances or deleting instances as needed.
In your case you don’t want this, so either:
Open the graph, run the graph, close the graph WITHOUT SAVING, repeat as needed.
Use Dynamo Player, which does exactly that for each run.
The key in the first option is to make sure you don’t save the .dyn. If you do, all bets are off, as Dynamo has mechanisms for perpetually keeping the element binding going across Dynamo sessions which rely on the file having been saved.
Thanks for the helpful explanation. I was really confused by the behavior of the 3D views overwriting because I just couldn’t see any possible root cause in the script.
After thinking about it I do recognize the behavior you’re describing. The not saving workaround will have to do for awhile until we upgrade to REVIT 2018/2019 with the better dynamo player input functionality. That should be ideal for our project teams: Put in the Room ID of the room data sheet set you’re trying to make. Hit Run. Working with the full script, the workaround does work predictably but is less than ideal in the production environment with +200 rooms/halls.
Looking through the packages, I’m surprised no one has built a node that works around this system behavior but maybe it comes up less than I assume?
There are solution alternatives built around python which avoid this issue, however you’re running the risk of making 30,000 duplicate elements that way.
If this is a graph that people will use often you may want to consider utilizing the Datashapes MultipleInput++ node to generate a better UI for use in Revit 2017, 2018, or 2019. This will not only overcome the adjustable input, but can Taylor a better user experience overall with features like the help button programmed to send an email with useful information for trouble shooting, allowing selection via drop down (imagine asking for room number 36.796ah in your current graph - what would happen?), and more. Well worth the 10 minutes which it would take to set up correctly.
I’ve been using Dynamo for quite a while but for the first time I’m facing issue of overwriting, whereas i’m using Dynamo Player only.
Revit 2021.
Please let me know.
)