Curtain Panels Bug

[H.echeva]

Hello,

I have a recurrent problem with custom curtain panel families.
Sometimes when I create a curtain panel family and I load it into the project it will completely break.
For example, once I had a curtain panel door and when I loaded it into the project the door went huge (bigger than the curtain grids).

Surprisingly, if I change any of the Family materials in the project, the family fixes itself. It almost seems as if the family doesn't update properly and I have to make a random change so it updates.
I am pretty confident that the families are modelled correctly.

I have experienced this in Revit 2018, 2019, and 2020 (all updated to the last build).

Has anyone experienced something similar or know a solution?

Many thanks in advance

[RDAOU]

@H.echeva 

I have never experienced that before...If you are confident the families are properly modeled, why not upload one for the Experts to have a look at it...I am not doubting your Revit modeling skills but maybe they see something which you might have missed...happens sometimes

[H.echeva]

Thanks for the quick reply.

Unfortunately, I can't share families due to company policy.

If this happens again I will try to make a screencast. However, it is not easy to replicate. It is quite random.

This has not happened only with families modelled by me but with families by other colleagues.

To add more information, we normally use nested families. We are in workshared models. And at least the last time that this happened the Family was inside a group.

The reason I say it is a bug is because just by changing a random material (which has nothing to do with the dimensions) it fixes the family and starts working perfectly fine.

If the modelling was not correct it wouldn't fix itself magically as it does.

So this solution works but it is annoying to do every time that happens.

[RDAOU]

@H.echeva 

If it is hard to replicate means its not a big but the error is being caused by something which is family specific (in most cases it is the constraints) ... When loading to the project, Revit does fix or attempt to fix minor errors upon editing type or parameters of the family (even ones irrelevant to the cause of the error) but that is neither magical nor is it a guarantee that the family has been properly fixed

Would be hard to guess what exactly is causing that behavior without the family

[syman2000]

I run into similar issue before. My issue was reference line break when I upgrade from 2017 to newer version. So I have to redo the family in the updated version and the issue fix itself. There are times you may have to do that inorder for these problem to go away.

[barthbradley]

---

@H.echeva wrote:

For example, once I had a curtain panel door and when I loaded it into the project the door went huge (bigger than the curtain grids). Surprisingly, if I change any of the Family materials in the project, the family fixes itself.

---

Makes no sense.  There isn't any connection between the size of the geometry and the Material assigned to the geometry.  The CW Door Width and Height is controlled by the Grid Spacing of the Curtain Wall into which it is inserted.  

[H.echeva]

I know. That's why I think it was bug. We've discovered this "fix"  by chance.

[barthbradley]

---

@H.echeva wrote:

I know. That's why I think it was bug. We've discovered this "fix"  by chance.

---

What Fix?  You mean you discovered this weird behavior?  Something else is going on. I think you're drawing the wrong conclusions.  This can't be related.  

Love to be proven wrong.  

[H.echeva]

Hello,

I was able to replicate the problem in the following video.

This time happened after I made some changes to the family and load it back to the project.

Video:

https://knowledge.autodesk.com/community/screencast/995c7156-898e-41e7-af2c-96717bfb24fa 

I have flexed the family thoroughly. I have even used the Archilizer plugin which flexes randomly all the parameters and everything was ok.

As you can see in the video, there are these problems in the family:

• One column is higher than the curtain grid span. This column is part of nested family and the height is driven by a formula which is equal to height report parameter.
• On the corner the cornice is protuding out of the building. There is a parameter that allows having an extension of the cornice beyond the curtain grid,  but this is set to 0.
• Another column is far away beyond the panel's limits.

As you can see after I change the material parameter to something random it fixes itself and all the parameters work as expected.

Any ideas?

[barthbradley]

Can you post the Family?  

[H.echeva]

Ok,

I really want to know what is going on.

So here it goes.

I loaded it into a new project and created a new curtain wall. Then I started moving gridlines randomly and it broke. Then I used the same thing with the material.

[ToanDN · Accepted solution]

Unpin the Left reference plane, pin the Center (L/R) reference plane, add EQ/EQ from Left to Right at Center.

[RDAOU]

@H.echeva 

In addition to what @ToanDN  posted, I would use an Instance parameter for the Width and VerticalConcrete and in the Host family I would lock the shape handles to reference plans Instead of locking and associating to Reporting parameters

[barthbradley]

The CW Panel Family you posted is not the one you are showing in your Screencast. I'm having no Material-related issues with the one you posted. 

[H.echeva]

Hello,

That worked. I didn't create this family from scratch and I didn't realise they had pinned the left ref plane.

If I see this behaviour again I will check this.

Thanks!

[H.echeva]

It is the same, but it has a parameter to turn off the walls.

The problem is not with the materials. It is with the dimensions.

The thing with the materials is a strange behaviour that fixes the family.

[H.echeva]

@RDAOU 

I used to do it like this. I used to put instance parameters and lock the handles to reference planes.

However, one day one colleague told me that it is more reliable to drive parameters by mapping parameters instead of relying on the handles.

This was very confusing for me because I had always done the other approach. However, I started to research, watching Lynda tutorials (Paul Aubin) and even asked in Reddit what people used to do.

The conclusion was that most people use mapped parameters instead of the handles because it breaks less.

Now, I am happy to hear your opinion on this, because I want to do it the right way.

[RDAOU · Accepted solution]

@H.echeva 

It depends on how they are used...

Using instance parameters and handles don't break in cases similar to this one (curtain panels, families controlled by reference planes or levels)... they actually are more reliable than mapped parameters example:

1. Using shape handles instead of mapped parameters, allows you to keep the reference planes in the child as they were, no equality and the right plane pinned ...Your panel will adapt to the curtain grid as expected. 
2. Using type parameters and mapping them in the Host will require that center l/R plane with the equality otherwise it breaks

on the other hand mapping  parameters in Arrays is more reliable than using Handles but that has to do with the way Arrays in function (not the handles)