Jump to content

Axpert 5 kVA patched firmware based on 72.70; overshoots


Coulomb

Recommended Posts

9 hours ago, Coulomb said:

the I term of the PI loop kept the power pouring in too long,

Finally decided to read up on that. Interesting stuff. :-)

It would seem to me that you need to limit the bounds of the I term otherwise your MPPT will always be slow to track, which is an important selling point of MPPTs, that they track better! :-)

Link to comment
Share on other sites

9 hours ago, Coulomb said:

My theory is that they have no protection against integral wind-up, so once the sun came out and there was plenty of available solar power, the I term of the PI loop kept the power pouring in too long, until that integrated error was reduced to zero by a negative error (the overshoot).

That certainly seems to be the case. Cloud moves past the sun, there is a drop in PV output , as the sun comes out, PV output takes off like a rocket, overcompensates or reacts too slow to pull back and causes the voltage overshoot.

Clouds.JPG.9e35d80deac37a6e660032199f9ae4f4.JPG

Link to comment
Share on other sites

1 hour ago, Don said:

Cloud moves past the sun, there is a drop in PV output , as the sun comes out, PV output takes off like a rocket

When you look at a current/voltage curve for a PV module (see attached image stolen off the interwebz), it is usually fairly flat at the top with a waterfall at the end (with Vmp perched right there on the edge of the cliff). An MPPT running at max power will have the voltage right there on the brink. But I suspect that here we're not running at max efficiency. The batteries are at absorb voltages and the MPPT is throttling the input in this example. As I understand it, the MPPT does that by driving the voltage over the cliff (without getting into a discussion about how it does that). So you have a little guy balancing on a surf board at the bottom of the hill there.

A sudden drop in the voltage should then cause the MPPT to reverse back up the cliff to get back to the maximum power point. There will always be a slight dip, that is unavoidable, but I suspect this can be done fairly quickly as it is very easy to detect when you've reached the MPP (dP/dt is zero).

This is of course followed by driving over the cliff again a few seconds later when the power is no longer required, but because the slope you're working at is now a lot steeper it is probably a lot harder to hit the right number. A small change in the PWM duty cycle has a much larger effect on the delivered power in this part of the curve. So I suppose it makes complete sense that any kind of filter that attempts to smooth out adjustments will tend to overshoot on that side.

Just thinking out loud of course...

pv_VI.gif

Link to comment
Share on other sites

18 hours ago, plonkster said:

The batteries are at absorb voltages and the MPPT is throttling the input in this example. As I understand it, the MPPT does that by driving the voltage over the cliff

My thoughts are that you would usually back off the current, i.e. move back away from the cliff, rather than over it. A lot of the MOSFET losses are proportional to I²R, so you'd be nuts to go for the high current option. Especially since as you say it's like "a little guy balancing on a surf board at the bottom of the hill there". I think it's also more intuitive; to back off the current, you just back off the PWM, and if the shape of the curve is such that this is now more power, just keep backing off. So that makes for a simpler algorithm, perhaps.

Now that I type this, perhaps that's the main problem, not integral wind-up. In Don's wonderful example, the PWM is set for maximum power, which with cloud is only 335 W. When the sun comes out, this PWM value may be past the MP point, so backing off the PWM actually increases the power for a while. If you aren't compensating for that somehow, you will get quite an overshoot. I'm no SCC expert, so I could be way off base there.

It's possibly also a combination of the two, if the above effect is real. Thanks for your thoughts, @plonkster.

Edited by Coulomb
Don't -> Don's (grr autocorrect?)
Link to comment
Share on other sites

55 minutes ago, Coulomb said:

My thoughts are that you would usually back off the current

That's precisely what happens when you push it over the cliff. You push the panel closer to Voc. At Voc, by definition, I=0.

