How to pass Hosting Wall thickness value into the family?

[Gadget Man]

Just a quick question:

Is it at all possible to somehow pass the value of Hosting Wall thickness into, say, a window family in the Family Editor? What I want to do is to define a type parameter that would react differently according to what overall thickness of the wall the window was inserted into.

Eg. My parameter could be: "Reveal Width = if (Host Wall Thickness NOT> 70, 70, 80)" - meaning that for any wall with total thickness of up to 70 the reveal would be 70 , but for any biger wall it would be 80. To do that, the formula would have to know this particular Host Wall Thickness value, that would depend on the type of the wall the window goes into (so it can't be determined during family edit).

I hope that you understand what I tried to say...

Jerry

[mlgatzke]

What if you place a couple of refplanes on the surfaces of the wall, align and lock them, and place a dimension to the two refplanes. Then parameterize the dimension with an Instance Parameter. This should then be able to pass itself on to a nesting family. Don't know if it WILL work, but it sounds like it should. Anyone done this?

[edit] Oh, sorry, I'm thinking along the lines that this would be within a wall based family of some sort - like your window.

[Gadget Man]

Yeah, I thought about it too first - used a parametrised dimension between existing "Exterior" and "Interior" Ref Planes, but then, when I changed a wall thickness definition (in Wall Family properties within Window Family Editor) it screemed a blue murder ("constrains not satisfied") - as to be expected... No good.

Thanks anyway.

[Mr Spot]

I'm pretty sure this isn't possible and i have had the need for it previously...

[Gadget Man]

I was afraid that somebody might say so...

Oh, well... Pity. Maybe in the future. (Unless somebody comes up with some solution after all..?)

Thanks anyway...

[Tom Dorner]

Give this a try......place a reference line perpendicular to the wall faces (the width of the wall). Align and lock one of the ends of the reference line to one wall face and the other to the center reference plane. Add a parameter that dimensions to the endpoints of the reference line. (edit: I used a parameter called half_width)

I tried it quickly here at home watching late night TV and it seemed to work without the constraint errors experienced using the reference planes.

Tom

[Gadget Man]

Tom,

That was a very interesting approach and I tried it instantly.

Unfortunately, unless I am doing something wrong, it still doesn't work (however, in a different way now). While it doesn't produce a constraint error any more, it simply maintains the same lenght of this Ref Line, regardless of what is current wall thickness changed to. I tried to align both ends of it to respective wall faces (and it showed all right - with locks and all), but as soon as I flexed the wall thickness, it lost one or the other alignment point. I think that what the problem is - we simply GIVE (introduce) another additional parameter value to the system (trying to constrain it even further) instead of TAKING this value (information) out from it. As I see in now, there is NO easy way to READ this value FROM the wall definition.

But... I shall keep trying to find the way...

And the spell checker doesn't work....

[Tom Dorner]

Ok...I tried something else this time and got a little further. I created a detail component of two reference planes and loaded it into a window family. If you change the width of the host wall in the window family the detail component parameter of "Wall_width" actually reports the wall width now rather than drives it. The trouble is that any attempt to link the "Wall_width" parameter of the detail component to a window family parameter only works one time, then the association get broken and the parameter now wants to drive the wall thickness. For a minute though I thought I had figured it out. I too will keep trying. This would be a lot easier if Revit had a "read only" type of parameter that reported the distance or condition of something.

Tom

[Scott D Davis]

So you are saying we need two parameter types?

A "Driving" Parameter
and
A "Reporting" Parameter

hmmm...interesting!

[Tom Dorner]

Yes Scott....I envision being able to set the door swing for example to 45 degrees if the wall is in phase existing, 90 if not in phase existing. Being able to "read" a wall thickness for example would "drive" a different HM frame size. The list goes on and on.

Tom

[Gadget Man]

Being able to READ the hosting wall thickness and also the TYPE (!!!) would be of even greater benefit - eg. we could have automatically adopted wall composition (and thickness) to , let's say, this little sill wall under a bay window (whatever it is called...), which could be defined as a part of fully parametric bay window family.

[dazza163968596]

So you are saying we need two parameter types?

A "Driving" Parameter
and
A "Reporting" Parameter

hmmm...interesting!
Scott,

Has this been added to the wish list? I don't want to post a duplicate wish. I could find lots of uses for a reporting parameter it would stop a lot of the "model over constrained" errors.
It would be great if we could use a reporting tag in formulas with system parameters and instance parameters referenced in the formula as well.

[Haden]

...it would stop a lot of the "model over constrained" errors.
Perhaps this is part of what the new Interference Check feature of 8.0 will do...:???: