Axpert constant mode changing?

[OomD]

Hi guys, hoping you knowledgable guys can shed some light...

 

When I started with the Axpert it was with only 2x280W PVs in series, thus about 66V or so going to the Axpert. I have setting 1 set to SOL. About 2 weeks ago, I replaced my 2x280W PVs with 6x300W PVs, configured as 2 strings (each with 3 PVs in series) in parallel (thus about 100V PV feed). Since then, whenever the sun rises or falls the axpert changes from PV to line mode a few times (instead of just once), guessing about 10 - 20 seconds between each change.

 

To my engineering mind it seems the PV voltage goes up, but as soon as it is loaded (axpert starts using it) the voltage falls below a threshold, so axpert stops using it, causing the (now unloaded) voltages to go up again, etc.

 

Anyway, while I can understand what causes this (although I have not monitored the voltage with a multimeter to observe this fluctuation) I was wondering if this behaviour of the axpert is normal? It never did this when I had only 2 PVs in series feeding it, leading me to believe the threshold voltage must lie somewhere near the 66V that 2 PV's give you. The fluctuation of 2 PVs is thus outside the hysteresis programmed into the axpert.

 

So:

 

1. Is this normal with 3 PVs in series? 

2. Can the threshold voltages be adjusted by some comms command? There's no setting in the manual for this, but maybe an undocumented one someone knows about?

3. Is there any other way of stopping this behaviour (if indeed it is normal) other than disabling the beeper so it stops bothering me?

 

Hoping you axpert experts can help!

[Arandoza]

Which Axpert model ? As one has to consider the Mppt specs for the various models when planning your solar strings etc. The 5 Kva unit is the only one that seems to be capable of around 3000 watt input from solar, the smaller units a max of 600watts solar?

Also would be good to know the specs of panels as well.

[Arandoza]

On the 5kva unit 4 strings of 3 X 250 watt panels is most you can go.

Ideally you want the voltage range from the panels to be close to the 64v mark, for best performance and not exceeding 115v otherwise you risk damaging the Mppt

[OomD]

Hi, thanks Arandoza. I have the 5KVA axpert. As said earluer, I have 6x300W panels, thus 1800W in total.

[OomD]

When you say it changes to line mode do you mean by it self? If so it will only do that if the battery voltage falls below the set value not the pv volts.

Yes, by itself. Bear in mind that with setting 01 set to SOL (and not SBU) it will revert to Grid as soon as the PV voltage disappears, irrespective of the battery voltage or SOC.

I gather this not normal behaviour?

[Arandoza]

I am also running a 5kva unit, and like JDP said, found it would switch between 5am and 8am and again from 4pm-6:30 pm from solar to mains, mine was set to solar, and solar and utility charging. I lowered the utility charging amps to 2 only, which then takes longer to switch back to solar, which means I get less switching at sunrise and sunset. Or one can choose solar only charging.

I also considered the SBU option, but was just concerned it would cause the batteries to cycle fairly

Often, so for now have opted to stay with the config above and evaluate it a bit.

Also the load on the system is quite low anything from around 200watts to about 800 watts, at these times, which could also possibly influence your experience?

[OomD]

Thanks for all the responses, guys. jdp, in your graph I see exactly what I suspected the cause to be. The only part that boggles my mind is that it never did this while only on 2 PVs, when the main PV voltage would be around 66V. I guess it depends on the internal thresholds that the axpert uses to switch.

 

Arandoza I also use SOL mode for exactly the same reason you do, to try and prevent excessive battery cycling. But, I see that batteries are cycled often anyway, as I only have 4 100AH batteries at this stage, and the "Back To Grid" voltage is set to 46V. This is because the axpert simply measures the battery voltage for "back to grid", instead of considering the battery SOC, and I don't want the batteries discharging too deep. Unfortunately this means that, especially when switching on loads like the kettle, the unit will switch back to grid and then start charging the batteries, as the load of the kettle makes the battery voltage drop - which off course does not mean the batteries are low.

 

The other reason for using SOL is not to get caught with low batteries when a (grid) power failure occurs.

 

Anyway, it seems to me that you guys also experienced this, so I glad to see it's not a fault on my inverter. My system load is similar to your, Arandoza. 

[OomD]

