Coulomb

That breaker looks too small to reliably break 100 A DC. AC perhaps, but not DC over 24 V. I use 100 A HRC 38 mm diameter fuses (positive and negative) in large holders that can be used as isolators. 100 A fuses that size don't nuisance trip on minor surges. These will cost considerably more than those dinky breakers, but it's safety equipment, so you pay it.

That's ok, the BMV will still work without the Axpert running. You'll need to read the BMV's small screen though, as your monitoring software won't work without the Axpert running. Edit : also, a clamp meter reading DC will have a significant offset that will likely confuse the issue.

I'll keep your problem in mind for when I get time to read the firmware again. In some places, it is using tenth of an amp resolution; in others, whole amps. It may be that it can't control the current to less than one amp. But there is the option of disconnecting the charger / inverter completely, and it sounds like that's what you need. When the current is leaking in, does the LCD display show the utility charger active? I.e. A box between the utility "tennis ball" and the battery icon, with power flow lines between?

No, I can't see why the patched firmware would help with this. Are you sure this is real current into the battery, not current from the inverter / charger supplying losses? As I type this, it seems unlikely.

Ah. I was thinking about the 5 kVA models, which are the only ones I've worked with. They use the inverter to "suck power" from the mains and hence charge the battery. It seems that the 3 kVA and below models use a separate power supply, as shown in the attached image. [ Edit: hence, a short on the mains input is much more likely to be in the AC/DC charger, though it could still be a MOV or other protection component near the mains input, before the relay marked "main". ] There is some good detail in the 1 kVA - 3 kVA service manual. PM me if you can't find it. My file is named "Axpert MKS 1-3KVA Service manual 20130611.pdf". I'm pretty sure I got it from this forum, in "Axpert Service Manuals 1.0.0" (thanks, vandyh!). I revisited this older thread because of a "like" by @starpk to my post.

Thanks! As a point of interest, what firmware version came with it? Main and SCC? There seems to be more support for equalisation now (many more settings, anyway).

That's more like it I remember home-made cassette interfaces that worked at 1200 bps and the chip could lock onto a quarter of a cycle. Also a DecWriter (more modern Teletype) that I hacked for 600 baud operation (300 baud standard). Early firmware updating: cocktails Asteroids video game (6502 processor) turned into a vector graphics interface for my Z80/S100 main computer, and modifying Flight Simulator (bought on cassette tape, I think) to drive the graphics. I even hacked the database to create a canyon to fly into. Those were the days Um, we're not drifting off topic now, are we?

Oh. So you skipped the SC/MP, Z80 and 2650 with S100 bus, Amiga, and making your own SCSI hard drive interface? And get off my lawn!

I find usually COM7 to COM9, sometimes COM5, but it depends on which USB port I plug into, the time of the day, and the phase of the moon, One Windows 7 machine from a friend of mine usually comes up with COM11 for one of the ports; so we have to change it or use another port (for DSP firmware updating). One of my ports is now locked to COM1 after trying to reproduce the SCC upload assert failure.

Well, it would be better to write the upload software properly so it can use any comm port up to 99 (or whatever the practical limit is) , but that's not an option with what we're provided with. The SCC upload software is hard wired to only use com1, period. I've never seen Com1 in use by other hardware, it seems to be reserved unless you have a real (non-virtual) comm port. So that mitigates the forced use of com1. But with millions of Windows PCs and laptops out there, I can believe there could be exceptions. I don't know if the use of com1 implies certain other resources, such as IRQ vectors or memory buffers with particular addresses. But library code should be dealing with those issues automatically.

I see that the latest instructions don't mention the OCX registration process (user friendly software, huh). There is a PDF file in the folder with the other SCC update files that tells you how to register the OCX. Solamahn who sometimes posts on the AEVA mentioned an assert failure; when I prompted about the OCX registration his next post stated that he "had it working now". I'll update the instructions on AEVA.

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?

No, I don't think it will matter. Perhaps the next thing to try, if there is no difference, just to be absolutely sure.

@PurePower: your first post on page 2 mentions your "Axpert MKS-5SK"; this is a true Voltronic Manufactured 5 kVA inverter with an MPPT Solar Charge Controller, right? I had a terrible thought when I noticed the title of this topic ("Axpert MKS 3000 24V Overload Bypass Enabled/Disabled"), since the patched firmware certainly won't work with a 24 V inverter. You would certainly have noticed that all the settings were for a 48 V battery, but if yours is one of the PWM (non MPPT) models, then it's possible that the patched firmware might appear to work, but have subtle errors. But if official firmware 72.40 works for you, then patched 72.60 should work. Did your inverter come with 72.40 installed?

