External Batteries count setting

[BillP]

Last Friday we had a power outage. My Smart-UPS RT 1500 with 2 additional external battery packs(SURTA48RMXLBP2U) running at about 60% load with between 6 and 7 amps of load only lasted 10 minutes.

My Smart-UPS RT 2200 with the same number of additional battery packs on the other side of the room with about 45% load went the full 58 minutes of the power failure.

I went into the web management on the network card and noticed that the setting called (External Batteries) was set to 1 and the run time estimate was 16 minutes.

The 2200 has this set to 3.

I have looked into this setting in the past more than once and can't imagine that I left this set wrong.

Using the information at this page: http://www.apc.com/us/en/faqs/FA156601/ My UPSes count their internal battery as an external one in contradiction to the online help, the English language and common sense. IMHO This should be considered a bug and fixed. I digress.

So I have 3 questions.

Can this setting be the reason for the short runtime? I thought it just used battery voltage once the power failed, or do I have something more serious wrong?

Could the setting have reset to 1 when I had it set to 2 or 3?

Is a battery calibration invalidated if I change this number? I calibrated the 2200 with it set at 2. I will calibrate the 1500 this weekend.

Thanks

[BillP]

Hi Brian,

I just wanted to share what I know..

I don't know why this was done and I also think it is a little silly but here is how the battery pack stuff works:

SURTA1500XL/SURTA2000XL:
Defines the number of connected battery packs for proper run time prediction.
1 = internal battery module,
2 = one SURTA48XLBP or SURTA48XLBPJ,
3 = two SURTA48XLBP or SURTA48XLBPJ,
etc. 

SURTA3000XL:
Defines the number of connected battery packs for proper run time prediction.
1 = internal battery module,
2 = one SURT192XLBP or SURT192XLBPJ,
3 = two SURT192XLBP or SURT192XLBPJ, etc. 

SURTD3000XLT and SURTD5000XLT:
Defines the number of connected battery packs for proper run time prediction.
1 = one SURT192XLBP or SURT192XLBPJ,
2 = two SURT192XLBP or SURT192XLBPJ, etc. 

SURT3000XLT and SURT5000XLT (non Ds), SURT6000XLT, SURT8000XLT, SURT10000XLT:
Defines the number of connected battery packs for proper run time prediction.
1 = internal battery module,
2 = one SURT192XLBP or SURT192XLBPJ,
3 = two SURT192XLBP or SURT192XLBPJ, etc.

Since the runtime estimate you see is just an estimate (or prediction as the above says), I do not believe having this count set incorrectly is a problem. The only time I think it may be is if you have software settings that trigger a shutdown based on runtime. But even then, I was under the impression the time would update as it goes but that may not be the case on every single model listed above.

Since it sounds like you have a Network Management Card, do you see anything in the log files?  You can share them here (http://www.apc.com/us/en/faqs/FA156131) by following these instructions. I am not sure what model of management card it is but a .tar is preferable or config.ini, data.txt, and event.txt with a general time frame to check for when this occurred. 

Do you also have PowerChute Network Shutdown installed on any attached equipment? That is another place to check.

The only time I think this value could get reset is if you reset the UPS to defaults (an option through the management card). I have never seen it reset on its own. I am thinking at this time this value is set on the UPS itself and not the NMC but I'd have to double check to be absolutely sure because I know you can set it via other means.

I think if you do a calibration first then change this value, the NMC is just updating it by a standard amount, knowing the model and how much runtime an extra battery pack provides. How old are the UPS batteries in the UPS and the pack? I would not do many calibrations, especially if the batteries are not too new. A power outage ultimately is supported to accomplish this to update that runtime estimate. If you do do another calibration, I'd ideally do it manually if at all possible (instead of issuing the calibration via the NMC). Instructions and general considerations for runtime calibrations are here: http://www.apc.com/us/en/faqs/FA284198

Hope this helps. In summary, we can take a look at your logs/settings go from there to see if we can figure out what occurred and why there is a difference.

[BillP]

When I updated the firmware it cleared the logs. I went through them and it seemed to be that it only lasted 10 minutes.

I did have a system hooked to the serial port in addition to the NMC. This is apparently unsupported. Once I updated the firmware of the NMC it would refuse to work until I unplugged the serial cable.

I can ask my Unix admin to check his logs and see if the Unix box told the ups to shutdown via the serial cable. That does not make a lot of sense because that cuts the power to the unix server. The unix server is legacy and does not support Network shutdown.

I do have PowerChute network shutdown installed on a few machines. I plan on doing a calibration and see how long it goes.

If it still just goes 10 minutes then I probably have a bad battery or connection somewhere in the packs. It does not lend itself to troubleshooting that issue. I would just replace the whole thing, but it is a bit pricey for that.

If it goes for the 90+ minutes I would expect then I will find the PowerChute logs and look for clues there.

Thanks for the information.

I will open another thread about how to deal with the lack of network shutdown.

[BillP]

Hi Brian,

Just adding a few more comments from my side..

On 11/27/2017 5:27 PM, Brian said:

When I updated the firmware it cleared the logs. I went through them and it seemed to be that it only lasted 10 minutes.

I was thinking, did you see any events like battery discharged, starting a shutdown, etc along with the actual on battery events.

On 11/27/2017 5:27 PM, Brian said:

I did have a system hooked to the serial port in addition to the NMC. This is apparently unsupported. Once I updated the firmware of the NMC it would refuse to work until I unplugged the serial cable.

Yes it is. On your model of UPS, the design of the communication bus is like a chain. Having a serial cable and NMC, which ultimately are on the same chain/bus causes a problem. You can get it to work sometimes depending on order you connect things and playing around but as you found after NMC reboot, it is not a sustainable set up long term. (Newer UPSs have a different design. While it is still not recommended or supported, there are less problems.)

On 11/27/2017 5:27 PM, Brian said:

I can ask my Unix admin to check his logs and see if the Unix box told the ups to shutdown via the serial cable. That does not make a lot of sense because that cuts the power to the unix server. The unix server is legacy and does not support Network shutdown.

OK. Yes, I've seen random signals come from dangling serial cables or those connected but not running software. I don't think it is the problem at this time based on the low runtime estimate issue but can't be absolutely sure.

On 11/27/2017 5:27 PM, Brian said:

I do have PowerChute network shutdown installed on a few machines. I plan on doing a calibration and see how long it goes.

If it still just goes 10 minutes then I probably have a bad battery or connection somewhere in the packs. It does not lend itself to troubleshooting that issue. I would just replace the whole thing, but it is a bit pricey for that.

If it goes for the 90+ minutes I would expect then I will find the PowerChute logs and look for clues there.

Totally agree with your logic and conclusion as you stated above.

[BillP]

My unix admin notified me that yes, his box is set to power down the UPS to save the battery power for itself. This is not really compatible with a shared UPS. It has the added benefit that the server will power back on when the UPS powers back up so the server is as available as possible without human interaction. We don't need that on those servers. This policy was set 20 years ago when the unix boxes were alone.

I will have to get the unix servers their own UPS, or accelerate moving them to virtual machines.

Other work arounds are to increase the time till the server tells the UPS to shutdown, or have it only do so when the low battery alert starts.

[BillP · Accepted solution]

Brian, are these the original batteries of the UPS or did you replace them recently or a few years ago? We had similar problems and usually the setting on the General for battery packs are calculated values. We also suspected that the batteries are of age and needed to replace them as well as check the connector from the extended frame is connecting correctly to the main unit. 

When replacing them you may have to do a run-time calibration for the unit to re-establish a new run-time threshold.