Jump to content

Axpert MKS II 5kW Error 08


Recommended Posts

So, an update to the above. "Bus over" fault occurred again few hrs later and at that time there weren't any issues with utility and PV was disconnected as well. Here's a QPIGS log

[2020-04-26 14:42:37](236.6 50.2 236.6 50.2 0402 0385 008 410 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:42:41](237.1 50.2 237.1 50.2 0402 0378 008 411 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:42:44](236.6 50.2 236.6 50.2 0378 0376 007 410 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:42:47](236.4 50.2 236.4 50.2 0405 0405 008 410 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:42:51](237.2 50.2 237.2 50.2 0403 0373 008 410 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:42:54](236.6 50.2 236.6 50.2 0402 0381 008 410 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:42:58](237.3 50.2 237.3 50.2 0401 0358 008 411 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:43:01](236.4 50.2 236.4 50.2 0378 0378 007 411 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:43:04](236.6 50.2 236.6 50.2 0378 0378 007 410 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:43:08](236.1 50.2 236.1 50.2 0401 0381 008 411 54.00 000 100 0041 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-26 14:43:12](240.5 50.2 000.0 00.0 0000 0000 000 421 54.00 000 100 0041 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-26 14:43:16](240.2 50.2 000.0 00.0 0000 0000 000 314 54.00 000 100 0041 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-26 14:43:19](240.0 50.2 000.0 00.0 0000 0000 000 172 54.00 000 100 0041 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-26 14:48:53](234.1 50.4 234.1 50.4 0187 0174 003 426 53.70 001 100 0040 00.4 389.0 00.00 00000 00010110 00 00 00174 110

The inverter shut off after 14:43

Edited by StrikerX
Link to post
Share on other sites
  • Replies 206
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

@charlez - I don't think the suppliers are even aware of this issue with the inverter! Here is the circuit The heart of the isolater, is the LD03-16B12 (AC/DC Converter Vin = 90-528VAC

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

@charlez has pointed me to this information from the official Axpert MKS II manual: 14. WARNING: Because this inverter is non-isolated, only three types of PV modules are acceptable: single cryst

Posted Images

I can't explain it.

After it faulted, the bus voltage read a very mild 421 V. However, it seems to have been dropping quite rapidly at that point, because the next measurement was 314 V, and 172 V after that. If that was a linear voltage drop (it would not be), it could have come from as high as 528 V, which would cause the bus fault. If as seems likely the fall was exponential, the initial bus voltage could have been even higher, but it depends on how long before the 421 V measurement the event occurred.

So whatever it was, it happened between QPIGS results (about 3-4 seconds apart, apart from the last one).

I wonder if any internal data (fault recording, perhaps the snatch graph) could help here. Can you post the results of a QFAULT command? If fault recording is on, that should give some useful information.

Edit: if fault recording is on, then this command should work long after the actual fault, recording data as the last fault occurred. It's stored in EEPROM, so even a power down should not affect this.

Edited by Coulomb
Link to post
Share on other sites

  

4 hours ago, Coulomb said:

I can't explain it.

After it faulted, the bus voltage read a very mild 421 V. However, it seems to have been dropping quite rapidly at that point, because the next measurement was 314 V, and 172 V after that. If that was a linear voltage drop (it would not be), it could have come from as high as 528 V, which would cause the bus fault. If as seems likely the fall was exponential, the initial bus voltage could have been even higher, but it depends on how long before the 421 V measurement the event occurred.

So whatever it was, it happened between QPIGS results (about 3-4 seconds apart, apart from the last one).

I wonder if any internal data (fault recording, perhaps the snatch graph) could help here. Can you post the results of a QFAULT command? If fault recording is on, that should give some useful information.

Edit: if fault recording is on, then this command should work long after the actual fault, recording data as the last fault occurred. It's stored in EEPROM, so even a power down should not affect this.

Here's what QFAULT read

[2020-04-27 15:30:17] [300ms] Return: (08 04 0400 0363 0042 534.8 54.0 235.5 50.26 234.2B?

If I am reading this correctly, bus was @ 534.8 when it shutdown? If it was, it makes no sense at all, everything else seems/looks normal.

p.s It hasn't happened again since yesterday. Moreover, I disabled battery charging during the day (they weren't being used anyways) and re-enabled charge from utility at night @ 2A only.

Edited by StrikerX
Link to post
Share on other sites
32 minutes ago, StrikerX said:

  Here's what QFAULT read

[2020-04-27 15:30:17] [300ms] Return: (08 04 0400 0363 0042 534.8 54.0 235.5 50.26 234.2B?

If I am reading this correctly, bus was @ 534.8 when it shutdown? If it was was, it makes no sense at all, everything else seems/looks normal.

So that's:

Fault code: 08

Work mode: 04 = Line mode

Output VA: 400 VA

Output power: 363 W

Inverter power: 42 W

Bus voltage: 534.8 V

Line voltage: 235.5 V

Line freq: 50.26 Hz

Inverter voltage: 234.2 V

As you say, everything else looks normal, with the possible exception of inverter power. According to your inverter status field of the QPIGS response, you were AC charging, so that 42 W is possibly power from the line into the inverter, which would push up the bus voltage. The battery was at 54.0 V, probably float charging a lead acid battery at 13.5 V per nominally 12 V battery module. 42 W seems reasonable to keep a battery floating.

All I can think of is that for some reason, the buck converter disconnected the bus from the DC-DC converter that would normally be transferring those 42 W into the battery. So then the 42 W would charge the bus capacitors. dV/dt = I/C ≅ 0.1/10⁻³ = 100 V/s. That could take the bus voltage from 421 V to 535 V in just over a second.

If that wild theory is correct, the question is: is this due to a hardware failure, or some glitch in the firmware?

Edit: the fact that the inverter voltage is slightly lower than the line voltage suggests that power is flowing from line to inverter output, which agrees with AC charging.

Edited by Coulomb
"absorbing" → "transferring into the battery"
Link to post
Share on other sites
5 hours ago, Coulomb said:

So that's:

Fault code: 08

Work mode: 04 = Line mode

Output VA: 400 VA

Output power: 363 W

Inverter power: 42 W

Bus voltage: 534.8 V

Line voltage: 235.5 V

Line freq: 50.26 Hz

Inverter voltage: 234.2 V

As you say, everything else looks normal, with the possible exception of inverter power. According to your inverter status field of the QPIGS response, you were AC charging, so that 42 W is possibly power from the line into the inverter, which would push up the bus voltage. The battery was at 54.0 V, probably float charging a lead acid battery at 13.5 V per nominally 12 V battery module. 42 W seems reasonable to keep a battery floating.

All I can think of is that for some reason, the buck converter disconnected the bus from the DC-DC converter that would normally be transferring those 42 W into the battery. So then the 42 W would charge the bus capacitors. dV/dt = I/C ≅ 0.1/10⁻³ = 100 V/s. That could take the bus voltage from 421 V to 535 V in just over a second.

If that wild theory is correct, the question is: is this due to a hardware failure, or some glitch in the firmware?

Edit: the fact that the inverter voltage is slightly lower than the line voltage suggests that power is flowing from line to inverter output, which agrees with AC charging.

It is weird and this is the first time it has happened in months. Also, I have 24x2V Shoto cells instead of 4x12V lead acid batteries.

Edited by StrikerX
Link to post
Share on other sites

Hello forum, 

I have pip5048mg and been running for two months without issue. Last night I have the same problem with error code 08. Waiting for a solution from this forum.

I have the bus voltage graph for my inverter. The line mode start at 5.30 PM, nothing happen until 8.40 pm when the bus voltage start to up. And at 11.55 pm the error occurred. 

Thanks. 

Screenshot_20200429-005523_Chrome.jpg

Link to post
Share on other sites
19 minutes ago, rddkrn said:

I have the bus voltage graph for my inverter

I don't suppose you have the battery current graph for the same period? It would help to confirm or deny my present theory. If you have separated charge and discharge current, whichever one was non-zero just before the bus over-voltage event would do.

Either you have pretty good data recording speed, or you were pretty lucky to catch the fault soon after it happened (showing just under the 500 V before the big drop). [ Edit: actually, your machine seems to have spent significant time just below 500 V, which seems to be different to @StrikerX's case. ]

Zooming in (on the time axis) to the event would also be helpful, but capturing the ramp up towards 500 V.

Edited by Coulomb
Link to post
Share on other sites
1 hour ago, rddkrn said:

Waiting for a solution from this forum.

I'm not sure that that will be forthcoming, at least from me. But I've had a few ideas.

I note that @StrikerX's data shows the bus voltage at 410-411 V, with the battery at 54.0 V. So that's a ratio of about 410/54 = 7.6. The transformer turns ratio has to be 8.0 or 7.0; I'll assume 7.0 (i.e. that this is a 64 V max model, not a 58.4 V max model). If the buck converter (between the inverter 400 V bus and the higher voltage end of the main battery-to-bus DC-DC converter) was in its common state of always on, this ratio would be locked to very close to 8.0. To achieve 7.6, it must be switching the buck transistor, allowing 410 V on the inverter, and 54.0 × 7.0 = 378 V at the DC-DC converter.

I believe that the buck converter has two main purposes. One is to allow charging of very low voltage batteries (e.g. 44.0 V) when more than (battery volts × 7.0) (in this example, 44.0 × 7.0 = 308 V) is not enough to produce a 230 V sine wave (needs about 230 × √2 + 12 = 337 V). The difference (in this example, at least 337 - 308 = at least 29 V) is dropped across the buck converter. The other is to allow "head room" to find tune the utility charge current if required, in case of a sudden change in either or both of the bus voltage or the battery voltage.

The buck converter, like the main inverter's output voltage, and PV charge current, are controlled by a PI (Proportional Integral) controller. This is industry standard practice. The Proportional  component does most of the work, but without infinite gain it can never achieve the required set point. So the Integral component is there to integrate the error terms and "close the gap" between the desired set-point and the actual measured value that is being controlled (be that output voltage, PV charge current, or utility charge current in the case of the buck converter). These things are a bit tricky, and require tuning of the various constants to get good performance with minimal overshoot and undershoot, and rapid attainment of the desired output.

Unfortunately, Axperts are renowned for their poor performance with over- and under-shoots. In particular, there doesn't seem to be any addressing of a problem known as "integral wind up". This can cause lithium batteries with BMSs to disconnect from the inverter, causing various problems. It can also cause lights to flicker. But in this case, I suspect that it might be causing the  bus over-voltage error.

Here is the scenario: when utility charging, the inverter is very sensitive to the phase of the incoming AC. The way inverters work, a sudden change in utility (or other AC-in) voltage will cause a sudden change in imaginary power flow; that should not change the bus voltage significantly. But a sudden change in utility phase will cause a sudden change in inverter real power flow. This will result in a sudden change in bus voltage. Bus voltage is a bit of a juggling act. Power is coming in or flowing out via the inverter; coming when the inverter is acting as a battery charger or going out when the inverter is powering loads. There is also possibly power coming in from PV charging. So I believe that there is a control system for bus voltage, but I'm not sure if it is a PI system or more a coordination of the other control systems.

So in StrikerX's case, he was utility charging. A sudden change in utility phase, possibly caused by a large industrial load kilometres away turning on or off, changes the bus bus voltage, let's say it drops 20 V. Now we have two control systems, one for the utility charge current, and one for the buck converter. Both of these are prone to overshoot, and to leave the system in overload for longer than necessary, possible because of integral windup. The combination of these two could see the bus voltage head too high for too long. It won't take long for tens of watts of power from the inverter-in-reverse to charge the bus capacitors (470 μF x 2 = 940 μF) to over 500 V. The bus voltage control system will allow the bus voltage to exceed 500 V, but only for a matter of milliseconds. Hence the error 08.

So @rddkrn, could we perhaps also see a zoomed graph of utility voltage around the time of the fault? Ideally, I'd want to see utility phase, but no measurement system is going to be able to record that. I'd expect that when a sudden change of phase occurs, there would be a sudden change of voltage with it.

It might be possible to figure out a patch for integral wind-up, which I might be able to debug on my own inverters, hopefully without blowing them up. I might then be able to port that to the firmware for these inverter-chargers with the 450 V or 500 V max Solar Charge Controllers, and it might work. There's a mighty lot of uses of the word "might" in this paragraph 😮

Edit: these PI control systems work best in linear systems, where a change of the control by x% results in an output change of something like Kx%, where K is nearly a constant. But with battery charging, there is a severe non-linearity. If you drop the bus voltage such that the DC-DC converted voltage falls below the battery voltage, my understanding is that the charge current drops suddenly to zero (the current doesn't smoothly change from positive (into the battery) to negative (out of the battery). This is because the buck converter isn't bidirectional, unless it turns on all the time (at which time it is locked into a 1:1 ratio). This 1:1 locking occurs in battery mode, but not in line mode when also utility charging. If they replaced the buck diode with a second IGBT, then it would be a bidirectional converter. But there is no need to go to that expense, so they don't. So my suspicion is that it's more likely events that decrease the bus voltage, causing the non-linearity to surface, that mainly trigger these bus over-voltage events. This is one of the theories I'd like to see supported or rejected by the data.

Edited by Coulomb
Link to post
Share on other sites

 

1 hour ago, Coulomb said:

I don't suppose you have the battery current graph for the same period? It would help to confirm or deny my present theory. If you have separated charge and discharge current, whichever one was non-zero just before the bus over-voltage event would do.

Either you have pretty good data recording speed, or you were pretty lucky to catch the fault soon after it happened (showing just under the 500 V before the big drop). [ Edit: actually, your machine seems to have spent significant time just below 500 V, which seems to be different to @StrikerX's case. ]

Zooming in (on the time axis) to the event would also be helpful, but capturing the ramp up towards 500 V.

I have the battery current graph. My data recording speed is 30 second.

battery charge discharge.png

bus voltage.png

Link to post
Share on other sites
1 hour ago, rddkrn said:

I have the battery current graph

Thanks. My theories aren't looking very good so far.

I'm curious about the large increase in bus voltage leading up to 21:00. Do you perhaps live at the north pole, where it's still light at 9pm?  😀  But then your system would have to be exquisitely balanced, for there to be no battery current showing. Perhaps you switched to line mode at sundown, around 17:30. Ah, the gentle bus voltage rise might be due to 2 A of utility current charging the battery, but losses eat up most of it, so it doesn't show up on the battery graph (as the charge current is less than 1 A, and has 1 A resolution).

Perhaps the event, whatever it is, at around 20:45 is the key to this. If the buck converter stayed locked at 1:1 so that the bus voltage is a fixed multiple of the battery voltage, then the bus over-voltage could never occur. Did anything significant happen at about that time? Load shedding perhaps? Edit: but then, there should be battery discharge current.

Edit 2: Could your water heater perhaps have come on at that time?

 

Edited by Coulomb
Link to post
Share on other sites
35 minutes ago, Coulomb said:

Thanks. My theories aren't looking very good so far.

I'm curious about the large increase in bus voltage leading up to 21:00. Do you perhaps live at the north pole, where it's still light at 9pm?  😀  But then your system would have to be exquisitely balanced, for there to be no battery current showing. Perhaps you switched to line mode at sundown, around 17:30. Ah, the gentle bus voltage rise might be due to 2 A of utility current charging the battery, but losses eat up most of it, so it doesn't show up on the battery graph (as the charge current is less than 1 A, and has 1 A resolution).

Perhaps the event, whatever it is, at around 20:45 is the key to this. If the buck converter stayed locked at 1:1 so that the bus voltage is a fixed multiple of the battery voltage, then the bus over-voltage could never occur. Did anything significant happen at about that time? Load shedding perhaps? Edit: but then, there should be battery discharge current.

Edit 2: Could your water heater perhaps have come on at that time?

 

I live at the equator, the sun sets at 17:30. You are right that I moved to the grid at 17:30. The mystery happened at 20.45 and at 23.50 
when suddenly the bus voltage rises quickly. My water heater only turns on during the day. The load at that night was three air-cond and two fridges (about 1500W). If this problem related to the loads, maybe at that time, all loads turned on at the same time.

Link to post
Share on other sites
3 hours ago, Coulomb said:

I'm not sure that that will be forthcoming, at least from me. But I've had a few ideas.

I note that @StrikerX's data shows the bus voltage at 410-411 V, with the battery at 54.0 V. So that's a ratio of about 410/54 = 7.6. The transformer turns ratio has to be 8.0 or 7.0; I'll assume 7.0 (i.e. that this is a 64 V max model, not a 58.4 V max model). If the buck converter (between the inverter 400 V bus and the higher voltage end of the main battery-to-bus DC-DC converter) was in its common state of always on, this ratio would be locked to very close to 8.0. To achieve 7.6, it must be switching the buck transistor, allowing 410 V on the inverter, and 54.0 × 7.0 = 378 V at the DC-DC converter.

....

....

...

So... it happened again in the morning around 6AM 😐 Hope this data helps

QPIGS leading up to the shutdown

[2020-04-29 06:17:54](240.6 50.1 240.6 50.1 0384 0344 007 410 54.10 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:17:57](241.6 50.0 241.6 50.0 0362 0349 007 410 54.00 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:00](241.2 50.1 241.2 50.1 0362 0347 007 411 54.00 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:04](242.2 50.1 242.2 50.1 0387 0353 007 410 54.10 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:07](241.8 50.1 241.8 50.1 0362 0340 007 410 54.00 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:10](241.7 50.1 241.7 50.1 0362 0339 007 410 54.00 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:14](241.9 50.1 241.9 50.1 0361 0334 007 411 54.00 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:17](241.9 50.1 241.9 50.1 0362 0348 007 410 54.10 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:20](241.8 50.1 241.8 50.1 0362 0347 007 410 54.00 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:24](240.3 50.1 240.3 50.1 0408 0384 008 410 54.10 000 100 0038 00.0 000.0 00.00 00000 00010101 00 00 00000 110
[2020-04-29 06:18:29](245.8 50.1 000.0 00.0 0000 0000 000 497 54.00 000 100 0038 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-29 06:18:33](245.7 50.1 000.0 00.0 0000 0000 000 422 54.00 000 100 0038 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-29 06:18:36](245.4 50.1 000.0 00.0 0000 0000 000 343 54.10 000 100 0038 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-29 06:18:39](246.1 50.1 000.0 00.0 0000 0000 000 249 54.00 000 100 0038 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-29 06:18:43](246.1 50.1 000.0 00.0 0000 0000 000 116 54.00 000 100 0038 00.0 000.0 00.00 00000 00000000 00 00 00000 010
[2020-04-29 08:24:48](235.6 49.6 235.6 49.6 0259 0196 005 429 51.90 000 097 0024 00.0 400.5 00.00 00000 00010000 00 00 00000 010


QFAULT

[2020-04-29 08:38:22] Send: QFS
[2020-04-29 08:38:22] [380ms] Return: (01 08 04 0361 0334 0040 240.8 50.16 239.9 50.13 000.0 561.2 54.0 038 204メQ
[2020-04-29 08:38:29] Send: QFAULT
[2020-04-29 08:38:29] [270ms] Return: (08 04 0361 0334 0040 561.2 54.0 240.8 50.16 239.9S~

 

 

 

Link to post
Share on other sites
40 minutes ago, StrikerX said:

So... it happened again in the morning around 6AM 😐 Hope this data helps

Indeed.

40 minutes ago, StrikerX said:

QFAULT

[2020-04-29 08:38:22] Send: QFS
[2020-04-29 08:38:22] [380ms] Return: (01 08 04 0361 0334 0040 240.8 50.16 239.9 50.13 000.0 561.2 54.0 038 204メQ

 

The "204" at the end of the QFS data is the important one to me. That's 0xCC or 0b1100 1100; bits 7,6,3, and 2 are on.

The meaning according to my notes is:

; Status: pic 999

; Bit 7: AC input relay (N side) on

; Bit 6: Line mode

; Bit 5: battery mode

; Bit 3: inverter relay on

; Bit 2: load relay on

In particular, the fact that bits 7 and 3 are on means that the AC-in relays are on, as well as the inverter relay. The load relay is on too. So that means that the inverter-charger is ready for utility charging, even though the battery charge current is zero. To me, that's asking for trouble; it's "standing on a barrel" when it has no need to.

It does confirm that a sudden change in line frequency will affect the bus voltage. Maybe that's all it is; if we can get the inverter relay off, then disturbances in line frequency/phase won't affect the bus voltage. Maybe the boost converter has little to do with it.

I'll see what I can find out.

Link to post
Share on other sites
6 hours ago, rddkrn said:

Hello forum, 

I have pip5048mg and been running for two months without issue. Last night I have the same problem with error code 08. Waiting for a solution from this forum.

I have the bus voltage graph for my inverter. The line mode start at 5.30 PM, nothing happen until 8.40 pm when the bus voltage start to up. And at 11.55 pm the error occurred. 

Thanks. 

Screenshot_20200429-005523_Chrome.jpg

This graph is useful. I will communicate it to Voltronic since I still believe they must solve the problem. Do you have the latest firmware on your Mks-II (71.80) ?

Edited by BvR
Link to post
Share on other sites
28 minutes ago, BvR said:

This graph is useful. I will communicate it to Voltronic since I still believe they must solve the problem. Do you have the latest firmware on your Mks-II (71.80) ?

I would like to hear if the following works for other people.  When error 08 appears, disconnect the solar panels.  Hopefully you have isolator boxes installed between the panels and inverter!!! It worked for me - the bus voltage dropped to its normal level of about 372V in a matter of 30 seconds. If it works for you too, I think a quick fix would be to connect the panels via a diode.  I am waiting for the next cloudy day to test my theory...

I know it is not the "proper" solution, but what the heck.  If it solves my problem, it is a quick, effective way to prevent a power disruption from a device that is suppose to prevent power loss :)  Even if (big if) Voltronic fixes the problem, I don't think it is too bad an idea.  You do not even have to open the inverter to apply the modification.

All of this is dependant on positive feedback , of course...

Link to post
Share on other sites
10 minutes ago, APV said:

I would like to hear if the following works for other people.  When error 08 appears, disconnect the solar panels.  Hopefully you have isolator boxes installed between the panels and inverter!!! It worked for me - the bus voltage dropped to its normal level of about 372V in a matter of 30 seconds. If it works for you too, I think a quick fix would be to connect the panels via a diode.  I am waiting for the next cloudy day to test my theory...

I know it is not the "proper" solution, but what the heck.  If it solves my problem, it is a quick, effective way to prevent a power disruption from a device that is suppose to prevent power loss :)  Even if (big if) Voltronic fixes the problem, I don't think it is too bad an idea.  You do not even have to open the inverter to apply the modification.

All of this is dependant on positive feedback , of course...

I have to mention error 08 is happening with my inverter with PV disconnected.

Link to post
Share on other sites
Just now, StrikerX said:

I have to mention error 08 is happening with my inverter with PV disconnected.

Like in physically disconnected, or only when it is dark?  In my case, it is dark and the inverter is in bypass mode when Error 08 occurs.  Only by physically disconnecting the panels, was I able to get the bus voltage to return to normal...

Link to post
Share on other sites
34 minutes ago, APV said:

Like in physically disconnected, or only when it is dark?  In my case, it is dark and the inverter is in bypass mode when Error 08 occurs.  Only by physically disconnecting the panels, was I able to get the bus voltage to return to normal...

If it makes sense, PV is disconnected from the inverter via a magnetic contactor. I have a net metering setup and the PV strings primarily go to the on-grid inverter and only when there is a grid outage does the PV gets switched over/connected to the axpert inverter. Primary role of the axpert at my place is to act as a UPS which it is failing at lol

Edited by StrikerX
Link to post
Share on other sites
10 hours ago, rddkrn said:

Waiting for a solution from this forum.

After a little more tinkering, I found that the 145 V max SCC models (e.g. Axpert MKS) allow the bus voltage to exceed 500 V for 10 seconds before fault code 08 is issued. In addition, they send an event to the supervisor task to switch to bypass mode (like line mode, but bleeds off the bus voltage).

In a VM III (500 V max SCC), the bus voltage has to exceed 510 V for 200 ms before fault code 08 is issued.

On Axpert MKS IIs / PIP-5048MGs, the bus voltage only has to exceed 500 V for 100 ms before fault code 08 is issued.

It looks to me that with neither the VM III nor the Axpert MKS II do they send the bypass mode event, at least not from the same part of the code. There may be a technical reason that some models can't use bypass mode to bleed down the bus voltage, and there may as a consequence need to be a much shorter timeout than 10 seconds.

It's even possible that the 10 second allowed time above 500 V contributes to blown IGBTs.

I wonder if 200 ms (as used in the VM III models, at least with main firmware version 20.59), instead of 100 ms, might fix a lot of these problems. But it's dangerous territory.

Link to post
Share on other sites
14 hours ago, Coulomb said:

In addition, they send an event to the supervisor task to switch to bypass mode (like line mode, but bleeds off the bus voltage).

As expected, there are other (circuitous!) ways of getting to bypass mode, so that's probably not so important.

14 hours ago, Coulomb said:

I wonder if 200 ms (as used in the VM III models, at least with main firmware version 20.59), instead of 100 ms, might fix a lot of these problems.

It would take me about half an hour to whip up patched firmware version 71.80b with this one-byte change. I can't get to it till tonight my time. Would anyone be interested in trying it? It would double the time that the bus voltage can be excessive before the inverter trips with fault code 08. But it's no more than what the manufacturer already uses in other, similar firmware (for VM IIIs). As I say, it's not without risk, so if no-one is game to try it, I won't bother.

Link to post
Share on other sites
16 hours ago, Coulomb said:

As expected, there are other (circuitous!) ways of getting to bypass mode, so that's probably not so important.

It would take me about half an hour to whip up patched firmware version 71.80b with this one-byte change. I can't get to it till tonight my time. Would anyone be interested in trying it? It would double the time that the bus voltage can be excessive before the inverter trips with fault code 08. But it's no more than what the manufacturer already uses in other, similar firmware (for VM IIIs). As I say, it's not without risk, so if no-one is game to try it, I won't bother.

I don't think you should spend time on increasing the time to 200ms.  The fact that the bus voltage goes so high, is by itself the problem.  So whether it goes above 500V for 1ms or 400ms, is irrelevant.  I feel safer with the system shutting down rapidly when the fault occurs (even though it should not occur at all).  But thank you for the offer :)

 

Link to post
Share on other sites
On 2020/04/29 at 10:23 AM, BvR said:

This graph is useful. I will communicate it to Voltronic since I still believe they must solve the problem. Do you have the latest firmware on your Mks-II (71.80) ?

@BvR how are you communicating with Voltronic? Would it help if we did the same?

Link to post
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...