PIP-4048MS and PIP-5048MS inverters

[paulvk]

Now the display of the second parallel inverter with the QPGSn command



So that is two of the commands now to get the rest working and to enable changes to settings with infrared remote control.

[coulomb]

I think we need to keep the semiconductors and capacitors cool in the pips so fitting 120mm fans...

I note that firmware 73.00 runs the existing fans much more aggressively (by a factor of 5/3) when solar charging, though no different when running a large load in battery mode. I believe that this is another change we can thank you for suggesting to the manufacturer; thanks, @Paulvk!

I was initially puzzled at why the fans don't also work harder with a high inverter load. But then I realised that this way, the extra noise would mostly be during the day, when solar charging. The exception to this would be AC charging at night to take advantage of an off-peak power tariff. So most of the extra noise will be during the day when people are usually not sleeping, and when ambient temperature would be highest. I haven't checked to see if the maximum temperature is higher at night than during the day. They do now run the fans at a minimum of 30% speed all the time in 73.00; this is quite quiet and should help keep the night time internal temperatures low. Overall, the new fan control code seems like a good compromise between electronics lifetime and fan noise.

[coulomb]

CONG = freezer 2HP
REF: fridge 1HP

I think problem was when stopped freezer = Overvoltage in AC back to inverters.

Well, 2 HP is nearly 1500 W, so that's quite a large freezer, perhaps ten times the size of a domestic freezer, if I'm not confused. An induction motor draws roughly 7x its continuous power for a fraction of a second when starting up; that's of the order of 10 kW. So starting one or both motors at the same time will be a significant load.

Such a large motor might have a kick like a mule when it turns off, so yes, it could well be due to inductive kickback when the freezer stops. The PIPs do have several surge protectors, but larger ones nearer the loads might be a good idea for this type of load.

