Axpert MKS II 5kW Error 08

[APV]

7 minutes ago, charlez said:

@APV  I am being stupid! Got wires totally mixed.

I presume watchpower is working now.  I am impressed to see that you are using a keystone to modify the pinout!  I actually wanted to suggest that (instead of cutting the cable).

[Coulomb]

22 minutes ago, charlez said:

Would one be able to connect watchpower via the cable just to test it?

Yes.

Afterwards, don't forget to exit Watchpower properly via the system tray, not just close the window.

[charlez]

@APV no its not, going to try the Narada Battery cable. Its also FTDI but different  pinouts are below. Will convert using the keystone. Thanks for all the help!!

[APV]

37 minutes ago, charlez said:

@APV no its not, going to try the Narada Battery cable. Its also FTDI but different  pinouts are below. Will convert using the keystone. Thanks for all the help!!

No, you cannot mix RS485 and RS232.  Different voltage levels...

[APV]

Just now, APV said:

No, you cannot mix RS485 and RS232.  Different voltage levels...

Also RS485 is a differential mode protocol (no ground), while RS232 is relative to ground...

 

[APV]

@Charlez: Did you use a multimeter to check that you made the correct connections on your RS232 converter?  Based on your initial post, you need to have connectivity as follows:

USB-RS232  RJ45 => PIP  RJ45

5 => 8

3 => 1

6 => 2

Remember to align the PIP RJ45 as in my photo - it should just work.  If it doesn't, try swopping 3 and 6 of the USB converter.  Also when I look at your photo of your keystone conversion, it does not look right.  Use a multimeter to verify that 3 and 6 of the RJ45 goes to the correct pins on the keystone...

[charlez]

54 minutes ago, APV said:

@Charlez: Did you use a multimeter to check that you made the correct connections on your RS232 converter?  Based on your initial post, you need to have connectivity as follows:

USB-RS232  RJ45 => PIP  RJ45

5 => 8

3 => 1

6 => 2

Remember to align the PIP RJ45 as in my photo - it should just work.  If it doesn't, try swopping 3 and 6 of the USB converter.  Also when I look at your photo of your keystone conversion, it does not look right.  Use a multimeter to verify that 3 and 6 of the RJ45 goes to the correct pins on the keystone...

@APV  thanks so much for getting me here, Watchpower now works with that cable. Problem was I had two keystones with different layouts and was referring to the key on the other one thinking they were the same. Can't thank you enough and @Coulomb for walking me through this.

[charlez]

55 minutes ago, charlez said:

@APV  thanks so much for getting me here, Watchpower now works with that cable. Problem was I had two keystones with different layouts and was referring to the key on the other one thinking they were the same. Can't thank you enough and @Coulomb for walking me through this.

Success! Thanks

[charlez]

On 2020/04/09 at 3:53 PM, Coulomb said:

My initial thought was that they had ported the PylonTech battery type == PYL code to this machine. Alas, no.

There is a new command QBMS, which spits out data like BMS battery voltage, maximum charge current, and so on.

This information comes from parsing a command of the form ^DnnnBMSddd... where nnn is the length of the command, just like a device response from a "secure" command (ones that start with the up-arrow). This seems to use the serial port that is otherwise unused in these models with 450 V max Solar Charge Controllers. That serial port is used to talk to the processor on the Solar Charge Controller in 145 V max SCC models; in the 450 V max SCC models, the DSP controls the PV boost converter directly, and so doesn't need the second serial port.

The maximum charge current value (and likely other values) seems to be actually used; in the case of maximum charge current, it is used instead of the EEPROM maximum charge current setting, if appropriate bits are set. Presumably those bits indicate that the BMS is connected and BMS data is actively being received.

