October 29, 20196 yr Author Hi @Wilfred Yes, Pylon to Axpert BMS communication won't work with a straight cable. Normally, when you order a "cable kit" from Pylontech, there are two UTP RJ45 cables in the box. One has white color and is labeled "CAN". Other cable is black. For a shame, none of these two cables will work with Axpert, nor InfiniSolar. For the Axpert, the best is to use a BMS cable that came bundled with the Axpert. If you did not receive such cable in the Axperts box, then just crimp it yourself using the wiring diagram above It's easy.
October 29, 20196 yr 1 hour ago, Youda said: Hi @Wilfred Yes, Pylon to Axpert BMS communication won't work with a straight cable. Normally, when you order a "cable kit" from Pylontech, there are two UTP RJ45 cables in the box. One has white color and is labeled "CAN". Other cable is black. For a shame, none of these two cables will work with Axpert, nor InfiniSolar. For the Axpert, the best is to use a BMS cable that came bundled with the Axpert. If you did not receive such cable in the Axperts box, then just crimp it yourself using the wiring diagram above It's easy. Thanks a lot, did only receive the black network cable from the Pylontech guys, and 0 cable from the inverter guys, I have sent your diagram to my IT guy, he will build me a nice cable :). Thanks a lot for you guys on this forum, would have been lost without you all. Regards, Wilfred
October 31, 20196 yr Ok, had a cable made and tried it today, still give error code 61, communication error. I am busy talking to the supplier of the inverters and will see if they have a solution for this matter. have a standard cross-over cable as well, just have not tried it yet. I am still running firmware 71.70 and will ask them if I can upgrade to 71.80 without loosing my warranty.
November 17, 20196 yr On 2019/09/03 at 9:55 PM, Youda said: during the last winter I had just 5 days where the inverters were forced to go into bypass. How do you heat your house?
November 17, 20196 yr Author How to charge your Pylontech US3000 and why From time to time, there's a discussion on Pylontech US2000/US3000 batteries and what is the best charging voltage for them. So, here's the answer based on my personal experience: C.C. = 52.5V C.V. = 52.0V Why: First of all, it's important to clarify what the term "charging voltage", sometimes referred as C.C. aka constant current, means. It's NOT the voltage that's being created by the charger and then applied to the battery terminals. In reality, the charger just pushes current into the battery, while constinuously measuring the voltage on the terminals. Once the voltage reading on the terminals is equal to the value that's set as charging voltage, the charger stops pushing current. Then, based on the selected charging profile, the charger goes in the next stage, like C.V. aka constant voltage, for example. If the C.C. voltage is set too high, the charger will continue to push the current in the batteries for too long. The voltage will rise above the safe level for that given battery chemistry and the cells will overcharge, swell and take damage. In order to protect the cells, US3000 has a balancer for each individual cell and a MOSFET for each brick. Once the voltage of the individual cell goes above 3.480V, the balancer will kick-in and start to burn the excessive current, turning the electric energy into heat. That's the way how US3000 ensures that at the end of charging all the cells have equal voltage, in other words "are balanced". Of course, cell balancers are not powerfull enough to burn all the energy that might be potentially pushed by the charger. That's the reason why there's a MOSFET in the battery pack. If all the balancers are already burning energy and the charger is still pushing energy, then the MOSFET will limit the current in order to protect the pack. In the specsheet, Pylontech recommend to set the charging voltage somewhere between the 52.5V to 53.5V: There's 15 LFP cells in each US3000 pack and balancers are starting at voltage 3.480V per cell: 15 x 3.480V = 52.2VSo, the setting C.C. to 52.5V (52.2V + 0.3V) ensures that all the balancers will operate correctly and at the same time, they won't be overloaded. If your solar charger is actively communicating with the US3000 via CAN bus or RS485, then he can read the battery voltage via this digital communication. Therefore, it does not matter how long the battery-to-charger cables are and whether the charger itself is measuring accurate or not. The voltage is measured by the BMS and communicated digitally. In that case, the best is to set C.C. to 52.5V. If your solar charger does NOT utilize BMS comunication, then he has to rely on his own voltage measurements. In that case, one has to take into account the length of the battery-to-charger cables, all the joints resistance and the associated voltage drop. Therefore, it might be necessary to adjust C.C. to a higher value, like 52.6V or 52.7V for example. There's nothing you can break if you will experiment and raise the C.C. slowly in order to find the best value for your setup. Just be sure to stay away from the maximum allowed voltage as described in the specsheet. While the specsheet allows charging voltage up to 53.5V, it's not a good idea: The higher voltage puts a higher load the balancers, mosfet and on the cells too. All the excessive energy is wasted and turned into heat. And the heat is generally not good for the cells, of course. Second reason, why setting the C.C. to the maximum is not a good choice is the fact, that during the charging there might be occasional spikes of power that will go to the battery. Sometimes these spikes are caused by the charger algorithm itself, sometimes they are caused by a changing light conditions or by turning ON/OFF bigger loads. Once this happens during the charging, and the battery is already at it's 53.5V maximum, the BMS will sense the overvoltage and throws an error. If not corrected immediatelly, it will shutdown the battery. How to set C.V. voltage: The LFP cells used in US3000 have a resting voltage 3.2V per cell. Technically, there's no "float" voltage that you need to apply to LFP, like is common in the Lead-Acid world. LFP cells are best to be charged and then disconnected. This is based on the fact that you can overcharge and damage a LFP cell even with 100mA of current, if applied for a long time. On the other hand, in solar applications it's impossible to disconnect the batteries from inverter once fully charged, since the batteries are acting as an energy buffer 24x7. Therefore, it's good to set C.V. to a value that will supply just a tiny amount of current into the batteries in order to keep them topped, and live with the fact that balancers will kick-in from time to time and will waste some energy by turning it into heat. With some other types of batteries, where balancers are visible, you can see this state - LED on each balancer blinks randomly, once per second or two. It's like a heartbeat. For a shame, Pylons don't have this direct visibility and you have to go into CLI, if you want to see what's going on inside the battery. Based on that, I'm personally using C.V. = 52V, so the balancers are not wasting excessive amounts of energy, and operate only when really needed. US3000 battery: Phantom BMS sitting inside a Pylontech battery: CLI info for a stack of 8xUS3000: pylon_debug>pwrsys Power System Information --------------------------------- System is discharging Total Num : 8 Present Num : 8 Sleep Num : 0 System Volt : 49756 mV System Curr : -17724 mA System RC : 558692 mAH System FCC : 588892 mAH System SOC : 94 % System SOH : 100 % Highest voltage : 3319 mV Average voltage : 3317 mV Lowest voltage : 3315 mV Highest temperature : 22000 mC Average temperature : 21500 mC Lowest temperature : 20000 mC Recommend chg voltage : 53250 mV Recommend dsg voltage : 47000 mV Recommend chg current : 118400 mA Recommend dsg current : -296000 mA Command completed successfully Note one interesting information: The stack has 592Ah of nominal capacity, but the recommended charging current, advertised by the BMS, is 118A = C/5. Recommended discharging current, advertised by the BMS, is 296A = C/2. No matter what values (much bigger) are being promoted in the specsheet, I would say that the battery designer had a very good reason why he hardcoded C/5 and C/2 into the BMS as recommended Amps. CLI info on the 1st brick: pylon_debug>info Device address : 1 Manufacturer : Pylon Device name : US3000A Board version : PHANTOMSAV10R03 Main Soft version : B65.6 Soft version : V1.3 Boot version : V1.4 Comm version : V2.0 Release Date : 18-09-12 Barcode : PPTAH02 Specification : 48V/74AH Cell Number : 15 Max Dischg Curr : -100000mA Max Charge Curr : 102000mA EPONPort rate : 1200 Console Port rate : 115200 Command completed successfully State of Health for 15 cells in the 1st brick: pylon_debug>soh Power 1 Battery Voltage SOHCount SOHStatus 0 3317 0 Normal 1 3317 0 Normal 2 3318 0 Normal 3 3317 0 Normal 4 3317 0 Normal 5 3318 0 Normal 6 3318 0 Normal 7 3319 0 Normal 8 3316 0 Normal 9 3316 0 Normal 10 3317 0 Normal 11 3318 0 Normal 12 3319 0 Normal 13 3317 0 Normal 14 3318 0 Normal Command completed successfully Statistics for the oldest brick in a stack of 8: pylon_debug>stat 8 Device address 8 Data Items : 0 HisData Items : 2048 MiscData Items : 122 Charge Cnt. : 0 Discharge Cnt. : 3180 Charge Times : 31004 Status Cnt. : 3179 Idle Times : 41151 COC Times : 0 DOC Times : 0 COCA Times : 0 DOCA Times : 0 SC Times : 0 Bat OV Times : 0 Bat HV Times : 0 Bat LV Times : 0 Bat UV Times : 0 Bat SLP Times : 0 Pwr OV Times : 0 Pwr HV Times : 0 Pwr LV Times : 0 Pwr UV Times : 0 Pwr SLP Times : 0 COT Times : 0 CUT Times : 0 DOT Times : 0 DUT Times : 0 CHT Times : 0 CLT Times : 0 DHT Times : 0 DLT Times : 0 Shut Times : 1 Reset Times : 14 RV Times : 0 Input OV Times : 0 SOH Times : 0 BMICERR Times : 0 CYCLE Times : 62 Pwr Percent : 95 Pwr Coulomb : 254001600 Dsg Cap : 4614627 [email protected] Cnt : 0 [email protected] Cnt : 0 HT Cnt : 0 LT Cnt : 0 LV Cnt : 0 LifeWarn Times : 0 LifeAlarm Times : 0 Command completed successfully Note the Cycle Times, this brick has 62 full cycles on it's meter. One full cycle is accounted whenever you discharge a full nominal capacity from the pack. Hope the above info will help someone to understand how to treat these batteries. Youda Edited November 17, 20196 yr by Youda
November 18, 20196 yr 19 hours ago, Youda said: Once the voltage of the individual cell goes above 3.480V, the balancer will kick-in How did you learn this? This sort of information is insanely useful to people making decisions about what software should do and I wish I knew about it sooner.
November 18, 20196 yr Author @plonkster the easiest way to verify this is to charge the stack of US3000 bricks to 99% SOC, while looking at the BatteryView.exe stats. You'll notice that US3000 brick is declared as 99% charged when almost all the cells are at 3.480V (+- few mV) and the rest of the cells at 3.450V at least. When you check each brick in a stack, one by one, you will notice the exact same state: almost all the cells have 3.480V, while one or two have 3.450V or 3.470V. These lower voltage cells have a bigger capacity than the others, I assume. So, the voltage that balancers are targeting is 3.480V and the 3.450V is the second condition that must be met in order to report full charge. See the screenshots. Details of 1st brick when 99% charged: Summary for stack of 7 bricks: Some more info: Phantom BMS in the Pylontech US3000 is using one Texas Instruments BQ34Z100 along with a set of BQ779XX balancers. These chips are pretty clever and power-efficient. For example, the max balancing current is only 50mA per cell. You can set not only a static balancing voltage value, but a whole voltage range where the cells will be balanced. Once all the cells are within this range, these 50mA balancers will try to make them equal. The 50mA is a very tiny balancing current, so the BQ779XX directly controls the chargeFET and dischargeFET in order to protect the battery from over/under charge, since the balancers alone are not powerfull enough to stop the charger from killing the cells. BTW, you can test these FETs directly from US3000 CLI, they are named cFET and dFET there. Also, you can see in the CLI that the above Texas Instruments chipset is set to ChemID = 435 in case of US3000. Based on the above, I would say that in each installation of US3000, there might be a different "balancing voltage" observed. However, 3.450V is clearly the minimum voltage that each cell have to reach in order to declare a fullcharge. And since there's a lot of cells in the brick and even more in the stack, one has to set C.C. a bit higher in order to ensure that ALL the cells in the stack sucessfully passed the 3.450V and are equalized at some other, a bit higher voltage. Makes sense? In short, this BMS has awesome design, that ensures high energy efficiency and longevity at the same time. It's a way better gear then I expected, to be honest. Regs, Youda
November 18, 20196 yr 31 minutes ago, Youda said: So, the voltage that balancers are targeting is 3.480V and the 3.450V is the second condition that must be met in order to report full charge. Thanks so much for the detailed answer. So basically, you derived this from 1) knowledge about the electronics used in the battery, and 2) observing what it does. It seems that at 52V, I'm just a tad over halfway between 3.45V and 3.48V per cell, which is why it does work for the most part. But 52.5V would obviously be just a tad better. @Ironman, I've set your charge voltage to 52.2V. I want to see if we go to 100% faster. At the moment I see it hang around 99% for an hour or so before it flips over. Edited November 18, 20196 yr by plonkster
November 18, 20196 yr Author Exactly. I think that most of the people at Pylontech don't even know how their products really operate. Which might be the reason why the documentation they provide to partnering vendors is so poor. The best charger for Pylontech would be the one that would pull all the states from the BMS and dynamically adjust charging current based on the info from the individual cells, like voltages, currents, temperatures. (Such detail is not available over CAN, only via RS485). But the complicated algorithms are prone to error and hard to finetune in the field. So, at the end of the day, just setting a nice flat C.C. voltage and checking the SOC from time to time is the best approach
November 18, 20196 yr 18 minutes ago, Youda said: The best charger for Pylontech would be the one that would pull all the states from the BMS and dynamically adjust charging current based on the info from the individual cells, like voltages, currents, temperatures. (Such detail is not available over CAN, only via RS485). But the complicated algorithms are prone to error and hard to finetune in the field. I agree with you partially. I prefer it when the BMS dynamically adjusts the charge voltage, essentially by summing the voltages of the cell plus a small offset required to get the current to move. This is much easier to work with in a DC-tied system. A current limit is a real pain when there are multiple chargers (multiple MPPTs and an inverter), because now you have to continually adjust the MPPTs to match the loads plus the required charge current, and as your loads move around... so your charge current goes over/under/over/under never quite hitting it. This becomes a lot of fun once the battery asks for zero charge current... A charge voltage makes it easy. Current can only flow if there is a potential difference. The end 🙂 Batteries that have dynamic voltages include the Victron HE series (Lynx BMS), the Discover AES battery, FreedomWon, and I've seen REC-BMS batteries also do voltage control (not sure if it is default or an option to be configured). This also allows the BMS to lower the charge voltage once the cells are balanced and thereby removing a bit of stress from them. Another reason why I was so impressed with the Discover AES battery. Sadly the Discover 42-48-6650, at 6.6kWh, is a 7000 USD battery, which puts it at just over 1k USD per kWh. a US2000 Pylontech rack (at around 2kWh) is around 16kZAR... which is also just a tad over 1k USD. So as nice as it is... the PTs has this fight down on the price. Edited November 18, 20196 yr by plonkster
November 18, 20196 yr An interesting and enlightening discussion. @Youda & @plonkster I have a question, that may influence a future system expansion, and this discussion is probably the most pertinent thread. In the future design, I am considering using Victron MPPTs and Quattros, and I am exploring Pylontech usage. My present experiments (using 3rd party MPPT's and LA batteries) show I can keep the MPPT going full tilt all day if I set their absorb voltage higher that the inverters' float and absorb voltage. I do this because I am exporting to an upstream system that has so much and many different loads that all the power is used without actually exporting onto the grid. I don't use any AC outs at all, I just dump all available power onto the upstream system. The inverters "export" all the power to maintain the float ( or absorb, as the case maybe) voltage, the batteries charge and the MPPT's track all day long. Every watt reduces the bill and there is no extra cabling on the load side of the inverters. That's what I want to achieve again. My question is, will maximum export still be available to me, if I go for Pylontechs and a full Victron system, or is fancy footwork in the BMS going to shut down the max export ability once the batteries are charged. - OR now, what should the settings be?
November 18, 20196 yr 6 minutes ago, phil.g00 said: My question is, will maximum export still be available to me, if I go for Pylontechs and a full Victron system, or is fancy footwork in the BMS going to shut down the max export ability once the batteries are charged. - OR now, what should the settings be? Right, you are talking about the "Feed in overvoltage" feature of the Multi. When you enable the "Feed in excess solarcharger power" option on the ESS menu, this is what it does. It instructs the solar chargers to charge at a higher voltage than the Multi is configured for, and then the Multi maintains the voltage by feeding power into the grid. If you use non-VE chargers, you can use this feature by setting their charge voltage a little above that which the Multi is configured for, and the same effect happens. When you use a managed battery like the Pylontech, the only difference is that the Multi no longer calls the shots. The battery does. The battery tells the system what the charge voltage should be, and PT asks for a constant 53.2V. 53.2V is however too high, because if we set the solar chargers higher than that (to facilitate feeding in of the excess), then we get dangerously close to 54V where the battery switches off. So there is a quirk built into the GX device. It ignores the charge voltage sent by the BMS and substitutes its own. It substitutes 52V. This allows enough room for things to continue working properly, so the solar chargers are instructed to charge to 52.4V, while the Multi attempts to hold the battery at 52V. This is what the discussion here is about: Whether this quirk might be a bit too much. At 52.5V we still have a good 1.5V margin. It's not as good as some other batteries, eg BYD, LG... all provide ample margin at the top before they freak out. The pylontech battery freaks out relatively quickly! Long answer short though: Your present setup of exporting everything can still be attained with pylontech batteries.
November 18, 20196 yr 1 hour ago, plonkster said: This is what the discussion here is about: Whether this quirk might be a bit too much. At 52.5V we still have a good 1.5V margin. It's not as good as some other batteries, eg BYD, LG... all provide ample margin at the top before they freak out. The pylontech battery freaks out relatively quickly! How quickly? I am happy with my present system performance (except the battery, which is shot). However I would still see voltage spikes and dips in normal operation. These perhaps last seconds, ( I have VRM logging set for 1 minute intervals). The spikes and dips aren't drastic, sustained or that often, but they are daily and can be about 4-5V about the steady state set point. After some random VRM world site visits, my fluctuations are perhaps lesser than most. The LA's handle this in their stride, will the Lithiums freak out? ....OR are spikes less pronounced with Lithiums by their inherent nature? 1 hour ago, plonkster said: Right, you are talking about the "Feed in overvoltage" feature of the Multi. When you enable the "Feed in excess solarcharger power" option on the ESS menu, this is what it does. It instructs the solar chargers to charge at a higher voltage than the Multi is configured for, and then the Multi maintains the voltage by feeding power into the grid. Lets say Eskom goes down, so exporting stops, will the ESS lower the charging voltages? (This is what 3rd party MPPT's don't do, and the voltage rises). Edited November 18, 20196 yr by phil.g00
November 18, 20196 yr On 2019/11/17 at 1:03 PM, Youda said: Note the Cycle Times, this brick has 62 full cycles on it's meter. One full cycle is accounted whenever you discharge a full nominal capacity from the pack. So currently mine get cycled down to 40-55% daily, how would the cycle meter react? I wanted to have a look at it, but with your disclaimer and possibly having issues later on, I am a bit hesitant
November 18, 20196 yr Author 100 days, cycled to 50% each day = 50 cycles on the meter. 5 minutes ago, PaBz0r said: I wanted to have a look at it, but with your disclaimer and possibly having issues later on, I am a bit hesitant
November 18, 20196 yr 1 hour ago, phil.g00 said: Lets say Eskom goes down, so exporting stops, will the ESS lower the charging voltages? (This is what 3rd party MPPT's don't do, and the voltage rises). Yes. The decision to raise charge voltages is made by the Multi, and if there is a reason why it cannot export (the grid code may specify a waiting period or a ramp rate for example, or the relay test was not performed yet, or the grid is out, or whatever), then the Multi does not raise the charge voltage. 1 hour ago, phil.g00 said: can be about 4-5V That sounds extreme. A DVCC system running ESS will set the solar chargers to 0.4V above the charge voltage requested by the battery (or the voltage we replace it with in the cases where we have a workaround implemented, eg 52V for pylontech). This means that at worst your batteries will rise to 52.4V. There is no regulation, ie if the Multi cannot feed all the power into the grid, it does not remove the 0.4V offset. The battery voltage simply rises that small amount. This was done on purpose: control loops always have a tendency to be unstable under some circumstances, so it is better not to have them unless you need them. A small offset does nothing to the batteries and avoids a control loop. If you run without DVCC, then the Multi uses a 4V offset and there is a control loop (the Multi raises and lowers the charge voltage as needed). This was only ever tested with LG batteries and Lead Acid, and because the GX device only syncs with the solar chargers every 3 seconds, that control loop is useless. Maybe this is what you see with your current setup. Short story: DVCC (distributed voltage and current control) is the new way. Use it as far as possible. Edited November 18, 20196 yr by plonkster
November 18, 20196 yr 12 minutes ago, plonkster said: If you run without DVCC, then the Multi uses a 4V offset and there is a control loop (the Multi raises and lowers the charge voltage as needed). This was only ever tested with LG batteries and Lead Acid, and because the GX device only syncs with the solar chargers every 3 seconds, that control loop is useless. Maybe this is what you see with your current setup. I do run with DVCC set off. I'll change it and see if it makes any difference.
November 18, 20196 yr 4 hours ago, plonkster said: I've set your charge voltage to 52.2V. I want to see if we go to 100% faster. Not today. Bad clouds - solar production went down to 10W from a 6000W array, over lunchtime! I could not believe that mid day dark clouds could bring down solar output that much! The battery went up to 94%, so I think my problem is solved - but they did not stay there - I don't think they balanced the cells properly.
November 18, 20196 yr Hi, Interesting to follow this. I have checked my cycles before and saw that they don’t go down exactly every 24 hours. I guess they will still cycle even if they are not taken down completely and get fully charged. I have 4x US3000’s, installed late afternoon 29/10, installed the ICC Pylontech cable on 1/11. The cycles were as follow: 1/11 = 2 2/11 = 3 (03:18) lowest SOC 34% 3/11 = 4 (20:22) lowest SOC 38% 8/11 = 8 (19:16) lowest SOC 21% highest 57% ( the weekend with the crazy clouds) changed settings to SbL to test the difference, the grid kick in at midnight for 1 hour (due to Axpert King firmware craziness), after a week I lowered the grid charge to 10A per inverter, to limit the grid consumption. 14/11 = 12 (05:32) lowest SOC 60% 17/11 = 14 (05:08) lowest SOC 70%, we were away over the weekend so not much loads over the weekend. It seems that the less loads you have and the less the batteries have to work, the longer it take to turn a cycle. So far I am happy, if the batteries will last 6000 cycles at 80% DOD, then my batteries should theoretically last more than 16 years lol if you want all the available data from 2/11 to today, I can send or post it Edited November 18, 20196 yr by Wilfred Add
November 18, 20196 yr Oh yes, the batteries will hover on 89% for an hour maybe 2 and then jump to 100% SOC.
November 18, 20196 yr Author 1 hour ago, Wilfred said: So far I am happy, if the batteries will last 6000 cycles at 80% DOD, then my batteries should theoretically last more than 16 years lol Oh, 16 years would be so nice! 🤣 But I think that if they will survive for 10 years, it would be still okay.
November 19, 20196 yr 14 hours ago, Wilfred said: 1/11 = 2 2/11 = 3 (03:18) lowest SOC 34% 3/11 = 4 (20:22) lowest SOC 38% 8/11 = 8 (19:16) lowest SOC 21% highest 57% ( the weekend with the crazy clouds) Is this from ICC or logging into the battery itself?
November 19, 20196 yr ICC, But something odd happened with my data last night. ICC must have lost something somehow. Show my grid watts went up to 1 044 310 watts, I am pretty sure if that happened something would blew up.
November 19, 20196 yr 10 minutes ago, Wilfred said: ICC, Wonder how accurate it is? Does ICC read these values directly or self determined?
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.