BritishRacingGreen

My MAX7.2 has suddenly exposed a failure mode and is presenting fault code F52 on the LCD display. The internet and available documentation describe this fault as “Bus Voltage Too Low.” I have also tried to gather as much information as possible from this forum and others. However, based on what I could find, it appears to be a fairly random fault, and I could not locate any posts that led to a definitive solution. I have not opened the machine yet, as I want to gain as much insight into the problem as possible beforehand. So far, I have run the following functional tests, and in my case the failure is deterministic, not random at all. Test 1 Conditions: Battery available (52.7 VDC), NO PV, NO GRID When I switch the inverter on, it enters its diagnostic phase and then outputs 220 VAC on the load output. It also asserts a relay, most probably the load (inverter) relay. After less than one second, the 220 VAC collapses and the inverter shuts down, displaying F52 on the LCD. Test 2 Conditions: Battery available (52.7 VDC), PV ON, NO GRID (PV available under sunny conditions) When I switch the inverter on, it enters its diagnostic phase and outputs 220 VAC on the load output, again asserting the load relay. The output remains stable and no fault occurs. However, the PV does not charge the battery; it only powers the AC load output. The settings that allow PV battery charging are correctly configured. Test 3 Conditions: Battery available (52.7 VDC), PV OFF, GRID ON When I switch the inverter on, it enters its diagnostic phase and outputs 220 VAC on the load output, asserting the load relay. The output remains stable and no fault occurs. However, the grid does not charge the battery, even though the settings to allow grid charging are correctly configured. Initial AssessmentBased on the above conditions and observations, the F52 fault strongly suggests that the DC-DC converter, which is responsible for converting battery voltage to the internal bus voltage (and vice versa), is not functioning. This explains nearly all observations. The only apparent contradiction is why bus voltage exists initially (for about one second) when running in battery-only mode. After some thought, I realized that a bus soft-start circuit is present. The machine uses this low-power soft-start path to pre-charge the bus capacitors and verify bus integrity (checking for shorts, etc.). This accounts for the brief energy available to produce AC for about one second. The bus then collapses because energy is not replenished via the DC-DC converter. I am confident that the high-side IGBTs and low-side MOSFETs of the DC-DC converter are not blown; otherwise, the soft-start process would fail. My attention is therefore focused on the SG3525 PWM generator, which may not be enabling DC-DC operation. If the SG3525 itself is functional, then the initial transistor amplifier stages that drive the A and B phase outputs could be faulty. The ±12 V rails are another possibility, but I have largely ruled them out because these rails also power the measurement op-amps, and a fault there would significantly distort the readings. Of course, the DSP control board could also be at fault by not enabling the SG3525 PWM, or the opto-coupler driver stage may have failed. Another possible fault could be a failed buck IGBT, but I have tentatively ruled this out because the body diode should still allow some discharge path from the battery to the bus. I hope this assumption is correct. At this stage, my money is on the SG3525 or its associated circuitry. I certainly hope so, as I am not in the mood to replace power silicon given the amount of mechanical work required to rework this machine’s heatsinks. I will provide an update when I open the unit during the week, and hopefully this will help someone else in the future who has to deal with the same F52 fault.

This mission-critical requirement calls for an EMS (Energy Management System) capable of logging and reporting with high resolution and periodicity. Kindly let us know whether the system is equipped with an appropriate EMS. If you require any assistance in this regard, @Steve87 may be able to help.

Unfortunately, you have not provided any information regarding the inverter model, family (PCS/HPS) configuration, whether it has PV, or whether it is programmed to export power to the grid. I would like to make you aware that the ATESS circuit breakers for grid, load, and battery DC are not conventional types. In addition to their primary function of tripping when threshold currents are reached, they can also be triggered via a digital control input. When the control subsystem deems it necessary to gracefully degrade the inverter to a safe state, it sends activation signals to the circuit breakers to trip. For instance, this behavior can be observed when the emergency stop button is operated, causing these breakers to trip. This means there may be reasons other than current surges for the input circuit breaker to trip. The inverter will display an error code and a short description of the issue, which can be viewed on its LCD HMI display.

I have a question regarding the Nerada protocol . Does anyone know the alarm bit details as supplied in subcommand 6 and subcommand 10 of main main command 1 ( read analogue data) ?