I note that the Pylontech BMS information is in a packet that starts with an up-arrow, but as far as I can tell, the format is different. So this is not directly for PylonTechs. So what is it for? A great question. My wild guess is that Voltronic Power are developing some new interface for battery BMSs, separate from the inverter-chargers themselves, which might translate BMS data from various different battery BMSs into one format, the one indicated above. But I stress that this is a wild guess. I'm further guessing that it's not quite ready yet, but the firmware source code is in the process of incorporating this new functionality, and when a fix for the bus voltage control / error 08 bug was needed, this BMS stuff "came along for the ride".

So while this new BMS code isn't a port of the battery type == PYL code, it might even be something better.

As for what they changed in the way of bus voltage control, I've not found that code as yet. There are plenty of red herrings: variables and functions with "busv" in the name, but aren't used. I may get to it tomorrow my time; I'm curious as to what they've done. With all the BMS code additions, it's not a simple matter of comparing function lengths to see where significant changes have occurred.

@Coulomb so still no feature to pass in SOC?

[APV]

On 2020/04/09 at 6:48 AM, BvR said:

I did put up a fuss with Voltronic themselves regardings this issue.  At first they gave me a lame answer as follows :

"Per your information below, it means error 08 was caused by the surge from the grid input. Error 08 means high BUS voltage, if the grid is not stable, and has high voltage spike, it will make the inverter BUS over voltage, then error 08 will happen.

 The inverter will restart when Error 08 happened. But the bus voltage must be lower than 500V. It can restart three times within 15 minutes.  If it exceeds three times, it won’t restart automatically. You will need to turn off the power and restart the inverter manually."

 I told them that the answer was not good enough since we have surge suppression installed and that the grid voltage was 223Vac at the time when the error appeared

I then received the following answer :

"Our RD has prepared updated firmware to improve error 08. Please find the download link below. The password is “daily”.  

 Please upgrade the firmware and check whether error 08 is resolved. "

I hope I achieved progress for all of us

AxpertMKSII5K71.80P.rar 1.43 MB · 16 downloads

Sadly, the problem reoccurred tonight after a cloudy day!  I guess @BvR will have to take it up with Voltronic again

 

[Coulomb]

41 minutes ago, APV said:

Sadly, the problem reoccurred tonight after a cloudy day! 

I was going to post that I didn't find any differences in the handling of the bus voltage, but there are so many parts of the code involved that I thought I'd wait for confirmation of a change.

It looks like they've just sent the latest firmware, in the hope that there was a fix in there somewhere, without having to actually sit down and solve the problem. A cynic might have said this was just to keep the customer quiet, but let's assume they wanted to confirm that there really is a problem even after the latest firmware, before they devote significant resources to it.

[APV]

10 minutes ago, Coulomb said:

I was going to post that I didn't find any differences in the handling of the bus voltage, but there are so many parts of the code involved that I thought I'd wait for confirmation of a change.

It looks like they've just sent the latest firmware, in the hope that there was a fix in there somewhere, without having to actually sit down and solve the problem. A cynic might have said this was just to keep the customer quiet, but let's assume they wanted to confirm that there really is a problem even after the latest firmware, before they devote significant resources to it.

Just for interest sake, what are you using to convert the HEX code to some readable form?

[Coulomb]

19 hours ago, charlez said:

@Coulomb so still no feature to pass in SOC?

Yes! [ Edit: as in, there is such a feature now! ]

When a suitable gizmo converts the BMS data into the Axpert ^DnnnBMS data command, the BMS SOC is used to update the 4-segment battery "bar graph", and also the value returned in the appropriate field of the QPIGS and QBV commands.

It also turns on the little "Li" segment near the battery icon, when the BMS is connected:

Edited April 12, 2020 by Coulomb
Clarify what I'm saying "Yes!" to

[Coulomb]

2 hours ago, APV said:

Just for interest sake, what are you using to convert the HEX code to some readable form?

For various technical reasons, I prefer not to give too many details. However, I use Ida Pro (the Interactive DisAssembler, PROfessional version), and I use some tricks to get the names of functions and the like. It's really tedious and time consuming, but for some reason I like exploring firmware. To do this, you need to be familiar with the architecture and instruction set of the Texas Instruments C2000 DSP (main processor), Freescale HCS08 (for the 145 V max Solar Charge Controller), and lately the ARM thumb instruction set (for the processor in the removable display of models so equipped).

