I’ve got a script that places an ACAD dimension then two MTEXT objects at the start & end of the dimension. It requires the selection of a profile view and a pressure pipe. My problem is that when I run the script a second time with different objects, the MTEXT objects from the first run are deleted/moved to the second pressure pipe. The original dimension stays, though.
What I expect is that when I run the script it creates a dimension & two MTEXTs each time it’s run with different objects. But the MTEXT objects created from the first selection are removed when the script runs again.
This sounds like an issue related to Element Binding. There were similar discussions about this topic. You can find a detailed explanation here.
Ok, but what if you don’t want element bindings? There are two methods to fix this which use. I recommend doing a save as in both cases, and checking the before and after carefully when done.
Open a new Revit file, then open the .dyn in Dynamo, disconnect all nodes which ‘start’ the graph (basically disable anything in the ‘gather’ stage of your workflow), and run the graph. Quickly confirm that the many errors have produced a null result on EVERY node which interacts with Revit. Normally, this would be bad, but in this case… save the graph, reconnect the selection nodes, and save the graph again. The bindings should have been removed. Alternatively you can replace the nodes which create Revit content with new versions - copy/paste is your friend. This can be difficult as you may not know every node in your first pass. Both of these methods are more ‘user friendly’ to perform, as they keep you in the Dynamo user interface.
Open the graph in a text editor, find the “Bindings” section, and remove all the content in the brackets. Be sure to catch it all and not mess with anything else - you may corrupt your .dyn otherwise. This is nice as it can be automated (with Dynamo even), and as such can be performed quickly on many files at once.
But there are situations where you want to update previously generated objects (but I’ve not been in that situation so far).
With unchecking all options, they newly created objects are only updated while you have the graph open and rerun it in the same session. After reopening the graph, the previously created objects will remain.
Ever build a graph that places block references along an alignment at a given interval?
If so did you go back and adjust the spacing to see what happens if you change the value to 2*x instead of x?
If while you were authoring you didn’t want to have blocks on x, 2x, 2x, 3x, 4x, 4x then you wanted to make use of binding.
Once it’s ready for deployment to the masses that is when Civil 3D users might want to turn those values off. Anything before that point runs the risk of confusing the graph author with duplicated elements (or elements placed where they think they shouldn’t be).
In the user’s case they might have authored the graph to place the mtext on the right side, then the left, then the right and the left (assuming they made use of lacing). if binding wasn’t in play they might think they solved it by toggling the switch to ‘left’ with the ‘right’ portion still existing. Run it in production and they only get left and then go back and toggle it to right. Then it fails again on the 3rd profile… etc.
But… the mechanism is too unmanageable imo. The settings are user settings and can differ from Dynamo Environment and Player. Working together in the same project with each different settings (maybe someone forgot to uncheck or check the settings after another project, or used the Player), and the whole project can be ruined.
So… I prefer to uncheck everything. This means that while finetuning, all objects will be updated on changes. If a client prefers otherwise, it is a new request which could be payable. Using Dynamo does not necessarily have to be for the client’s benefit.
And with Dynamo it is quite easy to find and delete those previously placed blocks or MTexts along an Alignment
With every setting off, I’ll never be surprised of accidentally deleted Alignments, Profiles, Corridors, whatever I’ve created before in other parts of the drawing. That is more valuable to me than maintaining graphs per project for an unknown wish in the future.
The best way of course, is when the settings where drawing based (and in accordance with how you describe the situation). That these settings are visible in the editor or in the Document Panel (and adjustable). Then you can use it to its full potential in every situation, without these crooked situations where some don’t want to use the mechanism because of inpredictability, and other’s are displeased by the unclear OOTB settings (how many topics have already been started on this subject ).
To me this is the difference between the initial authoring of the graph and the use of the graph. Initial author wants it on as otherwise you can’t see how the change breaks functionality when offsetting by value X instead of value Y, but once you are done authoring you want it off so you don’t run into the issues described. But if you default to it on… well expect a lot of content placed at your origin which you’ll have to manually delete if you ever use Automatic run mode, or a lot of overlapping objects if you start to dabble in generative design.
Really the ability to ‘disable or enable when ready’ is an advantage for the Civil 3D flavor of Dynamo, even though I dont’ like that it deviates form the [Revit, Robot, Alias, etc.] integrations.
The first alternative to what Civil has is “always on” meaning you always get previous content removed if there are bindings in the file, in which case the topic I linked is the likely path forward as this is the behavior in Revit.
The second alternative is “always off” meaning you have to deal with one of the 19213691 trees which are populated already existing and your guess is as good as mine as to which is which. In drawing based workflows maybe that’s a non-issue as you reference stuff by name and things like dimensions persist even after you delete the host, but in BIM based workflows it winds up with significant duplication as the new object ID means a new object means the dimensions and weeks of applied data built atop the previous instance just pulls a snap… and stops existing in an instant.