for sending data , you shift all the bytes thru the checksum below starting from the first 0x7C/0x7E character to the end of payload. You then append the checksum byte as well as an 0x0D character. uint8_t nerada_485_checksum(uint8_t *buf, uint8_t len) { uint8_t b = 0; uint8_t b2 = 0; int num = 0; for (b = 0; b < len; b++) { b2 ^= buf[b]; num += buf[b]; } return (uint8_t)((uint)(b2 ^ num) & 0xFFu); } When receiving data , you shift all the bytes thru the checksum starting at the first character up to and excluding the checksum byte and the 0x0D character. You then compare your calculated checksum against the received check sum , and also check that the last character is indeed 0x0D.

While there are no standardized designs among lithium battery systems, my experience suggests that Pylontech has significantly influenced many OEMs in their philosophy of BMS (Battery Management System) communications. Moreover, the Pylontech protocol is directly compatible with those of several other manufacturers. A detailed protocol exists for use by the so-called "upper computer" (e.g., your laptop) to configure and monitor detailed metrics of a specific battery pack in your array. This protocol typically uses RS485 communication rather than CANbus. The primary reason is that laptops are more RS485-friendly due to the readily available connection dongles, while CANbus requires specialized adapters. Historically, neither batteries nor inverters supported CANbus. As a result, the same management protocol was also utilized by inverters to extract relevant metrics. However, this approach is highly inefficient because the inverter needs to implement the entire "bloated" management protocol, only to extract a subset of relevant data. This is where CANbus comes in. Pylontech introduced CANbus support, among other features, to provide a "clean" interface for inverters. The CANbus protocol only supports the essential metrics required by the inverter. For example, the inverter does not need details about the number of parallel packs or the energy capacity of each one. Instead, it treats the system as a single virtual pack. The BMS-to-inverter protocol typically includes the following: Absolute Maximum Charge Voltage: The maximum voltage that the inverter must not exceed during charging. Absolute Maximum Charge Current: The maximum charge current that the inverter must adhere to. Optional Absolute Maximum Discharge Current: The maximum discharge current the inverter may obey. Some inverters struggle to limit battery discharge during large load surges, relying on a brief forgiveness period before the BMS activates protection. Whether or not the inverter complies with this limit is less critical, as the BMS will intervene if necessary. State of Charge (SOC): The overall SOC of the virtual pack as a single averaged value. The pack master is responsible for calculating this value based on the SOC and capacity of its slaves. While SOC is not essential for primary charging functions, it serves as a convenience metric for higher-level features, such as timer-based scheduling. Optional Additional Metrics: When deemed appropriate, the BMS may send additional metrics via CANbus, such as maximum/minimum cell voltages or temperatures. Typically, inverters will read and silently drop or ignore these metrics without forwarding them to parent-level functions.

If you disconnect the fence load, does it still disconnect? Also, when running from battery only, does that makes a difference? Some Nemteks gets very hot mainly due to the linear battery charging regulator requirement. So I want to suggest that you check the temperature of the low voltage module's heatsink after 20 minutes or so.

is this good enough for grounding ? Asking for a friend.

I repaired my neighbour's Nemtek Wizzord recently. I have also noticed that the 12V battery had been run down to 0V. After repair of the low voltage board, I substituted the battery with a 12V bench psu and found when lowering this voltage that the unit 'cuts off' when voltage goes below 11V. This looks promising, except the microcontroller does not switch off and a current of 45mA is still being drawn. This of course depletes the battery over weeks or months, and destroys the battery. Please take note of this when energizer is unattended for long periods of time. Also the mains charging voltage is 14.0V. Isnt this a bit high for a continuous float charge?