I've invited one or two people to share in this work, but so far none has lasted more than a few days. Perhaps no-one else is crazy enough 

[Coulomb]

If anyone wants to try to use these new BMS features, here is the format of the appropriate command. I believe it needs the usual Axpert CRC characters at the end, and of course a terminating carriage return. I haven't checked the "polarity" of the "c" field.

;
; ^ D n n n B M S aaa bbb c ddd eee f ggg hhh iii
; 0 1 2 3 4 5 6 7 8
;
; nnn is command length, including ^ and two CRCs, but not CR

; Next fields are variable length, space separated:
; aaa is BMS battery voltage, tenths
; bbb is BMS SOC, pecent 0-100
; c is 0 or 1 for discharge or charge current
; ddd is BMS battery current
; eee is 8 warning flags 0-255 (not used at present)
; f is 1 for force charge; 0 otherwise
; ggg is BMS CV voltage, tenths of a volt
; hhh is BMS float voltage, tenths of a volt
; iii is BMS max charge current, tenths of an amp

Edit: it looks like there is still no way to use the provided BMS SOC% for other than display purposes. So for example settings 12 and 13 are still battery voltage dependent. At least, they probably use the BMS battery voltage, but still, not all you'd want.

Edited April 22, 2020 by Coulomb
Oops! Left out the all-important SOC field; "b" -> "c" field near the top. Also fixed first line. eee field likely 3 digits max.

[charlez]

1 hour ago, Coulomb said:

If anyone wants to try to use these new BMS features, here is the format of the appropriate command. I believe it needs the usual Axpert CRC characters at the end, and of course a terminating carriage return. I haven't checked the "polarity" of the "b" field.

;
; ^ D n n n B M S aaa b ccc dddd e fff ggg hhh
; 0 1 2 3 4 5 6 7 8
;
; nnn is command length

; Next fields are variable length, space separated:
; aaa is BMS battery voltage, tenths
; bbb is BMS SOC, pecent 0-100
; c is 0 or 1 for discharge or charge current
; ddd is BMS battery current
; eeee is 8 warning flags 0-255 (not used at present)
; f is 1 for force charge; 0 otherwise
; ggg is BMS CV voltage, tenths of a volt
; hhh is BMS float voltage, tenths of a volt
; iii is BMS max charge current, tenths of an amp

Edit: it looks like there is still no way to use the provided BMS SOC% for other than display purposes. So for example settings 12 and 13 are still battery voltage dependent. At least, they probably use the BMS battery voltage, but still, not all you'd want.

@Coulomb thanks for this info. But as you said earlier they may provide a setting later using SOC. What software are you using to manage your inverters? This is what I can get out of my Narada batteries. Just passing a couple of fields to emoncms and not being used. Using the voltage to switch and not ideal.

temp::[31.0, 32.0, 31.0, 31.0] C
soh::100.0 %
status::[[], [], [], [('Charging', True)]] flag
packvolts::53.61 volts
soc::100.0 %
capacity::112.76 ah
addr::[1] BID
current::2.44 amps
cell_volts::(53.61300000000001, [3.554, 3.564, 3.567, 3.558, 3.549, 3.561, 3.564, 3.551, 3.567, 3.609, 3.613, 3.601, 3.587, 3.586, 3.582]) volts
cycles::330 cycles
 

[Coulomb]

3 minutes ago, charlez said:

What software are you using to manage your inverters?

It's a custom program in Node-red. We (Weber and I) were going to make the BMS public and sell them (the files are all available on Github), but realised it was going to be just too much trouble to maintain and support, so there are only three copies in use.

You should be able to turn that BMS data into a suitable command if you were interested.

[charlez]

On 2020/04/12 at 10:42 AM, APV said:

