Electrical Equipment Built-In Parameters Setup Backwards!

[Anonymous]

Why has this still not been fixed!?

*I posted concerning this topic again because I have additional details on the breadth of the problem, and another user who brought this up back in 2013 accepted a faulty solution instead of leaving the problem unsolved. In reality, Autodesk's Developer Team needs to fix this.*

This issue applies to the following parameters in Electrical Equipment (NOT JUST MAINS):

 - The 'Mains' Parameter... It's an Instance and should be a type

 - The 'MCB Rating' Parameter... It's a Type and should be an instance

 - The 'SubFeed Lugs' Parameter... It's a Type and should be an instance

A little background for anyone who doesn't know exactly what these properties mean:

Mains is the Frame Rating (Physical Enclosure Rating) of the Electrical Equipment.... This is the current rating that the physical equipment and internal components are meant to handle as manufactured. This is in Revit as a Built-In Instance parameter... it has been this way since or before 2012 and should be a Type parameter.

MCB Rating is the trip rating of the Main Circuit Breaker (or fuse rating) that has been specified by the electrical engineer. This can vary wildly between equipment of the same type or even frame rating (Mains). This is in Revit as a Built-In Type parameter... it has been this way since or before 2012 and should be an Instance parameter.

Subfeed Lugs dictates the presence of 'Pass Through' lugs that let an upstream panel feed a downstream panel, and let the MCB of the upstream panel protect the downstream panel. The presence of SubFeed Lugs can vary wildly between equipment of the same type. This is in Revit as a Built-In Type parameter... it has been this way since or before 2012 and should be an Instance parameter.

