CANbus networking of controllers

[menningd]

I've been thinking about the idea of connecting multiple controllers via CAN with the goal of providing aggregated data to Victron (or Pylontech, etc.) as one large battery. I figured I would open a Git Issue in case someone has already put more thought into this.
This functionality has probably been viewed as a bit of an edge case to date. Pylontech and Victron do offer the ability to daisy chain batteries. Besides the ability for further expansion, it also provides redundancy. For instance, in my case a 4s4p battery will be arranged so that there are 2x controllers configured as 4s2p which are themselves connected in parallel -each with their own battery disconnect. This way a fault with any cell only takes half the battery offline and maintains uninterrupted power.

Thoughts so far…
• Each controller has a configuration page option “Controller X of Y”. Where X is the sequential number the user assigns each controller and Y is the total number of controllers that will be networked.
• The controller # ‘X’ determines the hierarchy of the ‘master’ succession list. Controller 1 is default ‘master’ and is responsible for communicating to Victron. If Controller 1 fails to update then Controller 2 assumes the ‘master’ role and begins communicating with Victron.
• Some form of a heartbeat might need established to ensure all controllers are updating vitals regularly so that the ‘master’ can report out within Victron’s heartbeat window
• The controller # ‘X’ also determines the predetermined identifier or “address” range where each controller will be broadcasting its data. Whoever is elected ‘master’ is responsible for aggregating the data from these ‘locations’ to send to Victron
• I haven’t really gone into the rules used for aggregating each piece of data. Many are simple like grabbing the lowest module voltage. There may be some that require more careful thought...

[stuartpittaway]

Are you running batteries in an environment where they cannot ever be powered off or taken offline?

The idea you listed is fine, but we are venturing into a high availability style of design, potentially even safety critical system?

[menningd]

No, it's not that type of environment. I do recognize your concern about relying on this type of control for safety critical applications. That is not my intention. My particular installation will be on a boat where you take any redundancy you can get. But I don’t go offshore so it’s more of a convenience than safety critical (i.e. I don’t want the A/C to turn off in the middle of the night). I would still keep a manual battery isolator/selector to use the lead starting battery as a DC backup source for critical systems.

I guess some of the features of CAN protocol are already in the spirit of high availability design. CAN, just by nature of using it, would mean that every controller is simultaneously being exposed to all of the required data-it's there to grab. It seems like the logical continuation to seamlessly re-assign a 'master'.

[stuartpittaway]

Does Victron have no capability for multiple battery systems?

The trouble with CAN is that each controller would broadcast the same message Id's - so unless you can separate the physical CAN data lines, those messages would be mixed up and Victron would get confused.

Aggregation of those messages is possible - but things like state of charge are difficult to merge.

[menningd]

Victron does not support more than 1 (main) battery and likely never will. There are ways to setup aux batteries through VE.Direct (RS282) and it just shows up as another 'device' in the menu but it's completely separate from the main (not included in any SOC calcs, not part of DVCC, and doesn't display on the main page). The BMS-Can connection is a dedicated network just for handling BMS communciation so all critical information must go through there. As you say its only listening for a few identifiers (comprising one battery) so the data must be aggregated first.

SOC does require some post processing maths..

[stuartpittaway]

As you are looking at a 4s4P setup, a single controller would operate that size of battery without an issue.

Perhaps a different way to look at this, would to have a second controller sitting in a "standby" state waiting to take over?

It would need to electrically share the connections to the modules TX/RX and the CAN bus - not sure that would currently work without changes to the code and/or PCB.

[menningd]

I did consider setting up 4s4p on one controller but of course that doesn’t allow putting half the battery on separate contactors for redundancy.

I don’t think making a controller sit in standby is the way – unless you just mean the part of the code that would TX the Victron range of message identifiers. Any controller ought to still be actively TX’ing it’s data (with different identifiers) so that whoever will be reporting to Victron can speak on it’s behalf for full functionality.

Not sure a change in hardware is needed. If you daisy CAN H and CAN L off the terminals of one module to the next you would just solder blob JP1 on the last controller. Code changes of course…

From my view linking controllers in parallel affords: easier expandability, ability to isolate from hardware failures (cell/wiring), ability to isolate from controller (PCB) failure, the ability to parallel batteries with differing capacities, and support for more modules. Depending on the application- support for more modules could mean more balancing power, an option to improve comm speeds for those running really large systems regardless of any recent or future improvements to the hardware design, and may encourage those considering really high voltages to come down to safer levels.

[stuartpittaway]

Have you considered moving the fuse/contactor onto each bank of cells? So you have 4 battery banks with a contactor on each before they are paralleled?

You also need to consider the maximum current through those cells, can half the battery cope with the full load?

[menningd]

Have you considered moving the fuse/contactor onto each bank of cells? So you have 4 battery banks with a contactor on each before they are paralleled?

This does provide more granularity and was my first choice. There is an increase in the cost of the contactors, fuses, cabling/connectors (probably equivalent cost of another controller) but still don’t have the ability to isolate the problem automatically. As the code exists now you would see an alarm, then go manually isolate the problematic bank, login and reconfigure the controller down to 3x banks and startup again.

You also need to consider the maximum current through those cells, can half the battery cope with the full load?

Yes, half the battery is sized to comfortably run the maximum load.

[SergiCEES]

I will remain here to see if it gets any update. My case could be similar. I will have 8 packs 16s lifepo4 in parallel. Without a deep knowledge about the internals of the diybms. My thoughts are similar than menningd.

In my mind, each pack will have a contactor (another problem, for my case with 8 packs, is that there are only 4 relays, but it is another question) and will be a master contactor (on the busbar with all parallel packs).

