Independent Conduit Support

Status
Not open for further replies.
C

cvirgil467

Senior Member
Location
NewYork
Does the NEC 2012 (or prior editions) require independent conduit support from other systems, such as duct hangers, pipe hangers, and other similar systems? I though a seperate independent system was required but cannot locate any such requirement in Article 300.

Thanks.
c
 
300.11 only requires that they be "securely fastened in place" and prohibits supporting on raceway from another.
 
ActionDave said:
And that sums it up quite well.
Click to expand...

Lets just say in general you can not support other systems from the electrical system, so it is probably not such a good idea to support the electrical system from other systems either.

Those other systems may actually have an associated code that prohibits them from supporting other systems too.
 
kwired said:
Lets just say in general you can not support other systems from the electrical system, so it is probably not such a good idea to support the electrical system from other systems either.

Those other systems may actually have an associated code that prohibits them from supporting other systems too.
Click to expand...
I won't strap my conduit runs to a HVAC duct, but if the HVAC dudes build a unistrut rack to support their duck I have no problem strapping conduit to it.
 
ActionDave said:
I won't strap my conduit runs to a HVAC duct, but if the HVAC dudes build a unistrut rack to support their duck I have no problem strapping conduit to it.
Click to expand...

Same here, exception may be supporting a wiring method from duct that runs to a device associated with the duct, like a damper, pressure sensor, booster fan, etc.
 
What is the reason against using conduits in the same system for supporting other conduits (think back to back mineralaks)?

If the original conduit is supported securely, I don't see how piggy-backing that support has any downside consequences.
 
Stevareno said:
What is the reason against using conduits in the same system for supporting other conduits (think back to back mineralaks)?

If the original conduit is supported securely, I don't see how piggy-backing that support has any downside consequences.
Click to expand...
Do you see any downside if you supported twenty runs of conduit from one?

What if in the future you have to remove the supporting conduit?
 
Smart $ said:
Do you see any downside if you supported twenty runs of conduit from one?

What if in the future you have to remove the supporting conduit?
Click to expand...

What if the structural member supporting all twenty-one conduits runs gets removed for some reason? "What if" doesn't cut it, if it did we may as well give up because nothing we do will be right.
 
I will say that when you create a rack or kindorf support you will have to consider the weight that you will apply to it, that will be part of your calculation, now what about if after you did you task correctly a buddy from the plumbing trade use you rack and create a over weight in your supports, who will be responsible for it? plumbers or electricians?
 
Smart $ said:
Do you see any downside if you supported twenty runs of conduit from one?

What if in the future you have to remove the supporting conduit?
Click to expand...

...'what if' is a design issue, not covered by the NEC (or a least they claim).
 
jusme123 said:
...'what if' is a design issue, not covered by the NEC (or a least they claim).
Click to expand...
Enough already. "What if" scenarios are instilled into the very foundation of NEC intent. Many of the requirements are there just for the purpose of preventing "what if" scenarios. Whether a method is safe or unsafe is many times a result of "what if" analysis. Just becausse a scenario isn't fully detailed in the NEC itself doesn't mean those scenarios haven't been considered when the requirement was implemented. The question I replied to went to intent, not compliance, and therefore opened the door to "what if" scenarios.

So rather than wasting time bashing others' posts, make use of your time and offer something beneficial... :thumbsup:
 
Smart $ said:
Enough already. "What if" scenarios are instilled into the very foundation of NEC intent. Many of the requirements are there just for the purpose of preventing "what if" scenarios. Whether a method is safe or unsafe is many times a result of "what if" analysis. Just becausse a scenario isn't fully detailed in the NEC itself doesn't mean those scenarios haven't been considered when the requirement was implemented. The question I replied to went to intent, not compliance, and therefore opened the door to "what if" scenarios.

So rather than wasting time bashing others' posts, make use of your time and offer something beneficial... :thumbsup:
Click to expand...

I agree there are many code requirements that are there because of "what if".

I think the degree of probability, or the potential hazard involved has a lot to do with just exactly which "what if's" we need to give more attention to.

I also believe you can not successfully address every possible "what if" as there is an infinite number of "what if's" available.
 
Status
Not open for further replies.
Top