I wonder if perhaps one was starting when the other was switching off; this would be a voltage spike while the inverters' IGBTs would be working quite hard. Such a coincidence would be quite rare, of course, but after years of continuous running, it's bound to happen occasionally. [ Edit: it doesn't look like the fridge was "due" to come on in this case, but perhaps the fridge was opened and came on "early". ]

[rinaldoparaipan]

I have discovered a strange think at Effekta AXM 4048:When the inverter is working in by-pass mode, with the AC OUT fuse disconnected(so is no output consumption) the inverter takes 1.2-1.5 Amps from the grid.
I checked with different measuring instruments (AC clapmeter, Am meter in series with live AC input wire, a noninvasive ACS sensor with Arduino board) and the result is the same.
There is no battery charging current (cheked with clapmeter)-the inverter is set on Only SOlar charging mode.
The result of measurements was confirmed by two friends of mine, at an MPP Solar inverter and another Effekta.
When the relay switch to battery mode, there is no more grid consumption.
Would you please check your inverters if they have the same behavior?

[weber]

Hi rinaldoparaipan,

I know that seems like there is about 300 watts going to waste. But if so, the 300 watts of heat would be hard to hide. This is almost certainly mostly reactive power (measured in volt-amps not watts) that is simply charging and discharging a capacitor 100 times a second. Although I'm guessing that maybe 50 watts is actually being wasted as heat.

To find out what is really going on, you need to use a true-RMS power meter that simultaneously samples both voltage and current many times per cycle, or some other instrument like an oscilloscope, that allows you to take into account the relative phase of the voltage and current waveforms. Simply measuring the voltage and current separately, and multiplying them together, does not give the true power.

[rinaldoparaipan]

Yes, I supposed is reactive power and I know that 300W transformed in heat inside inverter's volume should give a high temperature.
The problem is that a lot of electronic power meters installed in Romania are measuring a part of reactive power, even in single-phase grid connection.
You confirmed my assumption.Thanks

[sinux]

Hi @@weber
I've installed the firmware 73.00a on my inverter. Works great! Thanks for all the time spent on this!
I installed it because my batteries were never fully charged with the old firmware (early exit of absorb stage).

I'd like to report a bug/regression :
From version 72.70c beta, you've "improved the accuracy of the battery charge and discharge current readings, particularly for low currents, as displayed on the LCD, and as given in response to the QPIGS and QPGS serial commands"

I've built a small data logger / coulomb counter that runs on raspberry pi. And since the upgrade, my "total wh in" don't match "total wh out" any more (within reasonable margins).

It looks like you've reduced the amount of amps reported by the inverter for battery charging current by 1 amp?

At first glance it seems reasonable to do that because the new figure becomes finally the real battery current, in most cases (see below).

The previous battery current reported (before the upgrade) was actually "battery charge or discharge current" + "self consumption".
This is why the inverter would always report 1 amp even when the battery was in float and full.

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

This has two unintended consequences with the new firmware :
1. The charging/discharging current reported is wrong (which is why my raspberry pi program is wrong)
2. The charger quits charging way too early when charging with 2amps, and quits slightly too early when charging with 10amps.

You should be able to replicate the problem by putting the inverter in bypass mode, AC charging at 2 amps, absorb time 180min. It never stays in absorb mode that long. (see attached picture - last night charging at 10 amps, absorb should be 180min - top red is AC charging)

As I've got a small system (4x 100Ah gel batteries) this is a bit of a problem for me.
Any advice?

[paulvk]

I have two 1Hp pumps running off my inverter but they do not have start capacitors only run capacitors more than a year 4 times a day no problems.

Now an update on LCD remote control:
I have the infrared remote working and any old remote can be used it learns the buttons.
regards Paul

[weber]

Hi @weber
I've installed the firmware 73.00a on my inverter. Works great! Thanks for all the time spent on this!
I installed it because my batteries were never fully charged with the old firmware (early exit of absorb stage).

Thanks for the kind words. I note that I didn't have much to do with finding and fixing the premature float bug. That was coulomb. But I am responsibile for the changes to current reporting that you are having a problem with.

I'd like to report a bug/regression :
From version 72.70c beta, you've "improved the accuracy of the battery charge and discharge current readings, particularly for low currents, as displayed on the LCD, and as given in response to the QPIGS and QPGS serial commands"

I've built a small data logger / coulomb counter that runs on raspberry pi. And since the upgrade, my "total wh in" don't match "total wh out" any more (within reasonable margins).

Thank you for such a detailed report. So that's Wh in and out of the battery? Particularly with a lead-acid battery, I'd expect Wh in to be 5% to 15% greater than Wh out. Also, the resolution of current measurement by the PIP is only 1 amp. Not really good enough for coulomb counting. How much do they differ, and in what direction?

It looks like you've reduced the amount of amps reported by the inverter for battery charging current by 1 amp?

That is correct. And when the battery is not being charged, we've also increased the amount of amps reported by the inverter for battery discharging current by 1 amp.

From the Dynamic Current Control manual:

"The inverter does not have a current shunt, or any other means of measuring battery current. The standard inverter firmware estimates battery current by measuring AC power and applying a simple efficiency scale factor for inverting (100/108), and another for AC charging (119/128). It completely ignores the no-load and no-charge losses."

"We improve the accuracy of low readings by the simple expedient of subtracting 1 amp from the charge current reading if it wasn't already zero, otherwise adding 1 amp to the discharge current reading."

At first glance it seems reasonable to do that because the new figure becomes finally the real battery current, in most cases (see below).

Thanks for confirming that.

The previous battery current reported (before the upgrade) was actually "battery charge or discharge current" + "self consumption".
This is why the inverter would always report 1 amp even when the battery was in float and full.

Right.

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

I think we tested it with AC charging and found approximately 50 W losses there too. But we will check this.

This has two unintended consequences with the new firmware :
1. The charging/discharging current reported is wrong (which is why my raspberry pi program is wrong)
2. The charger quits charging way too early when charging with 2amps, and quits slightly too early when charging with 10amps.

You should be able to replicate the problem by putting the inverter in bypass mode, AC charging at 2 amps, absorb time 180min. It never stays in absorb mode that long. (see attached picture - last night charging at 10 amps, absorb should be 180min - top red is AC charging)

As I've got a small system (4x 100Ah gel batteries) this is a bit of a problem for me.
Any advice?

I can see that would be a problem. We will investigate, and we may produce a version 73.00b to fix the problem.

[coulomb]

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

Sinux, I see that you are from South Africa. For whatever reason, there seem to be a lot of older models in use there, which probably have the AC/utility power supply still fitted. That might explain why at least some of the inverter losses transfer to the AC input instead of the battery, when AC charging. The AC power supply, if present, would take over powering the processor, LC Display, relays, gate drivers, and other electronics. Later models omit this power supply altogether, so these losses stay with the battery.

Does your inverter have the black heat-sink on top, like this one?

Top heatsink.jpg (15.41 KiB) Viewed 1443 times

[ Edit: I no longer believe that the presence or absence of the utility power supply could explain what appears to be a difference in required correction depending on whether the PIP is in battery or line (bypass) modes. The power that this power supply handles is likely to be much less than 50 W, and in any case it would be present while the AC input is present, i.e. in both battery and line modes. ]

Don't go to any trouble, but perhaps you remember if it is possible to power up your inverter without the battery connected, but AC input present?

[rezydent]

For me transistors broke down and I exchanged them on CSD19535KCS and IRFB3077PbF
Whether exist possibility of amending of stretching charging the battery to 64 VDC?
Do you know how it would be possible to do it?

[weber]

We've just updated the 73.00a patched firmware to "release" status, here:
viewtopic.php?p=66664#p66664
The only thing we've changed is the version letter that indicates it's now a release version.

[weber]

For me transistors broke down and I exchanged them on CSD19535KCS and IRFB3077PbF
Whether exist possibility of amending of stretching charging the battery to 64 VDC?
Do you know how it would be possible to do it?

Hi rezydent. No, it is not possible to increase the charging voltage to 64 volts merely by a firmware change, because the capacitors, MOSFETs and IGBTs are already operating close to their rated voltages. This includes the high-voltage DC bus capacitors which have a 500 V rating and would be operating at 512 V if the battery was at 64 V, due to the 8:1 ratio of the DC-DC converter stage.

[coulomb]

I don't know exactly why, but there's an exception to this case, when in bypass mode and charging with AC.
In this state, the battery charging current doesn't include self consumption (or maybe more logically the self consumption is much less than the average 50W in solar charging mode with inverter on).

There are two current sensors in the PIPs. One is a LEM branded Hall effect sensor, that appears to be at the output of the DC-AC inverter. It seems to be a DC sensor so that it can detect excessive DC in the AC output (there is a fault code for this condition). The other current sensor is a current transformer, apparently measuring load (AC output) current. So the battery current is inferred, not measured directly.

When inverting, the battery current is inferred from the inverter load power less any solar charging power, so the losses are not counted, and are supplied by the battery.
When AC charging, the battery current is inferred from the AC charger (inverter working in reverse), and counts losses as if they go into the battery, but they don't.

In both cases, the current into the battery is actually about one amp less than the PIP indicates, hence Weber's corrections. On my PIP, the battery current corresponds well with the actual measured battery current after these corrections.

Note that the changes are only to displayed or reported values, so charging, including the time spent in absorb mode, should not be affected.

I've retracted my theory about the presence of the utility power supply possibly causing different results to be reported by the older models.

This has two unintended consequences with the new firmware :
1. The charging/discharging current reported is wrong (which is why my raspberry pi program is wrong)

As indicated above, I don't see why it would be worse with the corrections. If it really is happening, you could perhaps take into consideration that the PIP is in bypass mode, and uncorrect the correction. But it still would not be nearly accurate enough for coulomb counting.

2. The charger quits charging way too early when charging with 2amps, and quits slightly too early when charging with 10amps.

You should be able to replicate the problem by putting the inverter in bypass mode, AC charging at 2 amps, absorb time 180min. It never stays in absorb mode that long. (see attached picture - last night charging at 10 amps, absorb should be 180min - top red is AC charging)

I tried this, and as expected when the current limit was 2 A, the reported current was either 0 or 1 A. The charger remained in bulk/absorb mode, as indicated by the flashing CHG LED. So I can't replicate your problem. I don't understand why you seem to imply that the problem would be seen quicker with the current limit at 2 A compared to 10 A. [ Edit: my testing was with only one machine turned on; if I had both machines turned on, I now believe I would have replicated your problem. See this discussion of the two amp per active paralleled machine threshold. ]

Is it possible that your Raspberry pi software is assuming that absorb mode ends as soon as the reported current is zero?

[sinux]

Thanks for the kind words. I note that I didn't have much to do with finding and fixing the premature float bug. That was coulomb. But I am responsibile for the changes to current reporting that you are having a problem with.

Sorry I forgot to mention Coulomb! Thanks to all! and thanks for the kind reply.

I don't quite know where to start...
Yes I'm in South Africa, my model was manufactured in 08.2015. It doesn't have the top black bar (see pictures attached).

I'm mostly happy with the new display of the battery current it's much more realistic (although I would say a tad too pessimistic - full sunshine with load at 50% solar output, battery floating, it often displays -1Amp for a brief moment - the battery voltage doesn't change so I guess it's just rounding).

What bugs me most, is that the battery amps reported by QPIGS is now changed. For continuity/compatibility reasons it would have been nice to keep it consistent. I understand that you want it this way for dynamic current control. Wouldn't it be possible though to detect the use of dynamic current control function and only change the response to QPIGS if it's in use?

If it's not possible, I'll change my software. Just trying to think about other people who also have developed programs like that.

I'm all too well aware that the battery current resolution is insufficient for coulomb counting. However, this only affects when charging with AC (at night in my case). During the day, the solar power reported is accurate enough and I use those values. All I'm trying to do is have a general idea of the state of the battery during the day (the counter gets reset every night when the battery is full).

I was also expecting about 10% more Wh in than Wh out. But that's not the result I'm getting...
But that's a different matter, maybe we can chat about coulomb counting using only data provided by qpigs later.
Since the firmware update there's always more Wh out than Wh in (but that's because self-consumption is now remove from Wh in)