I lowered the utility charging amps to 2 only, which then takes longer to switch back to solar, which means I get less switching at sunrise and sunset.

Why would lowering the utility charging current cause it to take longer to switch back to solar?

[OomD]

If in Solar first mode it will go to grid if there is no PV or the battery volts fall below the set point. To me the mode does not work that well as you could end up switching all the time if you have clouds. I also see at sun rise and sun set the relays of the pv will kick in and out as the pv comes in and out also switching between grid and batteries. So I use SBU mode and my software drives the rest if the logic.

How does your software drive the rest of the logic? Does it change the axpert settings on the fly to cause it to operate the way you want it to? I could not see any serial commands to force it to change modes, for example, I could only see commands to change settings (and read data, off course).

[Arandoza]

My thinking is that while charging I am running from Eskom. and charging from solar which is subsidized with 2 amp from Eskom, so the batteries will recharge slower, and thus switching less often from solar to mains when the suns rising or setting, and the panels are not yet able to supply enough current.

Between 8am and 4pm the solar generates enough power to run everything and charge the batteries.

And at night we run from eskom.

[OomD]

My thinking is that while charging I am running from Eskom. and charging from solar which is subsidized with 2 amp from Eskom, so the batteries will recharge slower, and thus switching less often from solar to mains when the suns rising or setting, and the panels are not yet able to supply enough current.

Between 8am and 4pm the solar generates enough power to run everything and charge the batteries.

And at night we run from eskom.

I hear you. I'll set the grid charge current to 2A and see if that helps, thanks.

[OomD]

Thanks, jdp. Yep it seems a custom solution is needed to make the inverter work the way we want it to. I have just monitored my PV volts and as soon as it hits 58V (or thereabouts) the inverter switches to it. That explains why the 2 PV solution never had this problem... at 58V it's already pretty close to max, so is already able to supply current. But at 58V the 3PV solution is only just seeing the crack of dawn, and is not strong enough yet.

 

Ideally this should have been a setting in the axpert.

 

I'm in the process of designing my controller/monitor (that will include BMV like functionality), and thought of outputting to software like yours (mine will log data too) for the fancy graphs and reporting. I just don't want to keep my PC running to control the axpert, I'd prefer having a separate controller do this work for me.

 

Anyway, thanks for the feedback. How do you instruct the axpert to switch modes? By means of changing the setting (say from SOL to UTL), or is there a software command that says "Go to Grid/PV/Batt" mode?

[Coulomb]

This issue could be related to the bug I've found (and fixed!) in the firmware. What seems to happen is this:

* The charger exits absorb mode when the current falls below a particular current threshold for a partucular time threshold. The current threshold depends in a few things, but it's a minimum of 5 A; for now let's call it 8 A. The time threshold is fixed at 50 seconds.

* Bulk and absorb are actually combined into a single stage when the SCC (Solar Charge Controller) is connected to the DSP (Digital Signals Processor) inside an Axpert.

* Bulk mode starts slowly. Sometimes this is because of the strength of the available solar energy.

* Bulk/absorb mode would exit to float while the current is still less than 8 A for 50 seconds. In other words, it exits *on the way up* (PV current is still buiding) using criteria it's supposed to be using *on the way down* (battery has absorbed enough charge, and is full).

 

This could be causing the excess switching that you have been observing.

 

I have developed a patch to firmware 72.40 that makes these changes:

* The time threshold is increased from 50 to 120 seconds.

* The exit criteria are changed, to add this condition: the battery voltage must be at least (CV setting minus 0.5 V). This is the main fix. If the PV curent is still rising, then the battery voltage won't be near the CV voltage yet, so the criteria are not met, so the charging continues. When the battery is fully charged, it reaches and briefly exceeds the CV setting voltage. (That's what absorb mode is about - staying near the CV voltage until the charge current drops down low, often C/5 or even C/20).

* There are some trivial changes, to report a different version number, and to make the 7-segment "font" more readable.

 

The current threshold remains as per the factory, which is: the maximum of (5 amps, and the maximum charge current divided by 5). So it will always be 5 A or more, but if you have set your maximum charge current (PV plus mains) to 120 A, then the threshold would be 120/5 = 24 A. If you want a lower threshold (i.e. charge the batteries a little longer), you could adjust the total charge current to say 100 A (for a 20 A threshold), or 80 A (for a 16 A threshold), and so on. Most of you would not need very high combined PV and mains charging, so this does give you a degree of control over how long the absorb stage lasts.

 

