Expose Pipe Outside Diameter to Pipe Fitting Families

[ViviNyehuusAndersen]

Background

When creating parametric Pipe Fittings in Revit, the connector only exposes the Nominal Diameter (DN/NPS) to the family.

However, Revit already knows the following properties of the connected pipe:

• Outside Diameter
• Inside Diameter
• Wall Thickness
• Pipe Segment
• Schedule

These values are used internally by Revit to generate the correct pipe geometry, but they are not available to the Family Editor.

The Problem

The same Nominal Diameter can represent multiple different Outside Diameters depending on the Pipe Segment.

Example:

DN Copper Stainless Steel Threaded Steel

DN20

22.0 mm

22.0 mm

26.9 mm

Because only the Nominal Diameter is exposed, Family Authors cannot create a universal fitting that adapts correctly to the connected pipe.

Instead, every fitting requires Lookup Tables, even though Revit already contains the required information.

This results in:

• Hundreds of CSV lookup tables
• Duplicate maintenance
• Increased development time
• Increased risk of incorrect geometry
• Difficulties creating manufacturer-independent content

Proposed Enhancement

Expose the following connector properties inside Pipe Fitting families:

• Connector.OutsideDiameter
• Connector.InnerDiameter
• Connector.WallThickness
• Connector.PipeSegment
• Connector.Schedule (optional)

These properties should be available exactly like Connector.Radius is today.

Example:

Socket Diameter = Connector.OutsideDiameter + 2 mm

instead of

LookupTable → Outside Diameter

Benefits

This small API/Family enhancement would:

• Eliminate the need for most Lookup Tables.
• Allow one family to support all Pipe Segments.
• Reduce content maintenance dramatically.
• Improve manufacturer-independent BIM libraries.
• Improve interoperability across international standards.
• Make Revit Pipe Families significantly easier to develop and maintain.

Why this matters

The information already exists inside Revit.

The API already exposes Outside Diameter and related size information for Pipe Segments.

The Family Editor simply cannot access it.

This enhancement would therefore require exposing existing data rather than introducing a completely new feature.

For BIM managers and content developers maintaining large company libraries, this would save hundreds of hours of development and maintenance every year.

[frankiewiczKZD3X]

PipeType should represent system of fittings and pipes that work with ich other. You wouldn't sell fittings with pipes that do not match. In the same way not having DO is not a problem. 
The number of tables would not decrease, we still need to know every other measurement.

Having a DO would not let you make families that represent reality, so it would only work on base of visual appearance. 
It would not affect speed of creating and maintaining libraries. It could have opposite effect, it open door for more wrong data to slip and make some lines to short.

while we have knowledge of what we put inside of table we have no idea what will bring user, that mean we need another validator for this data.

I don't see how any of this would save time, generating tables from data base is shortest part of creating libraries. 

[ViviNyehuusAndersen]

Dear @frankiewiczKZD3X 

---

Thank you for the detailed explanation.

I understand your reasoning, but from our perspective this would actually save a significant amount of time.

For us, one of the biggest advantages would be the possibility of removing FOD from all lookup tables. Maintaining FOD values across multiple pipe systems is one of the recurring challenges we face today, especially when the same family must support many different pipe types.

It would also allow our generic families to represent reality more accurately. We use generic families extensively to represent various types of equipment, and today we are often forced into compromises because the dimensional information is tied to the pipe type rather than the actual connection geometry.

I fully appreciate that there is still a long way to go. Over the years I have submitted many wishes related to pipes and fittings because these limitations continuously affect real-world library development and maintenance.

As another example, I have never understood why fitting angles are limited to a handful of predefined values. From my perspective it would be much more flexible if angles could be defined per pipe segment and adjusted to the requirements of that specific segment, rather than being restricted to five fixed angles.

Unfortunately, Autodesk has clearly chosen to focus development efforts on Fabrication Parts. For many companies, including ours, that is simply not a realistic migration path. Moving to Fabrication Parts would effectively mean starting over from scratch, which represents a very significant investment of both time and money.

Like you, we drive almost everything through lookup tables, but this is exactly where the challenge appears. As soon as a family must work across multiple pipe systems, the amount of management and maintenance grows rapidly.