(this is to reply to Coulomb above) Now regarding the charging current on AC, I don't have the tools to measure it directly. I did a small experiment using my utility prepaid electricity meter (the assumption is that it's accurate...) :
Starting conditions : inverter in bypass mode, solar panels disconnected, charging with AC at 2amps.

Start at 09:23 am, the meter indicates 42.50 kWh remaining
The data logger indicates that I've used 0.978 kWh already that day (this value is the sum of all AC output power from Qpigs command times delta T)
Bat voltage 51.9V (remains constant during the test)
Stop at 11:10 am, the meter indicates 42.00 kWh remaining
The data logger indicates that I've used 1.223 kWh that day

This means that in 1.78h I've used 0.5kWh from the utility. Out of which 0.245kWh (1.223-0.978) were household consumption.

This leaves 255Wh for charging and self consumption (500-245).
If the battery is charging at 2amps this is 185Wh (51.9*2*1.78) and that means self consumption was 70Wh that's 39W (70/1.78)
Which is expected.
To me that means that when you charge the battery at 2Amps with AC, this is the actual current that goes into the battery ! Somehow the charger requests more power to compensate for self-consumption.
As you state during that time the current reported varies between 0 and 1 A. Which is wrong (if I didn't make a mistake above ).
See the plots attached.

I hope this clarifies the problem.
Thanks for taking the time to help!

PS: I don't seem to be able to attach pictures anymore...

[sinux]

Then I'll link the picture :

[sinux]

Sorry I forgot to reply to some of your questions :

Don't go to any trouble, but perhaps you remember if it is possible to power up your inverter without the battery connected, but AC input present?

No It's not possible to power my inverter without the battery connected.

Is it possible that your Raspberry pi software is assuming that absorb mode ends as soon as the reported current is zero?

My raspberry software doesn't assume anything in this way (it's not that clever). I just manually look at when the battery voltage reaches 57.6V.
That's my start of absorb. And then when voltage drops to 54.4V that's the stop of absorb, if I'm not mistaken.
The setting in the inverter is set to 180min (by me, just to test it).
But the measured absorb time as described above is always shorter.

