question

teemischer avatar image
teemischer asked

Maximum Limit of DCL and CCL numbers

I have a rather large battery bank (10584ah with 7200amps of discharge limit) and venus showing wrong values: Something is limiting the numbers shown in CCL and DCL

1720970402915.png

(CCL is zero here because batteries are full, sorry for bad timing of the screenshot)

So the DCL is 3276.7 which is wrong, the correct number should be 7200amps.

(BTW, this number is obviously 2^15=32768 divided by 10)


Something seems to limit this number, it could be:

- Venus OS

- Venus GUI

- CAN BUS encoding

- BMS sending wrong values

Does anybody know where the limit comes from?

How can I dig deeper to find out?

Venus OS
1720970402915.png (30.7 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

2 Answers
Alex Pescaru avatar image
Alex Pescaru answered ·

Hi @teemischer

Probably from the BMS / CAN bus messages.

According to the Pylontech protocol, protocol adopted by many manufacturers, the DCL should be encoded on 16 bits with a resolution of 0.1A

So for 7200 amps should be 72000 which is way beyond 16 bits storage. See below.

Alex

bms-ccl.jpg


bms-ccl.jpg (26.1 KiB)
2 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

teemischer avatar image teemischer commented ·

thanks, great insights. I am not running Pylontech though, but the Victron native CANBUS protocol.

Question is: Do I have the limitation in the Victron BMS CAN protocol?

The closet I could find to a documentation is this: https://github.com/Tom-evnut/VEcan/blob/master/VEcan.ino


Also: 0.1 * 2^16 should give me 6553,6 and not 3276.7

Maybe there is another cut-off elsewhere?



0 Likes 0 ·
Show more comments
Alex Pescaru avatar image
Alex Pescaru answered ·

Hi @teemischer

It says 16 bit signed, so from -32768 to +32767.

As for the BMS, the BCV, DCL and CCL are published by the Victron native CANBUS on the same CAN IDs. The BMS CAN bus driver is the same for all batteries.

Below a comparison table:

can-protocol-table.png


7 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

teemischer avatar image teemischer commented ·

great, thanks, that helps a lot, now I know the answer as to why I am not getting the correct CCL/DCL values into dbus.

Next Question would be: Since I cannot fix the CANBUS part of the problem, what do you suggest would be the best way to get correct values into dbus? I would be happy with fixed values that I manually set.

Possible solution, but not preferred:

I already successfully attempted to write the desired value via "dbus -y SetValue", but it gets overwritten every few seconds. My preferred choice would of course be to avoid running dbus cli commands in an infitie loop so I don't overload the GX device :-)

P.S.: I like the canbus documentation you posted and so I looked for this "Open Solar Energy" project, but googling around did not help much. Who are they and where can I learn more about them?

0 Likes 0 ·
Alex Pescaru avatar image Alex Pescaru teemischer commented ·

@teemischer

Info is taken from here.

I can confirm the information there because I've taken a look at the Victron BMS driver inside Venus OS and the CAN IDs this driver is processing.

Yes, the BMS driver inside Victron OS is overwriting those information as they come on CAN from BMS.

Problem is that the CCL could / would vary, according to BMS decisions, as the battery SOC changes.

So putting them manually there could be tricky.

If I were you, I would modify the BMS driver and delete inside that driver the calls to the function that writes - based on the info read on CAN ID 351 - the "Info/MaxChargeCurrent" and "Info/MaxDischargeCurrent" and then you are free to write them manually in your scripts, without being later overwritten.

Question is: later, the Victron scripts are correctly processing those big values?

Because, based on the specifications, maybe they also defined variables that can't handle bigger values... Only they would know.... :-)))

1 Like 1 ·
teemischer avatar image teemischer Alex Pescaru commented ·

@Alex Pescaru

thanks Alex, I will try to influence the BMS people to implement the protocol so that it just sends the values once and not regularly.


1 Like 1 ·
Alex Pescaru avatar image Alex Pescaru teemischer commented ·

You wont succeed with the influence part... :-)))

Also those values can change dynamically and they need to be sent.

1 Like 1 ·
teemischer avatar image teemischer Alex Pescaru commented ·

Let's see. BMS info/software is a special usecase I have here, we are not talking about some standard stuff like Pylontech batteries, but a setup which is very comparable with the battery safety controller project where the software part is much more open. (https://github.com/shining-man/bsc_fw)


And my values do not need to change or dynamically adapt. My batteries can take much MORE charge current than the victron setup is able to deliver. (2400a Quattro CCL and >10000a Battery CCL). I would be happy if the wrong/low BMS CCL numbers would not limit the currents to LESS than the Quattros are able to deliver.


1 Like 1 ·
Alex Pescaru avatar image Alex Pescaru teemischer commented ·

Then why are you connecting the BMS to Cerbo?

Don't connect the battery with Cerbo at all, configure the voltage and (max) current in the charger/inverter and let the BMS do all the work...

Am I wrong or am I missing something?

1 Like 1 ·
teemischer avatar image teemischer Alex Pescaru commented ·

Sorry for the late reply, I was on holiday.

The reason why I would still like to connect to the BMS is to get all the other readings like SOC, Warnings, Alerts etc.

But anyhow, for now my way is to use the aggregate_batteries in Venus OS. It basically proxies all the readings from the BMS and I can just overwrite whatever values I want in the python script before they get published to DBUS.

0 Likes 0 ·

Related Resources