Jump to content

Solar charge controller issues with Axpert Inverters


Steven67

Recommended Posts

Hi. Im new to the site so please indicate if this has been discussed before. I have 2 x 5KW Axpert King inverters connected in parallel. This is fed by 6 x 3 330W JA Canadian Solar panels (2 banks to the one inverter and one to the other). This charges 2 x 3.5KW Pylontech batteries, which I monitor with the BMS cable from ICC and ICC software.
This setup runs most of the house, including Geyser (on a smart timer for 3 hours a day) and Pool pump, and does so without any trouble. The system also copes with ironing etc.. without any issues.

Problem I have is that in summer by 11am the Geyser is fully heated (2.8KW element), and the 2 pylontech's are fully charged. The power supplied by the solar panels then goes to Zero and the batteries take over. Regardless of the load thereafter, the one inverter with the 2 strings of panels (12) will not use the MPPT to charge the battery again. The only way I can get it to use solar again for other loads is to switch off both inverters and both batteries and doing a full system restart.

It doesn't happen every day, it seems sporadic, unrelated to weather or loads. The sooner the battery bank is full and the supply from the solar gets ramped down the sooner it happens.

I have read through the forum that it is likely an issue with the MPPT of the Axpert inverters, and see many others are experiencing the same issue. I really just want a system that is able to work effectively to its full capacity.

It seems that installing an external SCC / MPPT that is more "advanced" may solve this problem, is this true? Can anyone shed advice on how to go about doing this
Went with the Axperts as they were recommended by the installer, as they blend between grid, battery and solar, starting to regret that choice now though.
 Perhaps a reputable installer that can come have a look at the system - JHB Based.

Any advice will be appreciated, thanks

Link to comment
Share on other sites

17 hours ago, Steven67 said:

This is fed by 6 x 3 330W JA Canadian Solar panels

So your panels are 3S x 330 W. I suspect that may be the problem. When the panels have no load, their voltage increases, possibly exceeding the 145 V maximum, or at least over the 130 V where PV charge power starts to derate (reduce).

When this happens, what is your PV voltage? Perhaps you can pull this information from data logs.

Link to comment
Share on other sites

13 hours ago, Steven67 said:

From the graphs I have pulled Voltage seems within range.

Just barely. In winter these values would be perhaps 10% higher, which would be very close to the absolute max, and well beyond the derating voltage (130 V), and even further beyond the upper MPPT voltage (given as 115 V).

The telling thing is that the PV Volts goes to zero. If the Solar Charge Controller (SCC) was just backing off, I'd expect the PV volts to rise. Going to zero seems to indicate that the SCC is shutting down, presumably to protect itself, though it could be a temperature or other problem.

Can you plot the inverter temperature? If there is only one temperature value, it should be the highest of four values: the SCC, two heatsink values, and the transformer. If the SCC is overheating, presumably you'll see the overall temperature rising past about 55°C (the normal maximum on a hot day), and you should notice the correlation between the temperature and the dips.

Perhaps try this, if it's convenient. Isolate all the strings bar one, and verify that the problem still happens. Then rewire that string to be only 2 panels (bypass one panel by moving one of the PV plugs), and see if the problem goes away. If it does, excessive voltage is your problem, and you'll have to rewire all your panels to be 2S. Don't parallel the 2S string with any of the 3S strings, of course.

Link to comment
Share on other sites

  • 2 months later...

I am running a Axpert King 5k with pylontech one of US3000. Inverter firmware 71.86 and #5 = pyl.

I also had an issue that solar power was limited. What i found is this: The inverter or BMS sets #02, when battery is full or almost full, to 10A. With #16 = SbL UdC #02 will not be allowed to go higher than 10A. With #16 = SLb UdC #02 will go to 30A what in my case allows full PV power comming in.

Link to comment
Share on other sites

1 hour ago, MJS said:

 when battery is full or almost full

So it might be working as intended then? Charge current is reduced to prevent over-charging the PylonTech?

Edit: but is it ignoring load power that it could and should be supplying from solar?

Edited by Coulomb
Link to comment
Share on other sites