For example see last night's charging at 10 Amps from AC (absorb timer set at 180min).

[rezydent]

Hi rezydent. No, it is not possible to increase the charging voltage to 64 volts merely by a firmware change, because the capacitors, MOSFETs and IGBTs are already operating close to their rated voltages. This includes the high-voltage DC bus capacitors which have a 500 V rating and would be operating at 512 V if the battery was at 64 V, due to the 8:1 ratio of the DC-DC converter stage.

Ok, of it I didn't know that ratio 8:1 was working of DC-DC converter. But to 60 V it is possible so that it is to hurry him up? It would be for me some solving a problem with my batteries.

[weber]

Ok, of it I didn't know that ratio 8:1 was working of DC-DC converter. But to 60 V it is possible so that it is to hurry him up? It would be for me some solving a problem with my batteries.

Hi rezydent. What is the problem you are having with your batteries? There may be a better way to fix it. What kind of batteries are they? What is the version of the main firmware in your inverter?

[sinux]

So I can't replicate your problem. I don't understand why you seem to imply that the problem would be seen quicker with the current limit at 2 A compared to 10 A.

Please see the comparison of charging at 10 amps vs charging at 2 amps below.



Absorb should in theory be 180min in both cases (as this is set on the inverter).
Absorb time at 2 amps : 16 min
Absorb time at 10 amps : 60 min