The graph in the manual about staying in absorb for 10 x the time it was in bulk is just wrong, as far as I can see. This is the behaviour that the SCC would have in one of the Voltronic Power stand alone charge controllers, but it's completely overridden by the DSP when the SCC is combined with an inverter. At least, that's the situation for the Axpert MKS 5KVA models that I've examined. I think they just copied that graph from a SCC manual in good faith, and didn't realise that it no longer is relevant.

 

I developed this patch as a fix for LiFePO4 batteries. For LiFePO4, we wanted a few extra changes (e.g. minimum of 1 A current threshold, and allowing the low voltage cutoff voltage to be as high as 52.0 V). It was suggested that I should make a version of this patch without these extra LiFePO4 changes; this was done and it is called the "lead acid patch". Most of you here seem to be using lead acid, so that's probably the version of the patch that you would need if you were to try this.

 

Some of you are using 2015 models, which may come with firmware later than 72.40. (I'll find out in a few days, when my inverter gets re-delivered after the Christmas break). If necessary, I can apply the patch to the newer firmware.

 

Anyone wanting to try the patch can read these AEVA posts: introduction (pardon the gushing start from my enthusiastic friend Weber), and the lead-acid patch. Note that I've added "this patch may not be necessary" to the top of the latter patch, because you guys didn't seem to be having this issue, But now I see that it may just be a little hidden (from my point of view) as the "excess switching" issue.

 

Warning: the lead-acid patch is not as tested as the LiFePO4 patch. In fact, this version (I had to fix a bug in my bug-fixing patch ) hasn't even been downloaded to a machine (its predecessor has, and was tested as far as could be done on a machine with LiFePO4 batteries). But this may be the ideal time to test it, if you have a little more time this time of year. The zip file with the patch contains factory original 72.4 firmware in case you have to revert.

 

All comments welcome.

[OomD]

There is a command to switch modes. We posted links to the protocol on my softwre post. You can find it there.

Thanks, jdp. Obviously I'm being as blind as a bat, I downloaded the protocol doc referred to in your software thread, but I simply do not see a command to make the unit switch modes? I see a command to change the output source priority, but that is a setting and not a direct command. That is why I thought you perhaps cause the output mode to be changed by changing the setting, then causing the axpert to change modes?

 

Please help me here, which command in the doc is it?

[Coulomb]

POP02 = Battery / solar mode

POP00 = Line Mode

That seems to be setting output source priority, as Oomd mentioned. Does this effectively change modes immediately, assuming that the conditions are right? I think that this may be the problem, that it doesn't effect a mode change immediately.

 

Looking at the firmware, it merely changes the eeprom parameter OutputPriority, and sends an event. But the event is to the SciTask, which handles the serial ports (SCI stands for Serial Control Interface or similar). I wonder if it should wake up some other task to make the change happen sooner. I can poke around to see what task reads the output priority setting; it's probably task 0, the ModeSwitchTask. Maybe you can send some other command after the POP command to wake up the ModeSwitchTask; it will take me a while to sort this one out.

[Coulomb]

 

Maybe you can send some other command after the POP command to wake up the ModeSwitchTask;

Alas, no. None of the commands sends an event to the ModeSwitchTask. In fact, such events are quite rare. I haven't commented every call to OSEventSend() yet, but none of the ones I've done so far pass 0 as the task parameter (i.e. reference the ModeSwitchTask). But I've only done about half of these (but all the command processing functions).

[OomD]

Thanks, jdp. Tough I was missing something obvious.

 

Forcing a mode change by way of a setting change has its risks, off course. As settings are stored in NV memory (eeprom, I assume), how long before that wears out? Just wondering out loud here, I don't know how well the axpert software is written.

 

But ja, in the absence of commands that actually control the axpert I suppose changing the settings on the fly is the next best thing.

 

Thanks again!

[OomD]

Well the software that comes with it does it this way. So I am not using something I should not on my own.

No worries. I did not even know that it's own software (watchpower, I presume) can control it? I thought it's only for changing settings and recording logs.