The packs are listed from 1 to 8, the number 0 is the virtual pack (aggregation of all packs). So the pack 0 (virtual) is that communicates with the victron via CAN to regulate the voltage charge and current discharge.

The rules must be open to the user, for my case could be something like "accept all charge if at least 2 pack are >90% or less than XX voltage pack. If only 1 pack are >90% reduce charge (via voltage CAN) at XX volts (as in the last update)"

Seplos BMS is doing something like this with the last version of this BMS.

I think there are a lot of interest on multibank batteries (as can be shown in the victron community and in the [github project](Louisvdw/dbus-serialbattery#8 . He also had an [open issue regarding the Master BMS or virtual battery aggregation](Louisvdw/dbus-serialbattery#266 Also here we've an aggregation driver for dbus serialbattery, while isn't implemented officially)

[menningd]

I have been working on this and i think im very close to having something useful. Still doing a lot of cleanup.

The packs are listed from 1 to 8, the number 0 is the virtual pack (aggregation of all packs). So the pack 0 (virtual) is that communicates with the victron via CAN to regulate the voltage charge and current discharge.

I don't see any reason to explicitly define a virtual pack. The way i have it now, each controller is ready to be master ( aggregate and report to the inverter). They all constantly monitor traffic and the lowest addressed controller is elected master automatically if the current master controller goes offline.

The rules must be open to the user, for my case could be something like "accept all charge if at least 2 pack are >90% or less than XX voltage pack. If only 1 pack are >90% reduce charge (via voltage CAN) at XX volts (as in the last update)"

This is probably worth further discussion. Ive been thinking about this in terms of my setup which has a fairly small charge source relative to my pack size. So i was just going to use the minimum Max DVCC charge current value reported from any single controller to report to the inverter. Of course then that max current supplied by the charger will be shared by any parallel controllers so it would only ever see a fraction of that amount of current. Its not an accurate method but its the absolute safest. If we want to do something more accurate it will further complicate things. I have been trying to leave the CAN communciation completely separate from the other parts of the code especially when it comes to calculating DVCC parameters, etc. I suppose the next safest thing would be to take the minimum Max-charge-current and multiply it by the number of online controllers. Doing anything more accurate would require more integration into the existing DVCC code. Im not as knowledgeable at the actualy battery charge/discharge characteristics. Maybe somebody more knowledgeable can chime in and explain how it should be done .

[SergiCEES]

Thanks for the update!

I see your point about the virtual pack, from my point of view, it seems safe having a single virtual pack being the master than letting any of each of the batteries became the master depending on his state. Also, I think is going to be easy for the victron (or another inverter via CAN) to have contact with one single virtual BMS instead of switching BMS.

In your scenario, how do you connect all BMS to the unique CAN port? Victron (at least) assign 1 ID to each battery. It is possible to add more batteries, but only one could be the master (as can be seen in the dbus serial battery project).

Cheers

[menningd]

Also, I think is going to be easy for the victron (or another inverter via CAN) to have contact with one single virtual BMS instead of switching BMS.

There's really no communication between Victron and the BMS. CAN protocol is multimaster which means there is no direct communication between any nodes. Any node can broadcast a message and every node hears it. So basically the BMS broadcasts data values over the network and Victron hears them.  It couldn't care less who sent the message.  The only issue would be caused by multiple nodes broadcasting the same message ID at the same time - we avoid this by making sure there is only 1 master at any time. Victron does broadcast 2 status messages but we don't do anything with those.../

In your scenario, how do you connect all BMS to the unique CAN port?

You can daisy chain the CAN Hi/Low connections from Inverter to controller to controller, to controller, etc. The last controller will need the 120ohm resistor activated with a solder jumper. 

Victron (at least) assign 1 ID to each battery. It is possible to add more batteries, but only one could be the master (as can be seen in the dbus serial battery project).

I haven't looked at that project in depth. Can you point to exactly which section you are referring to? Assigning more than 1 battery to Victron is not particularly useful from my point of view- really just to see stats of a starter battery or something? As you say they only allow one "main" (let's not confuse the terminology you used here of "master"). And that is the one which allows you to control via the BMS-CAN port (thus the reason we need to aggregate).

[SergiCEES]

Sorry for my last answer, I've been out!

There's really no communication between Victron and the BMS. CAN protocol is multimaster which means there is no direct communication between any nodes. Any node can broadcast a message and every node hears it. So basically the BMS broadcasts data values over the network and Victron hears them. It couldn't care less who sent the message. The only issue would be caused by multiple nodes broadcasting the same message ID at the same time - we avoid this by making sure there is only 1 master at any time. Victron does broadcast 2 status messages but we don't do anything with those.../

I got it, Thanks

You can daisy chain the CAN Hi/Low connections from Inverter to controller to controller, to controller, etc. The last controller will need the 120ohm resistor activated with a solder jumper.

Sure, I understand it now.

I haven't looked at that project in depth. Can you point to exactly which section you are referring to? Assigning more than 1 battery to Victron is not particularly useful from my point of view- really just to see stats of a starter battery or something? As you say they only allow one "main" (let's not confuse the terminology you used here of "master"). And that is the one which allows you to control via the BMS-CAN port (thus the reason we need to aggregate).

It is here on the issue "handle multiple battery" at some point, they say that with the driver, the venus os is able to get all battery data, but only one is been used as the battery, the others only appear there to show values.

Louisvdw/dbus-serialbattery#8

Cheers

[lorenzo6201]

Any news about this. I have 13 banks , 13 modules , 182 cell modules. I would love to have data aggregation. I can test the code on my solar array or on a bench setup with 7 controllers and a spare growatt inverter.