The previously accepted 'Solution' (Found Here: https://knowledge.autodesk.com/support/revit-products/learn-explore/caas/screencast/Main/Details/0b8...) is not a realistic 'Solution' as it does not solve the core issue and is not scalable... especially on large scale projects. The projects I work on seldom have less than 80 panels and some have over 250. Even if Autodesk doesn't want to fix this, I would consider it a solution if they were to deactivate these Built-In Parameters instead of forcing them on us. At-least then we could set them up properly ourselves without confusing the heck out of our modelers... modelers who just end up seeing Two of every parameter. BTW Autodesk, if you're listening and you care about the 'E' in MEP, give me a ring... because I have a list of 20+ other serious improvements that could be made to Revit Electrical.

[RobDraw]

Most people that don't like the content provided by AutoDesk, which is only provided as examples, either modify it to suit their needs or make their own.

This is a user support forum. Not a way to contact AutoDesk to complain. There are a few ways that are more appropriate.

[Anonymous]

That would be nice! I sure wish we could modify these parameters!

[RobDraw]

Why not start from scratch and make your own, if you are so unhappy with the provided content?

[Anonymous]

1. Creating our own content 'From scratch' (assuming you mean parameters) - And that's exactly what we've done for the last 5+ years. It's just increasingly aggravating that we've had to deal with this issue for so long, when every advanced revit electrical user I've spoken to has acknowledged that this is without a doubt, the clearest problem with Autodesk's Electrical content.

I have always and will continue to build-in workaround parameters until Autodesk fixes these issues, but as long as the problem is not resolved at the source, it will continue to cause confusion between modelers, designers, and engineers... and will continue to result in wasted time and money for myself and my company.

2. Autodesk's content is only provided as an example - If the Autodesk Electrical content was only provided as an example, there would be a way to remove these parameters. In most cases, Autodesk does provides suggestions and examples on how to build the content, but also allows users to modify the parameters they've provided in the 'examples' - as you call them. With these particular parameters, Autodesk has forcefully decided what's right for the engineers/designers, and won't give them the ability to reverse, hide, or even separately group Autodesk's decisions.

3.  Wrong Forum / This is for user support - If this is not the correct forum on which to post these concerns, I would love to know what is. I have already attempted to contact Autodesk Support directly about this, and I have seen AUGI wishlist items on this problem go unnoticed for years... possibly due to Autodesk's ignorance with regard to electrical. My main intention for this post was not to get a direct response from Autodesk, but instead to revive hopes that a solution will eventually be implemented. My biggest fear, is that Autodesk has not fixed the problem because either 1. they believe their electrical user-base is too small to bother fixing their issues or 2. they genuinely believe it is no longer a problem because of the continual acceptance of solutions that are far-far less than ideal.

Essentially, I feel that the community of Revit Electrical users has been ignored for far too long, and the staggering amount of limitations that we electrical users have to deal with is absurd. So it's not just these 3 parameters that cause us problems... it's also limitations with PanelSchedules, ElectricalSystems, ElectricalConnectors... and all of these have pilled up over the years to a point that seriously causes me to loose hours of sleep at night. I still don't understand why I can't build a PDU family in 2018... when every major electrical firm works on data centers.    

[fabiosato]

Hello,

I would like to suggest you to join the beta tester program, so you can help Autodesk to develop these solutions.

[tino.freitas]

Hi @Anonymous

thank you for the time you took and the level of detail that you have used to present this issue. I did bring it to our development team and they are aware of this and working currently to fix it in future versions. At this point I would also suggest you consider what @fabiosato mentioned in his post and become part of our beta tester program.

I hope this has helped, please remember to 'accept as solution' to help others find answers!

[Anonymous]

Hello Tino,

        Thank you Very Much for bringing this issue to the Development team! As we hear more about Autodesk's efforts to reconnect with the electrical community, my colleagues and I become more and more excited about our future with Revit. Some parts of our company were forced by the rest of the industry to adopt Revit instead of doing so amicably. They continue to use Revit like AutoCad and have failed to transition to a Revit-optimized workflow (3D & Smart) at least partly because of these fairly insignificant (in the grand scheme of things) electrical issues with Revit. These electrical issues have stood for years as the polarizing force between those who openly adopt Revit and those who reluctantly adopt it. I've just reached out to the Autodesk Team with a request to be involved in the Beta and I'm so happy to hear and see the kind of responses we've seen so far!

              Thank You Very Much,

                                     James Kerfoot

Post Script: @fabiosato mentioned that he uses these parameters in reverse, but with means/uses that align with ours. I can't really argue with how he's fitting the parameters to his use-case, however, I think we could all agree that they would benefit from more flexibility and clarity in their definitions/descriptions.

[MuirEng · Accepted solution]

I have no idea how the accepted solution to this can be called a solution but that doesn't matter. I know Autodesk is taking a look at the general subject of hard coded parameter behaviour, but I have an easy hack that pretty much makes the issue go away and it might be generally useful in other cases where you really want a built in parameter to behave in a different way. 

I can't take much credit for this. Martin Schmidt put me on to this post, below. So thanks to Martin for talking to me about it and thanks to Steve for his excellent blog, and thanks to Kurt who wrote to Steve...

Change system parameter from type to instance

I've discovered that the actual process is even simpler than Kurt's method. 

Okay, so here is what you need to do: 

1. edit your favorite panel family

2. change the family category from "electrical equipment" to "data devices" 

3. edit the parameters "MCB Rating" and "MCB Type" and Feed Through Lugs. Make them all instance. (!!!!!)

4. save

5. change the family category back to "electrical equipment"

OMG IT WORKS! THE PARAMETERS STAY DEFINED AS INSTANCE!

This means our firm no longer needs to maintain separate family types for panels MCB and MLO and no longer do we need to create a new type every time we want to reduce the MCB rating below panel ampacity, or introduce feed through lugs. 

I think we will still maintain two panel board schedule templates - one for MLO and one for MCB just to get rid of the MCB rating parameter which cannot be set to "MLO". 

I hope this helps you as much as I believe it will help us. 

[Anonymous]

Thank You Very Much Brian!!!! 

This is amazing! I can't express how grateful I am that you posted this!

I'm about to rebuild our Revit families using this trick.

Just to clarify where Credit is Due:
Publicizing Solution - Brian Muir, Muir Engineering
Further Publicized - Martin Schmidt
Original Poster - Steve Stafford, Revit OpEd Blog
Found Solution - Kurt Thompson

     Thank You Again!

[curtisridenour]

But how does one fix it the other way? I have a built-in parameter "Description" somehow changed into an instance parameter.

• How did this happen? 
• How can you change it since every model category available to change it to has the "Description" parameter?

[ToanDN]

---

@curtisridenour wrote:

But how does one fix it the other way? I have a built-in parameter "Description" somehow changed into an instance parameter.

• How did this happen? 
• How can you change it since every model category available to change it to has the "Description" parameter?

---

Click the Edit button (pencil symbol).

[curtisridenour]

@ToanDN 

[ToanDN]

---

@curtisridenour wrote:

@ToanDN 

---

Which category is that family?

[curtisridenour]

Lighting Device

[curtisridenour]

@ToanDN 

the origin of this family is from CTC I believe. I stripped everything out to figure out how to change parameter back to a type from an instance. I have failed to even with dynamo.

[ToanDN]

Looks like they were changed with CTC specific app, which can dig deeper than the normal interface provides.  Sorry.

[curtisridenour]

Thank you for looking into it. That makes sense. Where did CTC get all this power from? Witchcraft...

[curtisridenour]

@ToanDN 

The CTC app can't do it either.