I agree, it limits charge current to pylontech but at the same time it limits PV current to 10A. I would consider this a being a firmware error. PV current should be determined by the load and not being capped. i have graphs of showing currents.

#02 is the limit. i agree that a actual current might be well below 10A when battery is almost full

Emoncms - vis multigraph.pdf

Link to comment
Share on other sites

On 2020/01/30 at 12:16 PM, MJS said:

I am running a Axpert King 5k with pylontech one of US3000. Inverter firmware 71.86 and #5 = pyl.

I also had an issue that solar power was limited. What i found is this: The inverter or BMS sets #02, when battery is full or almost full, to 10A. With #16 = SbL UdC #02 will not be allowed to go higher than 10A. With #16 = SLb UdC #02 will go to 30A what in my case allows full PV power comming in.

Today I ran into the same issue although I had #16 = SLb UdC. Pylontech BMS again set #02 = 10A. Only if BATT CHARGE <= 90% BMS sets #02 = 30A. This was the same yesterday so just a coincidence I did not realize and jumped to wrong conclusion.

I wonder if this is an SCC issue? My firmware U1:71.86, U2:20.00, U3:00.21, U4:01.10 .. is there any later version I could flash?

Today:download.thumb.png.9487a61fd84397d7a2d0c50deafbb2fa.png

Yesterday:550510849_download(1).thumb.png.20f0e714ded8e79934f230dcaa834c1e.png

Unfortunately the legend is not in the pics:

green PV_I_BATT, yellow BATT_CHRG, blue BAT_CAP_PERCENT

Link to comment
Share on other sites

7 hours ago, MJS said:

I wonder if this is an SCC issue?

I've been wondering myself.

Quote

My firmware U1:71.86, U2:20.00, U3:00.21, U4:01.10 .. is there any later version I could flash?

The first two are the latest I know of; I've never seen an update for the last two.

 

7 hours ago, MJS said:

Pylontech BMS again set #02 = 10A. Only if BATT CHARGE <= 90% BMS sets #02 = 30A.

So when battery type (setting 05) == PYL, settings such as 02 (maximum charge current) are modified dynamically by the firmware? I thought with battery type PYL you would not even see settings such as 02, they would be all internal.

7 hours ago, MJS said:

Today I ran into the same issue

