PDA

View Full Version : Family with Labels that are parametric



mmiles
2007-10-11, 08:15 PM
Hi all,

I want to make a light family- in the very least a symbol- for my electrical lighting plans that has an element to it that allows me to identify which fixture type it is.

We usu generate a list of fixtures that we use in our houses and then draft plans using one symbol with a set of letters next to them to differentiate. What I don't seem to be able to do is make a label, or text be both multiple things, or toggle on and off in a family.

In otherwords, how do I make a light fixture contain a label that allows me to either directly enter the pair of letters the fixture represents, or select from a pull down list the "type" it is? I suspect this is not too difficult, but I don't have it in me at the moment to pull this off....any help is welcome. thanks.

Calvn_Swing
2007-10-11, 09:19 PM
Usually we'd handle that with a tag, not in the family. If you've got the light fixtures placed, you can tag them in the electrical fixture plan/rcp as needed. I think the default lighting fixture tag goes to either Type Mark or just Mark. You can load it from the OOTB library if it isn't in your file. You'll want to edit the lighting family type properties in the project so that they have the right type mark values, and modify the tag family to use the type park parameter if it doesn't already. Once you've done that you should be able to tag by category and have everything work.

If you REALLY want the fixtures to show their "type mark" you've got two options....

1) Model text can have a visibility parameter associated with it, so you could turn it on/off in each view. It won't scale with the drawings, so I think this route stinks!

2) Much cooler, you can load any annotation family into the lighting fixture family and then place it where you want it. You can even do this with the OOTB tag if it goes to the right parameter. Since it is part of the family, the tag will either show up in all views that you can see the family, so that's the only downside. If you only want to see the tag in one view, but you want to see the fixture in several views, then you need to tag by category. If you can handle the tag in all views you see the light fixture in, then this is a great way to go!

mmiles
2007-10-11, 09:54 PM
thanks, I will look into the tagging. We usually only show the type mark on the electrical lighting plan which, for us, is often separate from the RCP. I haven't quite mastered the tagging- other than doors and windows, that is.

I was hoping to create something similar to a dynamic block in ACAD where I could select the symbol and have a pull down menu to select text which indicated the fixture type. This is also a feature I would like to have with appliances/cabinetry, too (i.e. DW, W, DRY, REF, FRZ).

Maybe I have to use annotation symbols in lieu of real lights...

Calvn_Swing
2007-10-11, 10:14 PM
Take a deeper look at that family. You can see that you can have multiple "tags" loaded and multiple"geometries" loaded as well. As long as these are type values, then you basically have a type-based pull down menu when you're placing elements.

For your situation, I really think you should:

1) place lights as you want them (cans, strips, coves, etc...)

2) Tag them in the fixture plan (we do ours separately as well). You can even try using the tag all not tagged to just tag them all at once. It actually works really well.

We only did this to electrical outlets because we only show them in one place (an electrical fixture plan) and not in other plans (floor plans, finish plans) so we just turn the category off in those plans. We handle lighting just like above. I'd strongly suggest using "real lights" as you don't want to go with something that precludes you from leveraging the data in "real lights" downstream. You may not use it on this project, or this year, but eventually you'll want that data and you won't have a standardized way of doing it or any practice at it because you've gone what I lovingly call the "dumb route." Getting real lights and tagging them is just so much easier than the logistical nightmare that "using annotations in lieu of real lights" could cause for you later...