Also, if this idea were ever implemented, there would be no obligation to use it. That is probably the part of the argument I struggle with the most. Very often new functionality is rejected because someone might use it incorrectly.

I heard the exact same argument when Autodesk introduced Maintain Annotation Orientation to additional family categories, while pipe and duct fittings were excluded because users could potentially display something they did not want. But if a user does not want that behaviour, they simply do not check the box.

The same principle applies here. If a company or user does not want to use a new capability, they can simply choose not to use it. That should not prevent the rest of us from taking advantage of functionality that could improve our workflows and reduce maintenance effort.

[frankiewiczKZD3X]

that sounds like you talk about ducts,  not pipes. In ducts it may have some sens. But for pipes it will make more work, it wouldn't be just as option, when we can just ignore it, it will make a many problems to all other users, especially when we do not know what kind of connector connect with familie.
The problem you describe sounds like a problem with automatization. I use to have the same fitting families for all pipes without problem. 
 

[ViviNyehuusAndersen]

I am not talking about ducts. To be honest, ducts should have the same segment option as pipes. The important point is that adding an option does not force anyone to use it. If you are happy with the current workflow, you can continue working exactly as you do today without changing anything. For those of us who need to control pipe segments independently of fitting families, the option would solve a real workflow issue and reduce the need for workarounds. I simply do not see why a complex piece of software should be designed around protecting users from making incorrect choices. Advanced software should provide the necessary flexibility and let users decide how they want to model their systems.

I honestly don't understand the resistance here or why this seems to generate so much frustration. Nothing would change for you—you could simply continue working exactly as you always have.

[frankiewicz63WYH]

I do not appreciated, being painted as a bad guy just because I question importance of your idea, there is some bold claims of how beneficial it would be for users.

---

@ViviNyehuusAndersen wrote:

Benefits

This small API/Family enhancement would:

• Eliminate the need for most Lookup Tables.
• Allow one family to support all Pipe Segments.
• Reduce content maintenance dramatically.
• Improve manufacturer-independent BIM libraries.
• Improve interoperability across international standards.
• Make Revit Pipe Families significantly easier to develop and maintain.

• That sound like only geometrical data that we need for fitting is DN, DO and DI. But last i check different producent of pipes and fittings can have different dimensions for fitting(for exemple length of union), so in best case you just have one less column in lookup table.
  
  
• that just sound like you using segments in pipe type in wrong way. When you go to store and buy pipes with fitings from the same system, they should be compatible with ich other, it would be crazy to have pipe DN15 and elbows DN15 but you need to know witch one you should use. PipeTypes try to represent this in it structure(not well, but still)
• for me in best case it would just remove one parameter from families, but add extra logic to check
• it would only affect custom fitting.
• what standards? 
• it would make more complex, now you have more variables that you have to take in to account. Knowing how bizzare some families work with it, what if we connect with heater, valve. Well it would probably be beneficial in connection between two PipeTypes.

The point is: working in this field I couldn’t see this benefits, and you fail to help me see it. Maybe try not see every where 'resistance' and 'frustration'.   

I'm leaving, it's time for a long-awaited vacation.
Good luck

[Susana_Duarte_LMSI]

@ViviNyehuusAndersen, you are not alone. I hate when the information is there and we just can't use it - there are a miriade of cases like that and this is just one. I agree with all you said, including the fact that this idea would not go against pre-existing workflows, so it is not a problem to implement and can be very useful for those that would like to use it. I would probably be one of those given that I'm revising now all our standards by scratch.

There is just one thing I don't agree. You said that ducts should follow the same logic as pipes. I don't think so, as ducts can be custom made for rectangular shapes, so they are a different ball game.

The logic could be usefull for cable trays, though, because we use them for modelling bus bars and technical wall chanels, that can have a completely different set of sizes, and would be great to have them correctly filtered in the list. The same usefullness would be for having heigh values separated from with, as cable trays do have a fixed up and side (with no cover, or automatic way to add a cover - another wish). So even when we model them on a vertical wall by changing the workplane, they still keep the same intrinsic logic of width and height.