Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Or allow the creation of a tag that would incorporate the elevation of the device. Different organizations tag with slightly different styles (ours uses the format [ +64" ], but I've seen other organizations use something like [ 64" ]. If the elevation could be incorporated into a tag, it would prevent us from having to set the elevation and manually calculate that elevation in inches.
I have added custom offset instance and/or type parameters to my entire library to control the height above floor level and allow schedules of heights to be created.
It was a LOT of work.
Also, stop creating OOTB content like sockets with the offset to the middle of the accessory, NOBODY in the UK sets out to the middle, its either the top or the bottom. Same as Tray.
I've been asking for years for the ability to tag Elevation and Offset for all MEP content. Please make this happen!
@scott, I'm afraid that it is common in North America to measure elevation from the center of small items such as receptacles (sockets), outlets, and switches. However, if it is common in the UK to use a different location on the box for elevation, then I agree that the UK OOTB should match the common use.
@Scott_D_, I just came across this idea and saw your post. I, too, had begun making my families so that elevation above the level was controlled by some other instance parameter besides 'Elevation.' So I would leave my 'Elevation' parameter at 0' 0", and adjust my Device Height parameter.
However, this has a downside: If the item you're hosting the device on (typically a wall) ever doesn't extend all the way to the floor, then Revit will not find a host. We've come across several instances in which, in the model, the architect has provided some poured slab over the top of the structural slab (which defined the level), and the wall begins only at the top of the poured slab. Because we were hosting the family at Elevation = 0' 0", but the wall which we were trying to host to didn't actually begin until 0' 1", Revit would allow us to place the device, but would immediately tell us that a host could not be found. Thus, when the architect adjusted the walls, none of our devices would move with them. This is a pain.
So, we've started doing this: Instead of having our family controlled by the elevation parameter, we just have an elevation parameter that ONLY controls tags and schedules. Therefore, we have to type the device elevation in two places: once in Revit's default 'Elevation' parameter, and once in our tag/schedule parameter. This is also a pain, and more work than it needs to be, since Autodesk should provide this functionality, but less of a pain than chasing the architect's walls.
Another, more minor downside is that, when using a separate offset parameter, space bar to rotate no longer works. The space bar rotates a family about its z-axis. Well, your z-axis is always at 0' 0", so if you try to rotate, the device will spin around all over the place. So you can't have a horizontal receptacle doing this, for instance. Not such a big deal for devices, but maybe for lights. If you have a rectangular light that can be wall-mounted vertically or horizontally, if the height is controlled by a separate parameter, you'd have to have two different fixture types to achieve this: one for vertical and one for horizontal...
@scbunker I have the same issue as you with emergency exit signs over doors, it always complains it has no host as the host point is where the door opening is.
I ignore it to be honest; I could align and lock the element to the wall but if the wall doesn't move its not going to be an issue. It doesn't cause that many issues.
I agree with your comment about the element doing strange things when rotated, it can be quite bizarre and the only way to fix it is to delete the element and start again with a new one.
I use a generic extrusion for my lights, if its longer than it is wide or mounted sideways I just put the height, length and depth in the relevant parameter fields and it sorts itself out. Not particularly aesthetically pleasing but it does the job.
You could put the extrusion on its own workplane and use a parameter to set it at whatever angle you fancy, I've never had much success doing that myself however, never seems to work correctly.
You could address the 1" wall issue by setting out all your families at 2" elevation using a custom height parameter that states what you want the height to be but have the actual height above floor level be set by a second parameter which equals the height you select affl minus -2". It's a bit of a nasty hack but it would just about work. (please don't throw things at me)
I would also be tempted to create new levels based of the finished floor level, not the level 1" lower
For “support tagging the elevation for MEP content”, how do you think be expected behavior in your workflow?
As mentioned above, the elevation may represent differently for different fixtures/equipment, e.g. as below image shows, for the Radiator the elevation means the bottom of the content, for the sink the elevation means the top of the content, and for Wall Lamp, Lighting Switches, or Receptacle, it means the center of it.
If the elevation property is supported in tag and schedule, how would you like to use it to based on above issue?
And currently, the Elevation properties value is dependent on Family’s original point and its schedule level, how does it work for you to create your own families and set proper elevation value?
I created my entire library of content from scratch built from an elevation line, this was set to be the bottom of low level accessories and the top of anything above roughly 1000mm affl.
It's less a question of how to implement it and more about where the origin of the geometry is in the family.
UK setting out doesn't usually use the centreline as this would mean that the top or bottom of accessories that are slightly different sizes would not line up with each other.
Top and Bottom elevations are both required but just turning it on so we can use it at all would be a great start.
Do you mean ideally you may want both Top Elevation and Bottom Elevation? if Revit Support the Elevation parameter for MEP content for Tag and Schedule without change the Elevation definition behavior, how will it help?
and could you explain a little bit on "It's less a question of how to implement it and more about where the origin of the geometry is in the family." Do you mean the family's original point definition?
If I have the same type of accessory, say a fused fused connection unit, used at 450mm affl to the bottom as well as 1600 affl to the top, in different locations for different uses.
The low level element may be for a radio frequency speech broadcast unit at a reception desk and the higher element might be for an intruder alarm main panel supply.
The images below might help, all of the text is Tags generated from parameters, none of it is typed by hand as plain text. I need the parameters available to achieve this quickly and accurately.
Each family has parameters and values for both top and bottom elevations at the same time. The way that I show the elevation i want is to choose a tag which references either the top or bottom parameter to show the information I want to display.
By origin I mean where the geometry starts in relation to the floor, all my families are inserted at an elevation of zero, it is the geometry in the family that moves, not the family instance itself.
I think the origin would be sufficient. All of our devices are setup with the origin in the proper location for it's elevation. So if the elevation should be to the top of the device, that is where the origin is setup.
Having just that ability would be great, but being able to maybe tag items based on the Reference Plan "Is Reference" options within a family would also be great.
So say I have a ref. plane that is defined as the Top, then I have a tag option to tag that specific reference plane for it's elevation. This would be the case for all of the other Is Reference options.
I am having a hard time following @Scott_D_'s recent posts, but I think I agree with @casquatch regarding defining the origin. I, Iike @Scott_D_, have created all of my families so that they are always inserted at an Elevation of 0, and a separate, taggable parameter for their actual height above level. This sometimes causes problems, however, and I would much prefer to just be able to tag the elevation.
Since there is a 'defines origin' option for reference planes, our families can be created depending upon whether we want the top, bottom, or centerline to be the elevation. We just have to check that reference plane as the origin.
I think casquatch is onto something. I think the origin is sufficient for the work my company does, but as scott.dakin stated, there's still a use for tagging multiple locations of the device. At the very least if we could tag the origin, we could create a separate family for top/bottom elevated devices. While inconvenient, tagging any elevation is better than tagging none. I do request, though, that the tag be capable of using a difference distance standard than the rest of the project. We generally use feet-inches for most dimensions, but for the elevation of devices, we use a format like +48" since 4' 0" would take up too much space.
Yes to @aaron.jonesSAP83's comment, being able to specify units of the tag is very important! Our company (and all other companies I can think of) tags elevation in inches only. If the feature only allowed #'-#", then the feature would be useless for us.
Origin is normally sufficient for our purposes. All of our families are created so that the Elevation parameter drives the modeled elements. There are too many modeling issues using a shared parameter to drive the modeled elements, as discussed in this thread. Also, since I've been pushing for this idea ever since Revit Systems came out, I was always my hope that Autodesk would eventually grant the wish and all I'd need to do was update a single tag family rather than revising my entire content library.
Having said all that, content that measures elevation from the top will be modeled in the family so that the origin is at the top of the model. For families that measure elevation from the center, the modeling is centered around the origin. If elevation for something is measured from the bottom then the modeling is done with the origin from the bottom. Examples of all three cases are shown below.
In other words, we would be content with just getting the Elevation parameter exposed to schedules and tags. It is my assumption that a downstream consumer of the model, when querying an element for their elevation, will understand that the Elevation parameter is showing the elevation that is/was used in construction, e.g. center of receptacle/outlet when in the US.
However, I can understand the needs of other regions of the world too and having the option to tag the top or bottom of elements' elevations would be good for all folks.
@aaron.jonesSAP83 and @scbunker, since we are talking about the normal tag system, it was my assumption that granting this request would provide the usual units override that is available for length units in the label dialog box.
@aaron.jonesSAP83, @scbunker, regarding "tags elevation in inches only", will you have the scenarios that the #'-#" style for other dimension and #" style for elevation showing on the same drawing? (like the below image?)
Currently, as @r.robert.bell mentioned above, the elevation was also controlled by Length units in Project Units setting dialog, when you change it to Fractional inches or Decimal inches, it will show #" style for all Length related parameter including Elevation, will this help?
I think using the Length Unit would probably work. Within the tag family we have the option to adjust those tags specifically away from the project settings if we wanted, so I think this would work for each tag as needed.