Yes, just use the old firmware file. I always include the original firmware that the patch is based on, in case it's necessary to go back, with the download instructions. In this case, that would be 72.60. But if you want to test 72.40 specifically (perhaps that's the last one you know worked for you), then I happen to have some older firmwares (including 72.40) available here: http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=59274&title=pip4048ms-inverter#59274 .

Excellent; good to eliminate the battery as a possible problem. It's certainly possible that there is a bug in the patched firmware not present in the original. I'll look into it. I'm not aware of any problems downgrading to an earlier firmware version, though others have claimed this.

Interesting. I wonder if the design and/or firmware are jointly done with Imeon. Or perhaps Imeon just have an arrangement whereby Voltronic manufacture the Infini series.

It's also my belief that the Axperts are manufactured by Voltronic : http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=59962&title=pip4048ms-inverter#59962 Edit : it seems the above post was spurred on by a post by @fllniks, quite possibly from this Power Forum. Thanks!

@stuvo, the 80 A of SCC output makes it a pretty recent model. They must be using old images on the web site. I'm guessing October 2016 manufacture date, based on the barcode number. But 80 A of SCC charge current plus 60 A of utility charge current makes 140 A max. Perhaps if you change the maximum utility charge current to 60 A it will allow up to 140 A of total charge current. Not that you need that much with a lead acid battery, just that it could explain the 110 A max (80 + 30). [ Edit: and the paper manual is old, that's not uncommon. ] [ Edit 2: maybe firmware version 32.xx is normal for the 80 A SCC version, can anyone confirm? I'd expect SCC version 04.10, however. ] So now, the low firmware version number remains a mystery, as well as the inability to update firmware.

@stuvo, it looks like you're doing everything right with the software update process, at least from what we can see here. I'm concerned about the 32.40 firmware, Either that is very old (the lowest number I have seen on a 5 kVA Axpert is 52.02), or the versions don't always increase with time, or it's custom, or it's not a Voltronics Axpert. I agree it would be very good to contact your supplier to see if they can provide a known compatible software update, or at least the update files for the existing firmware in case it's special in some way (and of course that you find some way to actually perform the update). I could not find any Axpert model on the SMK website. However, the fourth scrolling picture on the main page shows what looks very much like an Axpert, but with no brand name at all. The title said "Hybrid Inverter Charger", which is strange because the Axpert isn't a hybrid. When I click on Hybrid inverters under Products, I get a completely different looking blue box with a black "slot" up the middle. When I download the catalogue PDF, the specs for the blue box do sound like that of an Axpert, except for the mains charging, which is limited to 30 A. That sounds like it might be old hardware, which is quite possibly not suitable for use with firmware version 72.XX. Perhaps not even firmware version 52.XX. Perhaps the uploading process was different back then. Perhaps you have been spared a "bricking" by this, intentionally or not. (If intentional, I would have hoped for some error message, perhaps "Your inverter is not compatible with this firmware, contact your supplier" or similar.) Do you have a manufacturing date on your machine? On later models, it's on a small (perhaps 30 mmm x 10 mm?) label put over one of the case screws, so that they have evidence if/when you open the case. The vibes I got from the SKM website are that they are an independent manufacturer, not a reseller. But perhaps they are content to resell into the Axpert market, not compete with their own product, at least for the present. Edit: one final clue: the photo on the main web page hints at a heatsink on top of the unit. The top of modern units is smooth cover metal, no visible heatsink (the SCC heatsink is now entirely internal, for better or worse). Does yours have a finned heatsink at the top?

My guess is that COM1 isn't the USB to serial adapter. Is there another option for the serial port, i..e. if you clock the arrow at the right end of the "Serial" drop-down list box, are there any other entries in the list, other than COM1? As for the the assertion failure from the SCC firmware update program, I have no idea, but it sounds like it's related to the serial port issue. You said the existing firmware version was 32.40... could that have been a typo and it was actually 72.40? If it's not a typo, perhaps it's not a real Axpert, in which case all bets are off. Edit: make triple sure that Watchpower etc are not running; you need to use the exit menu, not just close the app.

Yes, it's not that simple, and I don't get why there isn't one visible. I didn't try hard to sort it out.

I don't know much about deep cycle lead acid batteries. My understanding is that you should not charge them much faster than C/7, or discharge them faster than some other limit, which I thought was about C/2 or C/3. 4000W at 48 V with 93% efficiency is some 90 A, which is heading towards C/2. I would not expect the voltage to collapse at that load, but I would not be surprised if the battery voltage at the Axpert terminals did a bit of a dip that causes the Axpert to draw more power to maintain the load, causing more voltage drop. Enough for the Axpert to declare overload. All this could happen so quickly that the Axpert display may not show it, let alone software monitoring. This would be more plausible if your battery cables were on the thin side, say 25 mm^2 or less. As I type this however, the above scenario would probably result in a different error code, related to battery and not overload. It's still plausible, I think, but less likely than I thought. So yes, a bit mysterious.

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?