Hi,

I am having problems with an Axpert MAX II 8K. It seems the firmware is no longer compatible with Pylontech batteries.

The inverters are new so I guess are running the latest firmware.

When the inverter is set to battery type PYL the Error 61 is occurring (lost communication).

Cables etc. are all ok, as is the Pylontech.

Another inverter I have is working fine.

(older) Firmware that is ok (pressing up arrow on the control panel):

U30000

U15401

U22208

Firmware that seems broken and does not work with Pylontech:

U30000

U2:22 12 (the 2 dots are actually 4 in a vertical line..)

U28101

Also, in addition to the 61 code, the inverter shuts down roughly 10 minutes after the error occurs. Changing battery type and it works ok so it seems the error is also triggering a shutdown. It 'should' just stop charging but I haven't yet been able to confirm if it does stop.

I'm waiting on a response from the supplier...

Anyone else seen this problem?

 

Edited December 25, 20223 yr by Acuario

7 hours ago, Acuario said:

U2:22 12 (the 2 dots are actually 3 in a vertical line..)

Can you show a photo of this, please? I'm intrigued. And it may be important. It may be that it's trying to indicate that there is a "1" here, or it might just be an artifact. Neither of the two round display firmwares I've looked at seem to do anything other than show "U2" and 4 single digits.

7 hours ago, Acuario said:

U28101

Do you mean U1 81 01?

One of the display firmwares I have is 22.20; it might be worth trying. It came with an Axpert Max II 10 kW, but the display firmware should be the same. Alas, I still don't know how to spot display firmware intended for the GigaDevice chips versus the ST Microsystems chips. I thought the former's firmware version numbers always were of the form 1xx.xx, but now I'm not sure. The 22.20 display firmware is in this post. [ Edit: But if you need 122.xx, then don't try this!! ]

Edited December 8, 20223 yr by Coulomb

Yes, finger trouble - U11801

Here is the photo

 

Thanks.

I'm guessing it's trying to say that it's version 122.12, but it doesn't quite have the segments to do it.

Do you have the phone app? if so, does it show the secondary firmware as version 122.12, or 22.12?

I should have added: if you find that you need 112.xx, then don't attempt to use 22.20!

I don't have the phone app but I have interrogated using the Communication API.

QVFW gives : VERFW:00081.01

QVFW3 gives: VERFW:00122.12

 

11 hours ago, Acuario said:

I don't have the phone app but I have interrogated using the Communication API.

Ah! Even better.

11 hours ago, Acuario said:

QVFW3 gives: VERFW:00122.12

Excellent! It seems that at least with the round display, they are attempting to show that you have (and therefore need if updating) display main firmware version 122.xx. Hopefully all the round displays with the GigaDevice chipset will have this.

The supplier has now accepted this is a problem and has referred it back to the manufacturer - we now wait..

I see there are several other posts on the same subject with Kodak inverters in September - have these been resolved as I guess it's all the same problem.

As a note, the command QBMS returns the battery connect status as 1 - disconnected on the 'non' working units.

So here is the story to date - and a work in progress fix for the brave..

No update on a firmware fix - I'm not holding my breath..

So how to fix? Simulate what happens when the inverter works correctly.

First step - capture the BMS messages and see what's happening - the critical phase is when the batteries are close to full charge - the charge current is slowly reduced from 150A to 10A.

The inverter continually polls the batteries for frames CID 61, 62 and 63.
The CID2 frame 63 contains the upper and lower voltage limits (53.25V and 45.00V respectively) and the current charge limit. The current charge limit is in A but seems to be 10% of the value set by the inverter. The inverter has various possible settings that can be obtained with the QMCHGCR command - in the case of the MAX II the values are 010 020 030 040 050 060 070 080 090 100 110 120 130 140 150. The chosen value is the nearest to the value that is available, i.e. if the value from the battery is 5.18A then the inverter sets the charge to 50A.

Reading the value from the frame 63 it is possible to send  MNCHGC messages to the inverter to control the charging current.

For anyone that wants to know the SOC from the batteries then this is available in frame 61