Actually, your graphs seem normal to me. There is a gap between the yellow and green lines; this represents the load, correct? (The green line sometimes can't keep up of course, depending on solar availability). What exactly do you see as the issue with your graphs? Yesterday from about 12:00 to 13:00 you seemed to have no solar contribution to load; is that the problem? Maybe there was little load.

I wonder if the firmware is internally still working with multiples of 10 A for setting 02. I should go check that; it may be a consequence of sending information compressed over CAN packets. [ Checks... ] Yes, it looks like they're still compressing that setting into 4 bits, dividing the maximum charge current setting by 10 and subtracting one. So 0-F represents 10-160 A. That could well explain some of the annoying behaviour, especially at low load currents.

But wait; one of the new CAN commands (number 27), sends the BMS maximum charge current. I don't know the resolution of this off the top of my head, but it's probably an amp or tenth of an amp. So it seems to me that they have the ability to do precise tracking of the solar power required to cover loads. Maybe some critical part of the code just needs to be changed to use the new CAN information, and through an oversight is still using the old. So there may be hope.

Link to comment
Share on other sites

 

7 hours ago, Coulomb said:

So when battery type (setting 05) == PYL, settings such as 02 (maximum charge current) are modified dynamically by the firmware? I thought with battery type PYL you would not even see settings such as 02, they would be all internal.

Yes #02 is dynamically modified by firmware. Yes, you can see and set #02. It will accept the setting (in my case to 30A) and change inverter's behaviour accordingly (in my case allow higher PV current) but within 5s (guess) it will change #02 again (to 10A)

 

7 hours ago, Coulomb said:

There is a gap between the yellow and green lines; this represents the load, correct?

Correct, green is the PV current, yellow is the battery charge current, difference used for the load.

7 hours ago, Coulomb said:

What exactly do you see as the issue with your graphs?

Zoomed in and load and discharge current added:

1886309102_20200201download.thumb.png.e41466cae990909ec01170d3c22bd3ba.png

10:26 charge current significant drop (no clouds etc.) battery SOC 90%

until 10:46 charge current stays @ 8A; SOC stays at 90% until 10:42, then climbs too 100% at 10:46 

10:46 charge current drops further

So far the only thing I do not understand is that the battery charge does not increase from 10:26 until 10:42. This could be due to BMS and is not critical to me.

The real issue to me is this: At 10:49 I switch on a significant load (about 900W) so total load about 1080W. Now I would expect the PV current to go up to cover the load. Instead the battery starts discharging. At 11:13 I switch on another load (coffee machine). Battery discharge continues. When SOC falls below 90% at 11:20 PV current jumps up to 30A.  I verified that #02 changed form 10A to 30A at that time.

12:04 and later every time SOC >= 90% ==> PV current drops to 10A

12:12 and later very time SOC <90% ==>PV current goes to full (30A)

(Weather conditions have not changed full sunshine no clouds)

So I wonder why PV current is influenced by #02

8 hours ago, Coulomb said:

So there may be hope.

How do you mean? 

Link to comment
Share on other sites

On 2020/02/01 at 7:04 PM, MJS said:

Yes #02 is dynamically modified by firmware. Yes, you can see and set #02. It will accept the setting (in my case to 30A) and change inverter's behaviour accordingly (in my case allow higher PV current) but within 5s (guess) it will change #02 again (to 10A)

Huh. I should go read the code for that. It's a bit tricky because the logic is split between two processors, and I don't know the connection between them yet.

Quote

Zoomed in and load and discharge current added:

10:26 charge current significant drop (no clouds etc.) battery SOC 90%

until 10:46 charge current stays @ 8A;

Would 8 A be all it can provide at that time of day?

Quote

SOC stays at 90% until 10:42, then climbs too 100% at 10:46 

10:46 charge current drops further

 

I agree it's definitely not behaving properly there. The yellow line is reasonable enough, but the green isn't coming up to cover loads. It's as if there was a solar balance setting for Kings, and it's set to OFF. As far as I can tell, there is no solar balance setting. So I'd assume it would behave like a model that does have that setting, but it's set to the default. The default is ON.

Quote

So far the only thing I do not understand is that the battery charge does not increase from 10:26 until 10:42. 

I'd say it's because the state of charge is over 90%; they've decided that 10 A is a safe limit in that situation.

Quote

The real issue to me is this: At 10:49 I switch on a significant load (about 900W) so total load about 1080W. Now I would expect the PV current to go up to cover the load. Instead the battery starts discharging.

Again, I agree that this is not what should be happening.

Quote

 

Quote

So there may be hope.

How do you mean? 

I mean the design of the machine appears to be suitable for solving this issue; at one point I was thinking it was a design fault; not much could be done if that was the case.

But now it appears to me that they have all the tools they need, so it's "only firmware" that needs to be fixed. This could happen.

 

Edited by Coulomb
Link to comment
Share on other sites

18 hours ago, Coulomb said:

Would 8 A be all it can provide at that time of day?

No, it was full sunshine and no clouds so 30A easy possible.

I will report the issue to MECER in Johannesburg and will see what they come up with.

Link to comment
Share on other sites

Hi, 

Your system is running as it should, sometimes #2 will jump to 140A, it do not actually put 140A into the battery.

No matter what your settings are, if you are set to PYL (#5), the system regulate itself. It should not reduce your cycles significantly.

I have seen that when our house is less “busy” it take longer to turn a cycle though. I have not had a cycle turning faster than 24 hours (I however have 4 of those batteries).

I unfortunately have some trouble now with my Pi freezing more often as I am not mobile enough to go and fiddle with it 10x a day :).

I know it seems scary, but just leave those batteries to do what they do. It is normal that when they are 100% that they will discharge a bit and then recharge. If you want, I can go back and plot my system for you to compare. Just keep in mind that I have lost some data due to my Pi deciding to strike.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...