Dry Joints and Axpert Error 06 Good day, hardware hackers. It’s only human not to share all of our failures on a public forum, but this one I need to share with you. I recently repaired a 5kW Axpert that had the dreaded Error 09. While there are worse traumas in life than Error 09, it is indeed problematic. Invariably, you need to replace 40-60% of the power silicon (MOSFETs/IGBTs), and it’s almost guaranteed that some gate drivers are faulty as a result of the big bang. I repaired the machine following my methods to bring it up in a deterministic 'soft' manner, and the initial test/verification went very well. However, a few days after the repair, I used the same machine to test a Pylontech US3000, which had a fried BMS power chain. About half an hour later, the Axpert displayed Error 06. I reset the machine, and either Error 06 appeared immediately again, or it would fail after a random period of time, which could be as long as one hour. Error 06 indicates that the AC output voltage is too high. Since there was no Bus Voltage Too High error, I suspected that the DC-AC full bridge might be at fault. This wasn’t due to clever deduction; rather, I knew that this bridge had been severely zapped during Error 09, resulting in the replacement of some gate drivers and gate resistors. Even though the full bridge was not faulty most of the time, I suspected the quality of the gate drive performance. I decommissioned the machine and disassembled it. The first thing I typically do is test the 47Ω gate drive resistor path from driver output to the IGBT gate pin. Guess what? One of those four paths had high resistance. It was a dry joint or a faulty resistor. The annoying thing was that it wasn’t open circuit but had an unstable value between 300Ω and 150kΩ (!!!!). I tested the resistor, which was fine at 47.2Ω, but I noticed a terrible solder joint on one pad. I tell you, I tested this circuit for continuity during the Error 09 repair. Nonetheless, I repaired the joint and checked all four circuits again. I reassembled, tested, burned in for 24 hours, and the Error 06 was gone. So, why the Error 06? Here’s my theory: We know that the IGBT gate has parasitic capacitance, which influences the switching times due to the RC time constant, where R is the gate drive resistance. The smaller we make the gate resistance, the shorter the gate switch-on or switch-off times will be. This explains the typical gate resistor values of 22Ω - 47Ω. We also notice in typical gate driver schematics that the driver DC supplies, referenced to the IGBT emitter, are asymmetrical (+15V and -5V). This means that the turn-off delay is somewhat longer than the turn-on delay in practice, because the gate voltage must discharge from +15V down to about the gate threshold voltage of 2-3V. This takes longer than switching the gate on, which requires raising the gate voltage from -5V to about 2-3V. This difference becomes significant when the RC time constant is quite large. The net effect is that the intended PWM duty cycle, controlled by the DSP controller, becomes distorted at the gate of the IGBT. As a result, your duty cycle ON periods will be longer than intended. This, in turn, causes the integrated voltage on the collector of the IGBT to become increasingly higher, leading to the “output voltage too high” error. I also believe that this is one reason why some IGBTs with large gate capacitances require a resistor anti-parallel arrangement. An additional resistor is connected in parallel with the gate resistor, but via a steering diode. The polarity of the steering diode is chosen to lower the net gate resistance when the IGBT is switched off (gate discharged). So, how do we test all this in practice? The first option is to have a dual-channel oscilloscope, with one channel connected to the DSP control signal and the other connected to the IGBT gate. However, these two signals are not in the same power domain, so I don’t typically go this route. One could connect the grounds together via suitable high resistors, probably in the order of 500kΩ - 1MΩ, but I haven’t tried that yet. The second option is to use only one channel and monitor the voltage across the gate resistor. This waveform represents the current through the gate and provides a lot of information. An example waveform is shown in the oscillogram below: The actual gate turn-on occurs during the positive-going pulse. This current pulse results from charging the gate capacitor to the 15V voltage level. The gate turn-off occurs during the negative-going pulse, which relates to discharging the gate capacitor. In this waveform, the period between on and off is about 6µs, so in practice, you need a 40kHz square wave to produce this as a test. Neither the gate charge pulse nor the gate discharge pulse plays a significant role due to their short durations. What I do is remove the DSP controller and inject a square wave on the relevant control pin of about 40kHz. Then I check the current profile as shown above. Under circumstances where the gate resistance is out of spec, you will see quite wide charge and discharge pulses. Cheers, and happy hacking!

Ok, then yes your total yield is a low in relation to 12 x 555W. You should be enjoying at least a good average of 4kw on peak if not more. What is the pv voltage when you drawing that odd 2kw from it.?

You say you get 1.6kw charge but what is the total yield of the pv? Maybe your load priiority is SUB or SBU in which case load is priority, then charging. So maybe the pv is delivering more than 1.6kw but is routed to load.

In order to stay safely away from the protection limits of the BMS, in the case where your rectifier is a dumb charger (no bms comms). Remember this : even without bms to charger communication, the bms can still perform its protection functions. A conservative charge voltage will not be able to get your pack to 100% SOC. But you have a use case where you dont need that. The hysteresis levels for triggering is typically 80% SOC generator off and say 40% SOC generator on.

One drawback is that generator must have enough capacity to both charge a depleted battery as well as supplying the load demand. If not the rectifier must have suitable current limiting capability. In an ac coupled arrangement the inverter can be configured to impose a lower charge current limit when it is in generator mode.