What I meant (sorry if I wasn't clear) is that the less amps you charge the battery with, the shorter the absorb time.
I've been struggling for 2 years to charge my batteries.
6 months ago, I realised that if I was charging them at 20amps, they were getting fuller than if I was charging at 10amps.
But that didn't make any sense to me!
Now if the absorb time is too short, that could be an explanation.

I've got a very small system and most people have more batteries and solar panels than me, so the problem wouldn't be obvious to them.
Sorry for the long posts. I hope this clarifies things a bit. Thanks for your help!

PS: I should note that before using your custom firmware, setting 32 didn't exist on my inverter. I don't know if maybe that specific model is lacking some hardware to count the time spent in absorb (RTC, etc...) ?

[rezydent]

Hi rezydent. What is the problem you are having with your batteries? There may be a better way to fix it. What kind of batteries are they? What is the version of the main firmware in your inverter?

My batteries are mine cadmium nickel with KOH electrolyte 48 cell x 150Ah
2NiOOH + Cd + 2H2O ↔ 2Ni(OH)2 + Cd(OH)2
type KPL , see in documentation

Code: Select all

https://www.google.pl/url?q=http://www.amcosaft.com/sites/default/files/document_repo/AMCO%2520Saft%2520KP%2520Range_final%2520web_0.pdf&sa=U&ved=0ahUKEwiF6u7G6I7aAhUHEiwKHS2lCFYQFggUMAA&usg=AOvVaw0qB3AnngFa4Q2isl25q5V0

[weber]

Hi rezydent. You can't use 48 of those cells in series, with the PIP-4048MS inverter. I calculate that 36 in series would be the best choice. In that case you would set the absorb voltage to its maximum of 58.4 V, the cutoff voltage to its minimum of 40 V, and the float voltage to 50.8 V.

You should also install our patched firmware that fixes the premature-float bug.

[paulvk]

My batteries are mine cadmium nickel with KOH electrolyte 48 cell x 150Ah

They will need a different charging process to the lead acid I do not think the inverters will do it correctly see below:
Charging Flooded Nickel-cadmium Batteries. Flooded NiCd is charged with a constant voltage to about 1.55V/cell. The current is then reduced to 0.1C and the charge continues until 1.55V/cell is reached again. At this point, a trickle charge is applied and the voltage is allowed to float freely.

[rezydent]

in this moment I have an adjusted maximal value of stretching loading, it results from observation that the inverter is charging the battery of batteries up for me up to the 75-77% of the nominal capacity, through about 5 hours of loading. I have an additional rectifier charging these batteries up to the 95% of the nominal capacity of course. I simply thought that he would manage to modify this inverter so that he loads with high voltage, but I can see that it isn't possible this way. A curtailment of cell remains for the battery.

[al76]

Is it worth following this up with mpp solar or move fwd with buying another unit and have this unit repaired in Aus? I was planning on a parallel system plus I will be needing a second independent system soon anyway.

I can't really advise you on such decisions. Except to say that I don't see that you have anything to lose by raising the problem with MPP Solar.

How long has the PIP-4048MS been in use? Could there be a fault in the isolation device between your PV array and the PIP?

I'm assuming the isolation device between the PV array and PIP is the large switch?

Any way I've been limping along with this situation where the solar charging starts from approx 9:30-11:30am on most sunny days all the while the pips relays click away. Except 1 day last week which was cloudy and the solar charging started at 7:30am.
This morning I woke up to a dead pip4048ms. Checked batterys, fired up geny. No hint of life. I've ordered a replacement unit this morning.
The unit was purchased Dec 2016.