The reason why you push it over the steep backside of the mountain rather than backing it down the front side (if this sounds like an analogy from Dawkins' "Climbing mount improbable", it kinda is... :-) ), is that you cannot go down smoothly to zero. The MPPT being a buck converter, you can only take the voltage down to battery voltage, at which point you will still make about a third of the maximum capacity.

55 minutes ago, Coulomb said:

just back off the PWM

Backing off the PWM actually increases the impedance and pushes the voltage up. The simple algorithm actually sends it over the cliff.

That's how I understand it anyway.

Edit: I said a "third", that's a thumbsuck. The lowest you can pull the PV down to (front side of mountain) is turning on the FET and leaving it on (100% duty cycle), which effectively pulls the panel down to battery. At this point it still makes battery voltage times PV current, which could be significant. Only way to get it down is to move the FET the other way, towards turning it off completely (0% duty cycle) which leaves the panel at Voc. Intuitively then, a 1% duty cycle is going to run the voltage on the backside of the mountain rather than the front :-)

Link to comment
Share on other sites

1 hour ago, plonkster said:

That's precisely what happens when you push it over the cliff.

Duh, of course. :o  Those IV curves always seem backwards to me. [ Edit: the convention is to put the independent variable, the one you can control, on the X axis, and the dependent variable, that one that arises from your choice of X axis value, on the Y axis. But they always seem to show it the other way around. Maybe it started that way because people put panels directly across batteries, so that the battery voltage really was the independent variable. But no-one does that any more. ]

And of course you are right, you can't go to zero in the other direction. So yes, a small PWM (current) error will produce a large voltage error in that part of the curve. Interesting.

All the more reason that you need good R&D to make a good charge controller.

Edited by Coulomb
As shown.
Link to comment
Share on other sites

19 minutes ago, PaulF007 said:

One question with regards to the overshoot. I noticed that most of the time it is only for a very short period. Will this really have such a big impact on the batteries?

It is just a spike for about 20 to maybe 60 seconds at most. I can't see that that should have any impact on the batteries. 

Link to comment
Share on other sites

6 hours ago, Coulomb said:

small PWM (current) error will produce a large voltage error in that part of the curve.

The better MPPTs use dI/dV to estimate how far away they are from the MPP. The peak is where dI/dV = 0 and in layman's terms is the slope of the line in the IV chart. So large dI/dV means take smaller steps :-)

Link to comment
Share on other sites

4 hours ago, Don said:

It is just a spike for about 20 to maybe 60 seconds at most. I can't see that that should have any impact on the batteries. 

but it might have an impact on the MPPT's internal components, as spoken about in another thread - I think about the Imeon inverters?

P.S. Wouldn't it be nice if we could "fine tune" MPPT (at least, the higher end stuff) controllers a bit?

Link to comment
Share on other sites

15 hours ago, Coulomb said:

the convention is to put the independent variable, the one you can control, on the X axis, and the dependent variable, that one that arises from your choice of X axis value, on the Y axis. But they always seem to show it the other way around.

Sigh. It's been pointed out to me that actually, changing the PWM is exactly changing the effective voltage that the panel sees. The panel sees in effect a boosted battery voltage, even though we call it a buck converter (because the power flow is in the buck direction). When the sun comes out, you just end up on a scaled-up version of the present IV curve, where the current is too high, so you just need to roll down the new IV curve to the desired current.

In short, the "other effect" (other than integral wind-up, I mean) doesn't exist. Sorry for the misinformation.

Link to comment
Share on other sites

3 hours ago, Coulomb said:

changing the PWM is exactly changing the effective voltage that the panel sees.

The way I understand it, is that because the big old inductor in the circuit has a reactance (X) which looks to the panel like a resistance, or one might generally say there is an impedance (Z) there that you can control using PWM, you can essentially control what V you want the panel to run at because V = IZ (and you control Z by controlling the PWM).

This paper helped to to understand some of the math behind it. The interesting bit is on page 4 (incremental conductance) and it provides a formula for calculating the error (how far away am I from the MPP), which as it seems to me uses precisely the slope of the curve to obtain a higher error value while it's on the backside of the mountain :-)

Link to comment
Share on other sites

Hi @Coulomb,

I flashed the inverters firmware yesterday after you posted. Murphy's law, as I completed the second inverter it started raining cats and dogs here. In any case I decided to test the firmware on grid/utility power. This morning the sun was shining with some scattered clouds, nothing too serious. I got to test the firmware on solar mode as well.

Herewith the settings on my inverters:

Parameter 2: Inverter 1 - 30 Amps          Inverter 2 - 20 Amps               Total - 50 Amps

Parameter 26: Inverter 1 - 57.6 Volts      Inverter 2 - 57.6 Volts

Parameter 32: Inverter 1 - Auto               Inverter 2 - Auto

Patched firmware 72.70b:

The battery voltage must stay above a threshold, and the charge current must stay strictly below another threshold, for at least 30 seconds. The voltage threshold is the bulk/absorb setting (parameter 26) minus 0.5 V. The current threshold is the maximum of two values:
1) the sum of all the Maximum Charge Current settings (parameter 02) for all paralleled machines, divided by 5 
2) the number of paralleled machines multiplied by 5 amps.