Sadly, the problem reoccurred tonight after a cloudy day!  I guess @BvR will have to take it up with Voltronic again

 

@APV I can confirm the problem persists, happened now after full day of cloud cover and on bypass mode.

[charlez]

Interesting this manual says 08 error is a firmware problem.

Copy_of_PIP-HS_MS_4-5KVA_new_Service_manual_201506A (1).pdf

[APV]

29 minutes ago, charlez said:

@APV I can confirm the problem persists, happened now after full day of cloud cover and on bypass mode.

Yes, mine did it as well.  At 19h00!  Around 18h20 it switched to bypass (as normal).  It was raining all afternoon, with an overcast morning.  I did try killing the soft start oscillator - however that kills the output as well!  So unfortunately stopping the oscillator is not an option.  I did oscilloscope traces on the control pin (from the CPU) of the soft start circuit when the problem was absent, as well as now., there is no difference.  The pin floats high in both cases.  So I guess I must start looking elsewhere for the problem.  As a final test, I am going to compare the waveforms of the soft start MOSFET in the two cases.  Just to be 100% that it is not the soft start circuit causing the bus voltage to go so high...

[APV]

7 minutes ago, charlez said:

Interesting this manual says 08 error is a firmware problem.

Copy_of_PIP-HS_MS_4-5KVA_new_Service_manual_201506A (1).pdf 2.66 MB · 1 download

It is a pity the Service Manual does not provide the circuit diagram - it would be so helpful (for me at least)...

 

[charlez]

That's way beyond me. A Google search seems to reveal that more people are experiencing the problem. Has to be firmware.

[APV]

40 minutes ago, APV said:

Yes, mine did it as well.  At 19h00!  Around 18h20 it switched to bypass (as normal).  It was raining all afternoon, with an overcast morning.  I did try killing the soft start oscillator - however that kills the output as well!  So unfortunately stopping the oscillator is not an option.  I did oscilloscope traces on the control pin (from the CPU) of the soft start circuit when the problem was absent, as well as now., there is no difference.  The pin floats high in both cases.  So I guess I must start looking elsewhere for the problem.  As a final test, I am going to compare the waveforms of the soft start MOSFET in the two cases.  Just to be 100% that it is not the soft start circuit causing the bus voltage to go so high...

Here is something extremely interesting!!!

The inverter currently is in its bad mood.  When you switch it off at the bottom, the bus voltage goes to zero.  When you switch it on again, the voltage quickly goes to 380V and then rises quite fast until it trips.  Out of sheer curiosity / desperation, I switched off the solar panels.  The bus voltage dropped to 380V in a matter of 30s!!!  Now remember - the unit is in bypass.  It is pitch dark outside.  I have measured the solar panel input - just about 0V.  So why the heck would removing the panels, "solve" the problem???

[APV]

3 hours ago, APV said:

Here is something extremely interesting!!!

The inverter currently is in its bad mood.  When you switch it off at the bottom, the bus voltage goes to zero.  When you switch it on again, the voltage quickly goes to 380V and then rises quite fast until it trips.  Out of sheer curiosity / desperation, I switched off the solar panels.  The bus voltage dropped to 380V in a matter of 30s!!!  Now remember - the unit is in bypass.  It is pitch dark outside.  I have measured the solar panel input - just about 0V.  So why the heck would removing the panels, "solve" the problem???

When the panels are disconnected in this state, there is a voltage of about 50V at the panel connector on the inverter.  I am going to insert a diode between the panels and the inverter and see if it makes any difference...

 

[StrikerX]

I have an Axpert VMII 5kva and got the "Bus Over" fault today (this happened a couple of times last year and the first time this year), not sure if it is related to this thread. Today this happened when utility went out for 15min and when utility came back, loads were anywhere from 300-500W during this time and battery was at 100%.

The inverter is approx 2.5yrs old so out of warranty now 

Edited April 26, 2020 by StrikerX