CCL and DCL in new Capacity and Count modes does not take in to account "Allow to charge" and "Allow to discharge" #47
Comments
|
Would it be useful if I added the ability to be able to manually specify something like the "capacities" so it could be manually tuned? |
|
Battery capacity and BMS capacity are published in dbus and can be easily read. I think its a matter of limiting the computed values (whatever system is selected by user IR, Capacity and Count) and verify before publishing if battery is under protection for charging and/or discharging, and limit the value to the max bms capacity, if applicable. That should work with any computation. With dbus-serialbattery there is already implemented a max charge protection that could be based on SOC, Battery temperature or cell voltage. In this scenario batteries are well protected and the direct sum of CCL and DCL is enough. Other batteries like CAB BUS connected will take real benefit of your extra level of protection. So behaviour can be automated and all info read from dbus or CAN. I don't actually know if there is other connection type available for batteries... |
|
I already do this: for each battery I calculate the overall current reqd to reach its ccl then pick the lowest overall current as the aggregated ccl. I don't think there is anything additional I can do to know whether it is going to result in an overcurrent for a particular battery. Maybe what I could do is start at 90% of that value and slowly increase upwards. |
|
Yes, all good but when a Battery goes into protection, its capacity
shouldn't be taken in consideration for the total CCL if the charge is
closed and DCL if the discharge is closed. At the moment if I close the
charge of one battery to simulate a protection. The CCL does not change and
remaining battery goes to protection due to overcharge.
If Capacity is used, the ah remaining in that battery (protected one)
should be removed from the computation. Only remaining batteries ah should
be used.
Same with Count mode...
El sáb., 27 abr. 2024 15:28, pulquero ***@***.***> escribió:
… I already do this: for each battery I calculate the overall current reqd
to reach its ccl then pick the lowest overall current as the aggregated
ccl. I don't think there is anything additional I can do to know whether it
is going to result in an overcurrent for a particular battery.
Maybe what I could do is start at 90% of that value and slowly increase
upwards.
—
Reply to this email directly, view it on GitHub
<#47 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BFPOLCWQ57UABT7ALYYOAILY7ORXRAVCNFSM6AAAAABGYNJL4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBQGY3DAMZTGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
The code already tracks /Io/AllowToCharge etc and excludes disconnected batteries from consideration. Please turn on debug logging and capture what dbus messages are flying about so we can verify what is actually happening. |
|
Hello! Testing day today. But unfortunately if I follow your debug activation sentence, I get an invalid json file and I'm unable to do the test. That's probably a silly question but I'm stuck. Here is my json file. It only includes the exclusion of the installed victron shunt on position 6. |
|
Sure, Note, you can change the loglevel dynamically too. BatteryAggregator has a LogLevel dbus path that you can switch between DEBUG and INFO. |
|
Ok here the logs. The test has been performed First, disconnecting and connecting charge and discharge of battery ONE. this test result was correct. So behaviour as expected. The test is repeated with battery TWO. Here the reduced limit is not applied and regardless of the disconnection (chrge or discharge) there is no significant reduction in CCL and DCL. Here LOGS |
|
i repeated the test and now doesnt wotk with any battery. I did a reset of the cerbo gx |
|
Count mode is the only one that seems to work. Here logs |
|
What I'm expecting to see are /Io/AllowToCharge messages everytime a battery connects/disconnects. These are one of the messages that trigger a recalculation of the CCL. In the first log there was only ever one for disabling ACM1. Never one for enabling it. I think you need to ascertain whether this is being correctly set on the batteries, and maybe if for some reason the aggregator is not picking them up. Or whether the aggregator should be listening to some other alternative message instead. |
|
Hi. I send you an additional. Just changed to mode to IR |
|
here last log |
|
To check for inconsistencies between the batteries and aggregator, I've create a dbus_dump.py tool available in the latest version. Please run:
before and after a battery connection/disconnection. It'll write files to /data/dbus_dump_*. Please attach these files to this issue, thanks. |
|
may be something misssing? python3: can't open file 'dbus_dump.py': [Errno 2] No such file or directory |
|
You probably havent changed directories, try |
|
Hi. I wont be able to test untill next week initially. We keep in touch to prepare a remote session |
|
@pulquero Hi, if you want. About 1030 am, I'll be able for a remote session |
|
Good with me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
New modes does not take into account the Allow to charge and Allow to discharge if any of the parallel batteries goes into protection and the total CCL and DCL remains well pass the actual limits. Or may be we have a problem with the correlation of the battery capacity and BMS capacity. I mean, you may have a large battery ie, 460 ah. but a relative small bms like 150a. 430ah 0.5C is 215a (quite common charge rate). but the BMS has a lower capacity 150a. So maybe the problem I have with single battery with 230a 0.5C rate and a 150 BMS. Your limits computation may only have a C rate computation when actually, an smaller limit is BMS capacity.
It's a theory actually....
The text was updated successfully, but these errors were encountered: