Coulomb

My understanding is that when it is set up, USB comms is just the same as serial comms, including being as slow as 2400 bps serial. There is then a virtual comm port like comm12. [ Edit: this isn't quite right; see Gnome's reply. ] So then you can use any serial comms program like TeraTerm. [ Edit: and this last part is completely wrong. ] But the trick is in setting it up. I never figured it out, and I've never seen it documented anywhere.

Yeah, it's supposed to be able to run 4 kW continuously. Maybe the load has a really bad power factor, and it's exceeding 5 kVA? That also seems unlikely. Maybe the battery voltage collapses when it reaches around 48 V, but if rescued at 49 V (where the internal resistance is a little lower) it's OK? What is the capacity of your battery?

Yes, there is the CRC (two Cyclic Redundancy Check characters). That's why the NAK comes back as NAKss; the "ss" part is the two-byte (two-character) CRC. There are a very few commands that don't require a CRC, and I think that QPI must be one of them, since it doesn't send back a checksum, just the 6 characters "(QPI30" and a carriage return. Try sending the CRC with the PI command. In this case, it's 0xD752. The second character is just "R", but the first is "W" with the sign bit set. Comms programs differ in how to send such characters. Some background on using commands (for the non-V Axpert, but the principles should be the same). The end of this post has how to send 8-bit characters using the Windows program TeraTerm. C source code for generating CRCs. A Windows applet for generating the CRCs more painlessly.

Your voltage logging seems to be reporting whole volts. The inverter's DSP works on tenths of a volt. So that 48 V might really be 48.4 or even 48.9 V. So it doesn't actually cross the back to grid threshold.

You can use both [ Edit: monitoring software and remote display ] I believe. Just use a USB to serial adapter, and connect the computer to the serial input of the remote unit. You might find extra delays that way, so it might not be ideal. I've never tried it, this is all theoretical.

My slightly educated guess is that running queries on multiple machines should be fine; the Axperts run a multitasking operating system and there are interlocks to prevent problems. However on a single machine, there is a lack of serial ports. There are two, but one is dedicated to talking to the SCC. It's possible that the USB port talks via some other port, but then I'd expect to see an extra cable from the serial port board to the processor board.

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

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.

The Axperts, also made by Voltronic, had this issue and it was fixed by a firmware update. @superdiy, maybe you're thinking of them, but maybe all their products from that period (2015?) had this issue. It may have been a desperation fix for some issue, and I'm blanking on what that was. Overcharging batteries comes to mind, but I can't see how the two are related. Edit: maybe it was overheating due to fan failures, that they fixed with coating some fan connectors. Still makes little sense.

Patched firmware version 72.70b is now available; see this AEVA post and the posts it links to. @Don, it would be great if you could test this for us all. Sun here has been poor, and rain is forecast for the next few days.

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.

Duh, of course. 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.

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.

Alas, Helios was not cooperative today. We were forecast a week of rain two days ago, now it's finally here.

Yay! I don't suppose you remember if the sunshine or clouds were particularly steady towards the end there, say after 3pm? I suppose other graphs could tell you that. Yeah. That's a doozy. Notice that there was a small voltage dip (undershoot) just before the overshoot. So for maybe a minute before the sun burst out around 2pm, the SCC was working at maximum output, and even that wasn't quite enough to maintain 57.6 V. So there was a small error in the output voltage, that over the minute would have integrated to a moderate "I" (integral term) value. 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).

@Mark, as far as I know the Axperts have a "Non-Return" valve. With firmware you can only go forward, not backwards. I'm pretty sure you can go backwards. I'd say that 72.60A would actually work better for you than 72.70A at present. I have 72.70b (LFP version) ready for alpha testing today. Would it be possible to post your battery amps graph? Just to get a feel for whether 72.70b is on the right track. From the battery voltage graph, it sure looks like there would be several stretches of 10 minutes where the solar input is even enough to allow the transition from absorb to float. The other thing to try would be to turn off some of your PV breakers when the SOC is near 100%, so that it has less power to overshoot and undershoot with. Obviously, this is not a permanent solution, but would be a helpful diagnostic. It's a little ironic that your very capable PV array is contributing to the problem here.

@Don, thanks for the clarification. Are you in a position to watch the charge currents on the LCD display? You may find that when the sun comes out, there is a rush of charge current due to the SCC overshooting the voltage set point, that the software doesn't catch (or only catches every fourth time perhaps). Similarly, you may find the battery voltage dipping more than half a volt below setting 26 for a second or two. It could happen even faster than that; the software works on 20 ms time slices, whereas the display seems to update about once or twice per second. But your software may be monitoring battery voltage and current much less than once per second. My theory is that at least one of these must be happening to reset the counter, so it never makes it to ten minutes. Sounds like cutting down the 10 minute qualification time is the way to go.

@Don, also what's your setting 32 ("Bulk charging time")? Automatic or a time?

Don, you say that your Axperts are stuck in bulk stage, and are not getting to absorb and hence not to float. How do you know it's in bulk? Hanging around the CV voltage (I assume your setting 26 is about 57.6 V) sounds like it's in absorb. What the Axpert actually believes it's in is only revealed by a field in the non officially documented Q1 command response. Does your software show the charge stage? I don't see it on the screen dump you showed earlier, but it may be on other screens. The thing is, the qualification time for bulk to absorb is only 10 seconds, already quite short, and changing the qualification time for absorb to float won't affect anything if it really is stuck in bulk.

I'm starting to think that the problem is the much longer qualifying time for reaching float (10 minutes in 72.70, 30 seconds in 72.60, 72.40, and 52.30, though in the latter we seem to have attempted to patch to 2 minutes (actually achieving 72 seconds). So the qualifying time is much longer. Maybe this was their lame attempt at fixing the main charge bug (too *easy* to go to float). Watching mine just now, with the solar power bouncing up and down, it's really hard to make both criteria (high enough voltage, low enough charge current). When the sun comes out, the temporary overshoot on battery voltage disqualifies the low current criterion. When a cloud comes over, the temporary undershoot makes it fail the battery voltage criterion. The chances of making both criteria without exception for 10 minutes become very low if you have changing solar conditions and/or loads. I'll ask Weber whether he agrees, and perhaps we could bring out 72.70b with that change (30 seconds qualify for float, instead of 10 minutes).

Sorry, it's me that is confused. I shouldn't be posting after midnight on my phone. Yes, those settings are fine. I'll have another think about what your problem might be.

Indeed. It seems to be "good enough", as long as you have a good battery management system. When a friend and I looked into solar energy systems some years ago, we came across essentially the "Blue verses cheap" question (where for us Blue could be Victron, Selectronic, or Xantrax/Schneider). As you guys have noticed and discussed, there is a substantial difference in cost, but also performance. We had a pair of PIP-4048 (Axpert 5 kVAs) to attempt to repair, so we evaluated them for our needs. (It turns out we successfully repaired only one of the two, so we were very aware of the reliability situation). In the end, we decided they would be good enough, but only if we could solve a problem with the charging. Initially we thought it would just need the right commands, but to do that we needed to crack the CRC algorithm. That was the start of the huge AEVA thread. It took some months to figure out that it was a firmware problem, and that it could be successfully patched. That was the start of the series of patches, and we made the decision to go cheap verses Blue. I'm going to make an attempt to get the charge bug fixed in official firmware. If that and the overshoot can be fixed in official software, then we'd have helped make available to all an inexpensive but decent performance inverter and charge controller. Well, especially if we can convince them to use 100 V MOSFETs on the battery side. It's so frustrating that there isn't a mid priced option, or that Voltronic don't put a bit more R&D into their products. As far as I can see, the only products competing at the low price end of the market are knock-offs of their own products, so they could own the mid price market, and make more money.

Ok. Respect! You must have a bad setting somewhere, or ICC (?) is sending a bad one (perhaps a bad configuration for it; sorry, I'm not familiar with how it works). It nearly has to be setting 02 (from memory, maximum total charge current) being not much more than maximum utility charge current. That's assuming it stays like that, with the battery voltage near the CV setting. If that's actually your float voltage, or it goes to your float voltage later in the morning, then it could be the charge bug, and you need the patch.

Yes. I'm still hoping to find that they have integral windup or similar, and that I can find an easy patch for that.

I have seen about 1.5 V overshoot, not such a big deal but they last for 30-60 seconds. Today it was causing my BMS to drop out the solar panels because one cell was over 3.61 V. The SCC was still pumping over 20 A into it when the overall battery voltage was 1.5 V over the set point. I'm used to a Blue Sky Energy solar controller, made in the USA, still in use with 3 of my 11 strings of panels, which has brilliant voltage control. It never seems to overshoot by more than one or two tenths of a volt. So I know it can be done :-) I agree that it only seems to overshoot on solar, where the source power is intermittent. Your system doesn't seem to put much solar energy into charging, though before 9am where your screenshot is from there wouldn't be much solar power. Presumably around noon it puts in a lot more current. Though with lead acid, you may be limited to perhaps 40 A of charging, even if you have more solar charge current available. That's another advantage of lithium batteries; they can absorb every bit of solar power that you have available.