It seems that when the SOC is at 100% the inverter stops charging. In the QBMS message the battery stop charge flag gets set, and the charging status in QPIGS changes.
Monitoring the QPIGS and QPIGS2 messages it seems it doesn't stop totally as the power from the solar exceeds the power used.
According to the MAX Communication Protocol it should be possible to control charging (and discharging) using the PBATCD command but I just get a NAK when I try. I have seen this response from commands when they can't be used for some reason so maybe the conditions are preventing it's use - that's still to be investigated.

 

..to be continued..

On 2023/01/20 at 6:09 PM, Acuario said:

According to the MAX Communication Protocol it should be possible to control charging (and discharging) using the PBATCD command but I just get a NAK when I try.

My guess (it's late and I'm waay behind on posts) is that the display isn't sending the command through to the DSP. If you had a MAX 1  with the removable display, you could bypass the display (warning: totally different pinout than the RS-232 port) and talk directly to the DSP. I guess you could do the same on a Max II, but you have to open it up and figure out what connectors you need. If you're lucky, it will be the same as I have documented on the AEVA forum. 

I think it would be nice if the display didn't reject commands it doesn't know or care about, and just send them through to the DSP.

..an update

Interestingly the King inverter interrogates the CID 92 and 42 values rather than the '6X' series. 92 is almost identical to 63 and the Pylontech responds to both.

On initial startup both the MAX and King interrogate 4F, protocol version.

The reduction in charge current limit (from Pylontech BMS) starts from 90% SOC and reduces to 10% at 100% SOC. It is not linear however and does not correspond to the SOC readings. From 92% to 99% it stays at 80A and when it first hits 100% it is still at 40A.

Simulating the charge reduction can be done in 3 ways, reading the SOC from the console port and just using the SOC to approximate the charge reduction or from the RS485 or CAN ports and more accurately setting the charge current (as the inverter/BMS link does normally - when it works!)

 

I read in various places that the common way to overcome the problems with BMS communications is to set the inverter to USE and then set the corresponding voltages.

This obviously works but there is no control over charge current. The batteries are obviously attempting to change this from the values observed from reading the charge current limit value from the BMS. Question is; will continuing to charge at a higher charge rate than the charge current limit when the batteries are approaching full charge have any adverse affect on the life of the battery?

 

Edited January 28, 20233 yr by Acuario

2 hours ago, Acuario said:

Question is; will continuing to charge at a higher charge rate than the charge current limit when the batteries are approaching full charge have any adverse affect on the life of the battery?

I'd say that's a yes. By definition, the current limit set by the BMS is the highest safe current. Charging at currents higher than that will cause some cells to over voltage; that's always bad for cell life.

That's what I suspected. So bad news for anyone setting USE with voltages on Lithium batteries then...

I did see mention somewhere that Pylontech require that their batteries are correctly charged (I guess according to the values from the BMS) for the warranty to be valid.

Can anyone confirm this? Do other manufacturers stipulate the same conditions?

20 hours ago, Coulomb said:

I'd say that's a yes. By definition, the current limit set by the BMS is the highest safe current. Charging at currents higher than that will cause some cells to over voltage; that's always bad for cell life.

If i was to implement a poor mans BMS control subsystem, whereby I have a small broker (raspberry) that reads bms messages from a battery and on the inverter side sends rs232 messages to the inverter to control charge current and voltages,  would I experience critical flash wear eventually on the dsp, lets say when i perform up to 20 setting changes a day. 

Or lets day 10 000 changes a year. I am not sure what modern flash ram ratings are. 

Edited January 29, 20233 yr by BritishRacingGreen

A good point. I guess that is already catered for as when the charge current changes as a result of the BMS message the inverter saves the setting (this can be confirmed by going into the programming or reading the QPIRI message).

I don't know where they would store the valued, it could be in flash or EEPROM, the latter has a much higher maximum number of write cycles (over 1 million) so even at 20 changes a day it would last over 130 years. It depends on the storage medium but I don't think it's something to worry about.

34 minutes ago, Acuario said:

as a result of the BMS message the inverter saves the setting (this can be confirmed

That is very true, great observation.

But it remains a question wether that readings are stored in persistent storage. In other words does the same reading exist when the inverter is rebooted without bms comms. 

@Acuario it is such a sad state of affairs these BMS protocol hell that so many users experience on various machines and battery types.

Without jumping the gun too early (hopefully you may still find a direct solution), I would like to point out that the Voltronics LIB PROTOCOL is reasonably documented, its transport protocol is standard RTU MODBUS. I have paired non supported BMS with Axpert using this protocol, by employing gateway hardware (eg raspberry, rockpi etc). 

So keep this in mind if you do hit a deadend. 

Also I want to develop a very low cost gateway based on the raspberry pi pico W(the one with wifi)  that supports one CAN channel and one RS485 channel. If there are interest in this regard i would like to invite people with your knowledge level to participate. Such project will be open source, community driven. 

My goal is a controller under 300 rands(!), excluding enclosure.  Want to start with it when autumn comes. 

 

6 hours ago, Acuario said:

A good point. I guess that is already catered for as when the charge current changes as a result of the BMS message the inverter saves the setting (this can be confirmed by going into the programming or reading the QPIRI message).

From memory they use something like the PBMS command (not available to users unless they bypass the display, not so trivial with round display models), which I thought just used a value in RAM. Though I just checked and I don't see it in firmware version 90.06, so I'll have to check again.

Users do seem to report that settings change at least from time to time.

The other thing is that every command that potentially saves a new value to EEPROM checks to see if the value hasn't changed, and if so doesn't re-write the value. So then you have over a million changes of the EEPROM value before you theoretically are at risk of running into EEPROM wear issues.

6 hours ago, BritishRacingGreen said:

I would like to point out that the Voltronics LIB PROTOCOL is reasonably documented,

As a point of interest, where is this documented?

1 hour ago, Coulomb said:

As a point of interest, where is this documented?

Attached  is protocol. Its nowhere referred to as Voltronic Lib, but Easun. 

When connected, the inverter is modbus master, and interrogates registers 0x30 to 0x34.and 0x70 to 0x74 periodically , and never anything else. Of course I am only specifying one pack only. 

 BMS communication protocol 20201202 (2).pdf

EDIT : Sorry  0x30 - 0x36 , 0x70 - 0x74  

 

//---------------------------------------------------------------------

// MKS3 BMS LIB PROTOCOL : TEST DATA

//---------------------------------------------------------------------

    /*bms_mb_ram[0x30] = 200; // module charge current (unit = .1A)
    bms_mb_ram[0x31] = 250; // module discharge current (unit = .1A)
    bms_mb_ram[0x32] = 527; // module voltage (unit = .1V)
    bms_mb_ram[0x33] = 73; // SOC (unit = %)

 /*   bms_mb_ram[0x34] = 0x0001; // total capacity in mAh (4 bytes)    120Ah
    bms_mb_ram[0x35] = 0xD4C0; // 120Ah */ 

    bms_mb_ram[0x36] = 1; // number of online packs

   /* bms_mb_ram[0x70] = 539; // charge voltage limit (unit = .1V)
    bms_mb_ram[0x71] = 498; // discharge voltage limit (unit = .1V)
    bms_mb_ram[0x72] = 250; // charge current limit (unit = .1A)
    bms_mb_ram[0x73] = 250; // discharge current limit (unit = .1A)
    bms_mb_ram[0x74] = 0x00C0; // control flags
    //bms_mb_ram[0x74] = 0x0000; // control flags*/

    is_bms_data_valid = true;

Edited January 29, 20233 yr by BritishRacingGreen
Extra info

From my tests to date I've not seen any activity from the Axpert on the CAN port, only on the RS485 where it requests data from registers 0x46, 0x61, 0x62, 0x63 in the case of the MAX and 0x42, 0x46 and 0x92 in the case of the King. 

The Pylontech outputs CAN data ID: 0x351, 0x355, 0x356, 0x359, 0x35c and 0x35e in a continuous stream.

I've tried using the RS485 connection and requesting data but it has proved complex for some reason - the receive buffer on my ESP32 does not seem to want to play kindly so I end up with responses out of sync with requests and as the reply frame does not contain any indication of what it is replying to it's impossible to guarantee the results. It seems to be related to the RTOS tasks as in a non RTOS program it works happily..

So moving to CAN some of the same data is available (or at least what I need to simulate the BMS link). Fortunately when I designed my PCB I made provision for a CAN interface so it was fairly easy to move to that.

I now have code running that reads the CAN data and based on the data sets the inverter charge current. As an additional extra it also sets the battery type and float/bulk/shutoff voltages so these can be changed from the defaults that the BMS sets (which, in another topic, were deemed to be too high).

 

1 hour ago, Coulomb said:

From memory they use something like the PBMS command (not available to users unless they bypass the display, not so trivial with round display models), which I thought just used a value in RAM. Though I just checked and I don't see it in firmware version 90.06, so I'll have to check again.

PBMS on the round display versions returns NAK. The only BMS message that works is QBMS. It returns

QBMS:
(0 051 0 0 0 532 532 450 0150 0220

which fits with the PBMS data as documented.

7 minutes ago, Acuario said:

From my tests to date I've not seen any activity from the Axpert on the CAN port, only on the RS485 where it requests data from registers 0x46, 0x61, 0x62, 0x63 in the case of the MAX and 0x42, 0x46 and 0x92 in the case of the King. 

The Pylontech outputs CAN data ID: 0x351, 0x355, 0x356, 0x359, 0x35c and 0x35e in a continuous stream.

I've tried using the RS485 connection and requesting data but it has proved complex for some reason - the receive buffer on my ESP32 does not seem to want to play kindly so I end up with responses out of sync with requests and as the reply frame does not contain any indication of what it is replying to it's impossible to guarantee the results. It seems to be related to the RTOS tasks as in a non RTOS program it works happily..

So moving to CAN some of the same data is available (or at least what I need to simulate the BMS link). Fortunately when I designed my PCB I made provision for a CAN interface so it was fairly easy to move to that.

I now have code running that reads the CAN data and based on the data sets the inverter charge current. As an additional extra it also sets the battery type and float/bulk/shutoff voltages so these can be changed from the defaults that the BMS sets (which, in another topic, were deemed to be too high).

 

I implemented modbus on ESP32 way back in 2019 using Aduino lib for rs485 serial. That lib had a rs485 control line bug to enable half duplex arbitration. So i had to modify the lib at the time. If you have scope and you have access to the RS485 ditection control line, it will be worth to check that the control is correctly aligned with the intended direction of packet flow. 

Axpert supports WECO and SOLTARO canbus protocols, as per 2 years ago, may there are more now. . Axpert itself only consumes canbus frames, never produces. @Coulomb has reverse engineered Axpert firmware and documented  some canbus frames and data structures. Ask him to provide you with pointer should you be interested. 

7 hours ago, BritishRacingGreen said:

Also I want to develop a very low cost gateway based on the raspberry pi pico W(the one with wifi)  that supports one CAN channel and one RS485 channel. If there are interest in this regard i would like to invite people with your knowledge level to participate. Such project will be open source, community driven. 

My goal is a controller under 300 rands(!), excluding enclosure.  Want to start with it when autumn comes. 

It sounds roughly the same as what I have designed/developed. This is with an ESP32. The white sockets are for an LCD display and a touch switch. 

The user relay can be programmed to switch on/off depending on the SOC. 

I don't know how much 300 rands is - but according to the currency calculator it's just over 16 euros - I don't know the price of the raspberry pi but I thought they were more than that. 

10 minutes ago, Acuario said:

It sounds roughly the same as what I have designed/developed. This is with an ESP32. The white sockets are for an LCD display and a touch switch. 

The user relay can be programmed to switch on/off depending on the SOC. 

I don't know how much 300 rands is - but according to the currency calculator it's just over 16 euros - I don't know the price of the raspberry pi but I thought they were more than that. 

Well done, You beat me to it😎

I am reffering to the Rpi PICO W. Its an embedded controller not unlike the ESP32, less hardware resources, but goes for 5 dollar. So my budget is about R120 rand for the pico and 180 rand for a carrier pcb with CAN PHY and RS485.  

EDIT: the pico lacks can controller, but a clever engineet from UK has implemented a PIO driven MAC layer and some soft bit banging, all within the pico, with an overhead of only 30% load on one of 2 Cortex cpu cores. This is what inspired me to go this route. 

Edited January 29, 20233 yr by BritishRacingGreen