Element binding - Can you add shared parameter to families that will change their shape during design and keep these information each time the design change?

Hi everyone, I design 1 specific graph for 1 project. The Dynamo graph supposes to create 5 generic model families from Solid Blocks that were created in Dynamo (the intention is that when I change the solid block’s shape in dynamo --> the family instances’ shape in Revit will change accordingly) Then add the shared parameter for these family instances.

First run, the graph worked fine. As indicated in the photo below, all 5 blocks had expected shared parameters and desired shape.

Now here is the problem:
If i would like to change one of the family instances’ design from a rectangle block to a chamfered corner block and run the graph again for update. Each time Dynamo deletes all the shared parameters that I added from 4 other blocks. Dynamo only added the parameters of the block that i changed the shape.

Do you know what was the problem here? Is this element Binding Problem ? I thought Dynamo would override all elements and its properties on top of old elements which were created within this graph? Means, shouldn’t all of these family instances have their parameters and new design shape each time i run the code?

I had this idea from Jacob Small’s video below, please fast forward to minutes 13:00

@Qnguyen2688 Sorry for the understanding, do you want to add the shared parameter to the family? :thinking:

Hello Vijay, Yes, not only adding parameter but also i want to change the geometry too.
Most topic is only talks about add parameters to “no change” in design elements.

My graph works fine only at first run with Dynamo.

But my problem is that my family’ shape will change during the design (As indicated in the picture, say i like it square blocks at first, then i changed my mind, now i want 1 of the block chamfer @ the corners) if i run the graph 2nd time,or 3rd… or each time when i want to change the shape of the family, Dynamo recognizes this new shape from the same solid block as same element (same ID), but it gives the updated family a new ID, and deletes parameter from the old family which was created by the graph. Which i don’t understand why it does that. I thought what created was undone??? Is this element binding problem ?

Maybe, maybe not.

Without seeing the graph you are using and the data set that produces it, it is impossible to know.

Post a sample data set to reproduce and I’ll try and have a look tomorrow between meetings.

Hi Jacob thank you for reply.
So these are the snapshots



Then if the design change this is what happening:



What i find out is, if i click in the family instance that does not have shared parameters, active family editor mode, the family still has all shared parameters that i wanted.


but somehow as indicates above Dynamo did not let these parameters shows up in revit. And if i load the family back into Revit manually, override the family and its parameters, Revit shows shared parameter again. Because of this as you see in the end of the 2nd series snapshots, i am trying to work around this problem by save family instance as files and reload them back in revit in batch. But of course i still have problems with this route.

Would need you to post the Dynamo graph and RVT to help.

1 Like

Attached. the Revit file is too big, the website does not allow me to do upload sorry. Can you please open revit and create random filled regions shapes then run the graph. Then change 1 of the fill regions’ shape, and run the graph again you will see the problem. Thank for helping

Create bubble plan base on Fill Region.dyn (166.0 KB)
Revit file:

1 Like

I’ll try and get a look later today/tomorrow (depending on where you are). :slight_smile:

1 Like

you could always add the file to a shared Google Drive/DropBox/Box or other file sharing site and then send Jacob the link :slight_smile:

2 Likes

You’re right Tom, I totally forget that. I just updated the comment with the test file now. Thank you.

Couldn’t ever get into that Revit file as it’s behind a ‘request access’ note, so I had to spend some time rebuilding the dataset after all.

Tried looking at this today, and spent some time attempting to make the Parameter.AddShareParameterToFamily node work, and after about an hour and a nice little headache realized that the node needs the shared parameter to exist in the shared parameter file that you’re using to work. Lesson learned. :slight_smile: However, even after getting that straightened out it never consistently worked (in fact for me it consistently failed on the first runs, only ever working on runs where family types weren’t created).

Looking at things deeper though, I don’t think this part of the graph is worth trying to automate. The requirement for the shared parameter file to be set to the one which has these parameters in it is quite limiting - every job you use this on will need these shared parameter already associated to it… You’ll also have a hard time managing to get those nodes to work correctly after the fact. And even if it worked in a heartbeat, and only added 1 second to your run time, you’d never be efficient with the time spend.

Instead I would associate the shared parameter into the family template (save that in the same location you save the parent graph), and use that to creating the family types. This will take you maybe 3 minutes to do by hand, so if you’ll run the graph 180 times (including the time spent in development) you’ll come out ahead. Based on the titles I’m confident you’ll surpass that number as you develop the graph (nevermind the implementation).

I did take a look at a few of the other aspects of the graph, and made some changes which may increase performance speed (the SAT import associated with the family type creation is still and will likely always be the slow point though). Note that there is an “area” parameter associated with my template, but it’s read only so I get an error on the last node.

2 Likes

Hey Good morning Jacob, Thank you so much for helping. I am sorry that did not provided you enough information for helping. I appreciate it very much.

Every advice is great ! I totally agree with the naming convention ^^ I just did not know how to do it before and I learned a new thing with you, Hurrahhh thank for that. Also agree on the parameters too, I did not think of that, but you are right, it would be way easier to build all those parameters it in the family template already then we no longer need shared parameter document.

When i run the graph i meet some issues, i wonder if you can help me with.

1st. The graph sometime (sometime only not all the time, perhaps it is my dynamo problem because as 2 am last night until now, familytype.bygeometry rejected curve.extrudeassolid said solid type was wrong type so weird) creates duplicate, and when I changed the shape of the fill regions, the family’s shape does not change:

2nd. is a bigger issue i met. Please have a look at the Red circle of this family elements. I gave these blocks a name parameter, and other information parameters.
But each time, say if i change one the fill region shape and run with dynamo again, the block will change the design accordingly. Dynamo erases all these information.

In the photo i only have 5 blocks, each block has 5 information parameters (fill color, space name, space usage, area, required area) just for testing. But in a real project say we have like 30-50 blocks or more. The amount of work to re-punch these information in is a lot.

Do you have any advice for this case? Now it is not just element binding, it is also (I guess I call it as…) element’s information parameter binding haha ^^, Thanks very much again for all your efforts…

believe that this is because the FamilyType.ByGeometry node does not initiate Element Binding - only the placement of the family instance bound into the file. You can confirm this by saving your .dyn and opening it in a text editor. Search that file for “Bindings” and you’ll see a list of the bindings added to the file. If after running and creating data you only have one line you can assume it’s the FamilyInstance.ByPoint node, but best to confirm by searching the GUID. My AU session has the information required to perform such verification.

Since your family type is changing with no binding, the parameters will too, which means you’ll loose the data in the relevant node.

You could attempt to add bindings to the action by making a custom node, but I’m not sure how well that will work. There is a FamilyInstance.ByGeometry node in the Springs package (I think - package may be wrong) which may have bindings built in as an easier first try.

1 Like

Thanks Jacob, let me try that watch your video again and follow the steps mentioned there and here.