The way I interpret it from the above is as follow:  

Voltage threshold 57.6 - 0.5 V = 57.1 Volt

1) 50 / 5 = 10 Amps

2) 2 x 5 = 10 Amps

The maximum of the two values stays 10 Amps.

Therefore for the transition to take place from Absorb to Float, the charge voltage may not drop below 57.1 Volt and the charge current should stay below 10 Amps for a period of 30 seconds. Should the charge voltage drop below 57.1 V or go above 10 Amps, the timer would reset. Is that correct? If that is the case, the transition to float happened quite some time later for some reason, although the criteria was met in both cases. Especially the charging from solar took some time longer for the transition to float to take place. 

Figure 1: Charging from Grid

Coulomb4.thumb.JPG.e9e142cd204409e49c2291d3d737ad92.JPG

 

Figure 2: Charging from Solar

58baa868d7010_Coulomb7-solar5.thumb.JPG.dddb93187fdec8ebcfbdef48255fb277.JPG

Link to comment
Share on other sites

17 hours ago, Don said:

Therefore for the transition to take place from Absorb to Float, the charge voltage may not drop below 57.1 Volt and the charge current should stay below 10 Amps for a period of 30 seconds. Should the charge voltage drop below 57.1 V or go above 10 Amps, the timer would reset. Is that correct? If that is the case, the transition to float happened quite some time later for some reason, although the criteria was met in both cases. Especially the charging from solar took some time longer for the transition to float to take place. 

