ETAP/SKM Modeling of Allen-Bradley 140G Series Circuit Breakers with ETUs

Status
Not open for further replies.

HenriEE

Member
Location
Metairie, LA, USA
Occupation
Electrical Engineer
I am having issues with the modeling of Allen-Bradley 140G Series molded case circuit breakers (MCCBs) with electronic trip units (ETUs) in SKM and ETAP software. The issues are with the maximum clearing times of these devices in the fault current region, which is extremely important since it affects arc flash calculations and protective relay coordination.

The Allen-Bradley documentation is unclear and contains contradictions. Also SKM and ETAP disagree on the maximum clearing times of this equipment in the instantaneous and hardware override regions. Here are some facts.
  1. For a 140G-M with LSI trip unit, ETAP assumes the maximum clearing time is 60ms in the instantaneous region, but only 10ms in the hardware override region.
  2. For the same device with same settings, SKM assumes the maximum clearing time is 60ms in both the instantaneous region and in the hardware override region.
  3. Rockwell (Allen-Bradley) publication 140G-SG001E-EN-P contains a TCC that shows a maximum clearing time of 30ms in the instantaneous region. The clearing time in the hardware override region is not clear. I sent a clarification request to them about this.
  4. Rockwell (Allen-Bradley) Support Knowledgebase Center Post QA26552 published on 2/14/2020 states that "all 140G/140MG Circuit Breaker frames will clear a fault in 30ms (2 cycles) or less". 30ms and 2-cycles are not the same thing, especially if you are at 50Hz. I've sent a clarification request to them about this.
  5. The same issues exist with Allen-Bradley 140G-K and 140G-N devices. However Allen-Bradley documentation is inconsistent for these, showing different instantaneous region maximum clearing times of 20ms and 40ms instead of 30ms, which contradicts their QA26552. I've sent a clarification request to them about this.
I have been in communications with Rockwell (Allen-Bradley) about this, and I'm having difficulty getting the answers I need. I've been in communications with ETAP, and they insist that their modeling is correct. I am awaiting a response from SKM about this.

Has anyone else had to model Allen-Bradley 140G Series devices in ETAP/SKM software and run into this issue?

Most users of SKM/ETAP software will automatically assume that modeling of protective relay devices is done correctly by the software. I've been guilty of that myself in the past. I noticed the issues described in this post while working on a project to convert a large and complex SKM model to ETAP and noticing that arc flash calculations were very different between SKM and ETAP.
 
Last edited:
I received a ruling from Rockwell Allen-Bradley product engineering in Milwaukee, WI. The correct clearing times of the 140G-K, 140G-M and 140G-N with LSI trip units are:

Instantaneous Region:
All 3 have a 60ms clearing time.

Over-Ride Region:
The 140G-K & 140G-M have a 11ms clearing time.
The 140G-N has a 5.5ms clearing time.

In the over-ride region, SKM was considerably off, using 60ms instead of 11ms. ETAP was only marginally off, using 10ms instead of 11ms (or 5.5ms). Also, for unknown reasons, SKM erroneously used a different clearing time of 30ms when instantaneous tripping is disabled.

This information has been passed on to SKM, ETAP and EasyPower technical support, so that they can update their library files.
 
Those are some pretty specific numbers. I would be curious what the actual operating parameters are after the equipment has been shipped, installed and operating for several years. They every pull devices from the field and retest them?
 
The 11ms is 10ms plus a 10% tolerance, and the 5.5ms is 5ms plus a 10% tolerance. That's why those numbers look strangely specific. They are absolute maximum clearing times that account for tolerances.

Software companies like ETAP, SKM & EasyPower have to rely on manufacturer's data when they model devices like this. They don't do testing of devices themselves and neither do consulting engineers. We use the manufacturer's provided data. The problem in this case is that the manufacturer's data was unclear and contradictory, and different people interpreted it in different ways.

I discovered this problem only because I was doing a SKM to ETAP conversion and had to compare results. If I was working just in SKM or just in ETAP, I most likely would have trusted that the software was modeling the devices correctly and not questioned it if the results looked reasonable.

Devices already in service should continue to operate within tolerances, unless they are damaged. I doubt if Rockwell would pull devices from the field and test them, but I'll ask them nonetheless. It has been difficult to get answers from them.

I recently learned that these Allen-Bradley 140G series devices are actually ABB equipment that has been re-branded by Rockwell as Allen-Bradley equipment. You would think that Rockwell would pass on the ABB data, but they don't. They created their own documents.
 
If I was doing this I would need to be convinced that this level of specificity is (1) warranted for the application and (2) actually accurate as to the conditions of operation over time. Maybe I'm a skeptic, but I would err on the side of caution. I find it hard to believe that AB has this info accurately defined for a broad range of equipment down to 1/3 of a cycle tolerance.
 
If I was doing this I would need to be convinced that this level of specificity is (1) warranted for the application and (2) actually accurate as to the conditions of operation over time. Maybe I'm a skeptic, but I would err on the side of caution. I find it hard to believe that AB has this info accurately defined for a broad range of equipment down to 1/3 of a cycle tolerance.
I think it is quite possible with digital trip units. I doubt it can be anywhere near that with t/m trip units.
 
I'm a skeptic as well, and that's why I've been investigating this and trying to find other people who might have encountered this same issue before.

Those fast tripping times are only in the hardware over-ride region of those devices, and they do in fact operate in less than 1-cycle in that very high current region. This can be seen on TCCs that Rockwell publishes, and this has been confirmed by Rockwell. Those high currents operate the devices very rapidly. The 10% tolerance adds an error margin to give a maximum clearing time value.
 
Those are some pretty specific numbers. I would be curious what the actual operating parameters are after the equipment has been shipped, installed and operating for several years. They every pull devices from the field and retest them?

It’s an electronic trip unit triggering a coil. So the trip unit time should not change or it fails outright. That leaves the mechanism. That part is highly dependent on lubrication issues. This is always the problem area. Realistically on small MCCBs though I’ve rarely found issues mechanically until we get way past expected service life. Lubrication issues are consistently a problem in ANSI style breakers by nature.
 
Keep in mind 60 ms would be the case where the breaker is powered off then powered on into a fault. So the microprocessor has to boot, start collecting data, then fire the trip relay. Hardware override is a magnetic trip unit so you are seeing a quarter cycle to reach fault level current (4 ms at 60 Hz) then roughly a half cycle to actually mechanically move and interrupt current (8 ms) to arrive at that 10-12 ms figure. Plus aren’t these for motor circuits? If so we would want to delay 1-2 cycles to allow motor inrush in IEC motors (not locked rotor) to pass.
 
The 140G Series is for feeders, and the 140MG Series is for motors. They both will have the fast hardware over-ride trip, which as you stated, is magnetic and not electronically operated through a microprocessor.
 
The 140G Series is for feeders, and the 140MG Series is for motors. They both will have the fast hardware over-ride trip, which as you stated, is magnetic and not electronically operated through a microprocessor.

So you would probably normally require 1/4-1 cycle to recognize a fault. This all depends on if the software is looking at RMS current thus 1 cycle sometimes 2, or if it has a nonlinear type of fast recognition algorithm that typically operates at fuse speeds (1/4 to 1/2 cycle). Then again a half cycle actual trip cycle. So the remaining 30-40 ms is all microprocessor power up and boot up time. If you are already powered up this extra time probably disappears but you are looking at worst case numbers. Few manufacturers publish or admit to boot times that clearly exist.
 
Status
Not open for further replies.
Top