I have a script that places a mech equip family over vertical pipes going thru a specific level. It places the family at the floor level (z) at the pipe location (x,y). It will not place a family if there is already a family at that location.
In scenarios when some pipe have families on them and some don’t, the script will remove one of the instances that was already placed. Very odd. So all of the “bare” pipes get a new mech equip family placed on them, but one of the mech equip families that was already placed will get deleted. Not what I want!
For what it’s worth, the ID of the family that gets deleted is then given to one of the newly placed families. I’m using Revit 2020.
Is there any way to keep it from doing this? I’m stumped.
Update: If I close and re-open the script before re-running it, then it works fine. Hmm. Maybe that’s the “solution”. If you need to re-run the script, close it and re-open it.
Update #2: It’s doing it again. Closing and re-opening the script doesn’t seem to be the solution. 
@SeanP is right. This is bindings at play.
The bindings in this dyn:
For more in depth info feel free to sign up for my AU course on the topic - the Thursday showing had some openings last I checked.
2 Likes
Just Undo in Revit to get the deleted Elements and Run the Script again for the new one!
You might need to cut & past at same place for the placed family before placing new one … or you might use dynamo package to bake old elements to not to be deleted.
IMO that is a very bad experience and prone to user error - one forgotten undo won’t show for quite some time.
Best to work with the system and clear the existing bindings, then use Dynamo Player on future runs - no bindings are introduced there.
2 Likes
Dude how to Clear the bindings?
Check the link which @SeanP posted for specifics, but you can either:
- Run the graph in a new file with the node which creates the elements unwired so it produces a null, then re-wire it and save the graph (but don’t run it).
- Open the dyn in a text editor, and search for “Bindings:”, and clear out the data contained in the square brackets.
2 Likes
Thank you SeanP. I followed JacobSmall’s suggestion (“run the graph in a new file with the node which creates the elements unwired”)
Now the script works perfectly. However if I run it a second time in the same Dynamo session, the issue will reoccur. So it looks like if you want to run it again, you’ll want to close and reopen the script. (The script will be read only for users, so we won’t have to worry about Element Binding getting saved into the .dyn.)
As JacobSmall also mentioned, if I run it via Dynamo Player, the issue does not occur. I can run it repeatedly with no problems. Good to know.
Thanks guys!
1 Like
Jacob, your AU class looks great. I’m interested in all of the Learning Objectives. Unfortunately I won’t be there this year - hopefully you’ll post a handout on the class page? I’ll watch for that…
Handout was already uploaded, but I don’t think non-registered users can get to it until after AU, which gives me the opportunity to change my mind and remove my foot from my mouth before I let the world have the handout. 
I’ll try to provide that and whatever else may be needed after AU - letting that content get put out there and supplementing with whatever I have to as needed. 
2 Likes
