Controlling Parametric Voids in a Family?

[cek]

I'm interested in creating a roof panel family that has edge and field voids that I can control with drag arrows while the family is in the project.

I've created a rudimentary panel that does this through parameter dimension controls to manipulate the void elements but the usability is a hit or miss approach adjusting parameter values and then reviewing the model for accuracy. I would rather just be able to turn on the void function and then drag the void edges to the appropriate locations in the model.

Has anyone run into this or have a link or methodology to address the drag edge functionality in a family?

[wmullett]

Instance based labels ... not type - then you will have grips in the model to control the void. BTW, you can't turn it on or off but you can drag it off so it no longer cuts.

[cek]

I'm not following you on this one. Labels do not appear to be an option in my family. I'm familiar with labels in annotations.

[Steve_Stafford]

Reference planes that are using an IsReference value of Strong or the named values combined with Instance Parameters will provide the grips to drag interactively. Create the reference planes, dimension to them and lock your solids/voids to them. Is this what you are after?

[wmullett]

2009 Family editor ... clicking on the dimension brings up the "label" parameter ... not running 2010 right now.

[cek]

Thanks Steve,

Your recommendations have gotten me one step closer. I can get the drag arrows to show up on a square penetration but for some reason two faces maintain their distance from the panel perimeter and the other two operate freely.

In the family I can grab the reference planes and move them freely so they aren't locked in position except relative to the other reference planes of the cutting square.

Of course to make things more diffcult I've nested the panel family to a roof hosted family but we can deal with that after I get the main panel functioning properly.

I've attached the main panel family I'm working on. Disregard all the unused parameters which are there from a previous methodogy I was employing and haven't cleaned out yet.

[cek]

Ok, I derived a solution. I needed an additional ref plane one beyond the limits of the width and the other beyond the limits of the length. I assigned a strong reference to each and a dimensional parameter. This locked the non-movable faces beyond the panel limits.

See attachment.

Now on to the nested host issue. May have to generate this family in a roof based family to start with.

Thanks again for the assistance.

[cek]

Can't seem to get the settings right to permit the nested family to give me the drag control features. I am working in 2009. Not sure if this is a version limitiation or if 2010 has corrected for this.

I can get the roof based host family to give me all of the void drag controls but once I bring it into a project I loose this capability. I've used both shared and not shared settings on the nested family.

Another annomally is that I've create three different panel versions in the nested family (no cut, 1 cut and 2 cut) and while I can select these values in the type selector the type selector will not drive the panel change. I essentially have to drag the other panel I'm looking for from the Project Browser.

Maybe I'm not really understanding the nuances of nest family control because I can't seem to get this to work.

[Steve_Stafford]

I haven't looked at your file but based on your comments. If you want the drag capability to affect a nested component then you need to use instance parameters in the nested family and align and lock those to the host family.

In effect you need to recreate the conditions/constrains in the host (final) family and drive the nested geometry there. This means you can define the nested family fairly simply with instance parameters and strong reference planes so you can drag them into compliance with the host. In the project you get the host's drag controls, not the nested family. Hope this makes sense.

Edit: I looked at the family and re-read the thread....can we start at the beginning? What do you want to do again? Here's my take:

You want a roof panel - but you have a structural framing family posted (nested roof panel is structural framing too but you started it as a Generic Model Roof Based and changed its category?) If you want the family you put in the project to be hosted by a roof it has to be the hosted family type, the last one, the one that goes in the project. Nesting "kills" the hosting behavior of the nested file.

You need a void - 1 cut, 2 cut and none This could be done by pushing and pulling the void in an out of the panel according to yes/no parameters. One solid, 2 Voids, reference planes and dimension/parameters to drive the push/pull with yes/no parameters to turn on/off the voids so to speak.

I don't think you need to nest to get the result you are after. Start with the bones and muscle, reference planes and dimensions, to define the behavior you want and then add the solids and voids.

[wmullett]

Attached is a test family that shows a parametric void that can cut or not by dragging it off the soild.

[cek]

Ok, I backed up into a roof based generic family and recreated the parameter controls. No nested family.

I've also attached a test project. In the test project the panels have two problems. When the roof has any slope (1/2 per ft showing) the slope oriented drag controls are not available while the drag controls pendendicular to the slope are available. As soon as you flatten out the roof the other drag controls become available. I have a feeling this may be an unresolvable issue.

The other problem is the Type Selector will not drive a single panel into an alternative cut configuration.

[cek]

Opps, Spoke to soon, the epiphany was late in arriving. Switching to wireframe gives you bi-directional control of the drag points.

Also resolved the type selector problem. I had the parameters driving the void cut / no cut control as instances. They are now type parameters and everything appears to be working fine.

Thanks Steve and WM for all your input and helping me to resolve this family.