The current criterion is that the charge current has to be *strictly* less than (as in integer < as opposed to integer ≤) the threshold, i.e. strictly less than 10 amps, and because the current is measured in whole amps, this actually means 9 amps or less. Given that the time units in your grid charging chart are about 11 minutes, that seems to agree reasonably well (it's hard to tell the way the current is tapering off so gently).

For completeness, the voltage criterion is not strict, and there are two measurements. In order to pass the criterion, you need either battery voltage as measured by the DSP to be greater *or equal* to the threshold, *or* the battery voltage as measured by the SCC to be greater *or equal* to the threshold. The SCC voltage is usually a little higher while charging, so it's usually the SCC voltage that makes or breaks the criterion. Put another way, to fail the voltage test, you need the battery voltage as measured by the DSP and the SCC to both be less than the criterion. 

Looking at your solar charging charts, it looks like the battery voltage is pretty steady, and is not a factor from about 10:35 on. The average current seems to drop to 9 amps at about 9:35, and seems to be smooth for the next 40 minutes or so. So ideally, it should have transitioned to float by about 9:36, give or take 10 minutes. But solar charging is rarely smooth, and there could well have been voltage or current glitches that don't show up on the chart. From about 10:15 to 11:00, the clouds seem to have made the voltage and current curves quite choppy, so it's not surprising that float wasn't achieved there. It eventually went to float at about 11:18, about 1:42 later than it ideally could have. Ironically, this was a couple of minutes after a moderate glitch in the voltage and current. There is even a pair of glitches right before it went to float.

I think up to two hours of extra absorb time is not too bad, but it would sure be nice to minimise the over- and under-shoots of voltage (and hence of current), so that this figure could be improved. After all, some days might have choppy cloud all day. Hopefully, there will usually be a 30-second period where the chop is slight enough to allow transition to float. The chances of 30 seconds of smooth sun or cloud are a lot higher than the chances of 10 minutes (20x as long!) of relatively constant solar output.

If today's conditions (sun with scattered clouds) are about the worst case, then I think that this is Ok, and is as good as can be had for a while. If not, it would be possible to change the current criterion to be say divide by 4 (50 / 4 = 12.5 A, so 12 A would be used, really 11 A or less) so that it would be easier still to make it to float. But then on days where you needed to grid charge, you'd be getting a little less than a full charge. Maybe we'd make it /5 for single machines, and /4 for any number of paralleled machines ≥ 2. But let's see how 72.70b performs over time.

Thanks once again @Don for your prompt testing.

Edited by Coulomb
I'm told the second glitch is about 30 seconds before the transition to float, so reworded to suit.
Link to comment
Share on other sites

7 hours ago, Coulomb said:

 It eventually went to float at about 11:18, about 1:42 later than it ideally could have.

Yes, here is a time period of 15 minutes where the volts and amps were very stable. I was surprised that it did not make the transition to float during that period. 

58bba57e90185_Coulomb7-solar3.thumb.JPG.d7c84ee1a6e3c3de45fea37f8910e2fb.JPG

 

7 hours ago, Coulomb said:

There is even a glitch right when it went to float, but either that was seconds after it made the decision to go to float, or was actually caused by the decision to go to float, with its consequent change of voltage set-point.

During that period, there was at least three resets.

58bbac8d587ac_Coulomb7-solar6.thumb.JPG.b3ce96193cd661d84ede611c1359c1eb.JPG

I zoomed in on the 30 seconds preceding the transition to float. It seems the criteria was actually met (voltage border line), although it was choppy at the time, unless the decision to go to float caused the choppiness. 

58bba7dc41048_Coulomb7-solar9.thumb.JPG.feda7f9d65ae5f7c059d3c1a67fd4f08.JPG

7 hours ago, Coulomb said:

But let's see how 72.70b performs over time.

I agree, let us leave it for now and see how it goes. At least it goes to float now on solar, where it was virtually impossible before.

Link to comment
Share on other sites

Hi @Coulomb,

I sat here watching the graphs like a hawk. Today, when the criteria was met, the system made an attempt to go to float and seemed to abort. Shortly after that a second attempt was made and it transitioned to float. It seems it is at the time of making the decision that causes the choppiness. Just a pity that the clouds moved in as it went to float (the cause of that spike you see). The SOC according to the BMV702 is at 98%. I think the setting are just right. It had a nice decent absorb time and it can now trickle charge to 100% on float the rest of the day.

58bbc2d8f0ceb_Coulomb7-solar10.thumb.JPG.2edaaecc8adbb93f989890453667c821.JPG

 

58bbc92b59028_Coulomb7-solar11.thumb.JPG.3688a4f05e4703d69c143eeaa50954d9.JPG

Link to comment
Share on other sites

@Don, I think that today's chart was a textbook perfect case. The SCC has to get consistent readings of 9 A or less for 30 seconds, and it looks very close to that when it transitioned. There may be slightly different readings between the SCC, the DSP, and your BMV (a nice alphabet soup there), and I can readily excuse that difference today. Hopefully today was a best case, and yesterday near worst case, and you won't have to worry about it any more. Thanks for the additional data. 

Link to comment
Share on other sites

Just some feedback on firmware version  72.70: 

If you have been following Coulombs posts, you would be aware that the original firmware from Voltronic, comes with a charging bug. That is why there is the need for Coulomb to patch the original firmware, to fix the charging bug in the firmware. In short what happens is the system would transfer from absorb to float to early. The batteries would be in float while they should still be in absorb stage.

For the system to transfer from absorb to float, the voltage need to be above a certain level and the amps below a certain level for a period of time. In the past this used to be 30 second. It seems with the latest original firmware release they changed the time period to 10 minutes in an attempt to fix the problem with the system going to float too soon. The charging bug was still there and therefore the Coulomb patched firmware version 72.70A. The charging bug was fixed once again in this version and the time period left at the "new" 10 minute period. This however caused another problem. It was virtually impossible for the system to go to float and it would stay in absorb stage the whole day. My feeling was that if the charging bug was fixed, then maybe 30 seconds was the right time period in the first place.  

@Coulomb decided to reduce the time period for the voltage and amp criteria to be met for the system to transfer from absorb to float back to 30 seconds, as in the previous firmware versions. This is the latest patched firmware version 72.70b. I tested the 72.70b firmware and it seemed to be fixed, although it would not transfer from absorb to float when expected to as the criteria was met, but only some time later. We concluded it could only be spikes that the monitoring software was to slow to catch and caused the timer to reset. It however still bothered me why the transfer never took place when it was supposed to, as ICC for Pi was reading at close to 2 readings per second. Yesterday I was sitting here at my PC watching all the data coming through, going from one graph to the other, then it dawned upon me. The volts and amps graphs in the monitoring software were coming from the BMV readings, not the Inverter readings. The BMV readings were very stable, while the Inverter amp and volt readings were erratic jumping up and down continuously. I needed to look at the Inverter amps and volts. Therefore it is not the monitoring software that could not see the up and downward spikes, I was looking at the wrong data. 

This morning I watched the Inverter amps and volt readings. There was always one spiking op or down resetting the timer. Eventually the readings became more stable and I noticed the amp and volt criteria was met. 30 Seconds later it went from absorb to float, as it should. I can confirm with confidence the patched firmware version 72.70b works as intended and would recommend you download it and flash you Inverters with this firmware version. 

Thank you very much @Coulomb for the great work you are doing with the patched firmware versions. I know you mentioned that you are communicating with the OEM to have the bug fixed in the original firmware. Therefore no more patching required. Please keep us updated on the progress. 

Hi @ebrsa, if you have not upgraded the firmware on your inverters yet, it is time to do so now. 

Link to comment
Share on other sites

Thanks  great deal @Don for all your hard work in what must be hours of testing and returning to the forum after the unhappy incidents of the recent past. It takes maturity to rise above the childishness and contribute to the benefit of all Axpert and Infini users. @Manie has similarly demonstrated maturity by posting again. Let's hope the exchanges will in future be kept at a level well above that of the yellow press. We also owe @Coulomb our gratitude for his ongoing attention to improve the firmware.

I will certainly upgrade my firmware during the weekend when I will have time and report back what I find.

Link to comment
Share on other sites

  • 3 weeks later...

Hi guys,

I just reflashed my Axpert 5Kva MKS with @Coulomb's 72.70b firmware. I did however try to update by SCC firmware as well but with no luck. I followed the instructions and tried it from 2 different windows laptops but no luck. I keep getting error messages and the aipProgram closes. An advice? should I bother? I still have 1.24 on my secondary CPU.

Capture2.PNG

Link to comment
Share on other sites

11 hours ago, Czauto said:

Hi guys,

I just reflashed my Axpert 5Kva MKS with @Coulomb's 72.70b firmware. I did however try to update by SCC firmware as well but with no luck. I followed the instructions and tried it from 2 different windows laptops but no luck. I keep getting error messages and the aipProgram closes. An advice? should I bother? I still have 1.24 on my secondary CPU.

Capture2.PNG

I Googled this error, and came up with:

"Most likely you have a DDX call to an control ID that doesn't exist on your dialog. Did you delete anything from your dialog and not delete its associated member variable?"

(DDX is Data Exchange, old Microsoft terminology).

Poking around in the code confirms this. So most likely there is a bug in the upload code (all original manufacturer code, not patched) that is normally not invoked, so it doesn't normally get seen (and hence fixed). My guess is that it's to do with a dialog that has been removed, and that would be the one for the comm port. I think they had a lot of trouble getting the code to work with a selectable comm port, and thought to hell with it, we'll always use COM1 and make the user change their comm ports to be COM1. Then they forgot to delete some code that references the now deleted comm port.

You state that you followed the instructions... did you somehow forget to change your USB to serial's device to COM1? This applies only to the SCC firmware updating; the DSP firmware (72.70b) updating uses a totally different upload program, which allows for COM1-COM9 (but not COM10 and beyond).

Mind you, when I just tried running it with no COM1 present, it just said "Invalid port number" and didn't throw up the assert failure. So the light works fine in my office.

I tried running it from a folder with a space in the name. No assert failure.

I don't suppose you have Visual Studio (free "Express" or "Comminity edition" is fine), so you can press "Retry" and see the call trace, and post it here?

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...