EG4 6000xp CANBUS Comms with Victron Smart Shunt w/DIY Battery

[Ai4px]

Currently it wouldn't work, CAN Bus has like a master slave relationship, and your 2nd inverter would respond same time as first - every packet gets a response from the inverter.

ummm that's not how canbus works..... a packet is sent and every single client on the line that recieved it correctly asserts the CAN-H and CAN-L line. Anyone who didn't decode the packet properly does nothing. So it doesn't matter if more than one client hears and ack's the message / packet.

Carrying this protocol forward... if no one responds by asserting the H-L lines, the sender assumes the packet was not recieved correctly and will typically retransmit. For this reason you must always have at least two on a network.

 

[sijones2010]

This code uses CANBus, not Modbus. CANBus ID's are documented in the code...

PYLON Protocol, messages sent every 1 second.

0x351 � 14 02 74 0E 74 0E CC 01 � Battery voltage + current limits
0x355 � 1A 00 64 00 � State of Health (SOH) / State of Charge (SOC)
0x356 � 4e 13 02 03 04 05 � Voltage / Current / Temp
0x359 � 00 00 00 00 0A 50 4E � Protection & Alarm flags
0x35C � C0 00 � Battery charge request flags
0x35E � 50 59 4C 4F 4E 20 20 20 � Manufacturer name (�PYLON �)

Thanks Seagal for correcting me, I had modbus on the brain for ages as was designing a fire detection system integration.

 

[sijones2010]

ummm that's not how canbus works..... a packet is sent and every single client on the line that recieved it correctly asserts the CAN-H and CAN-L line. Anyone who didn't decode the packet properly does nothing. So it doesn't matter if more than one client hears and ack's the message / packet.

Carrying this protocol forward... if no one responds by asserting the H-L lines, the sender assumes the packet was not recieved correctly and will typically retransmit. For this reason you must always have at least two on a network.

The CAN implementation is a specific variant for Battery/Inverter with specific implementation for each battery manufacturer and the inverter has to support each one.

For pylontech (and others but may use different ID's):

The CAN packet format is a 29 bit identifier used in the standard frame format, and the bus transmission rate is 500kbps, pretty much unidirectional other than a "Received packet" response to each packet received, packet ID 305 with 8 bytes of 0x00, only 6 packet ID's are implemented, using User-Defined battery type in Solis Inverters you can reduce the packets down even further.

The packets are sent in a way that every inverter on the bus would receive them and they would take them in, they don't know about each other, there is no way to send to one inverter so then all would reply with ID 305, the software (which I wrote) wouldn't understand the out of packet response.

I expect that the packet ID 305 on the bus and going in to the inverter from another one may cause it to alarm, the inverters aren't the most intelligent at handling the data, I have to be careful with my software otherwise it can hang the task that sends the CAN bus data.

This is why in my opinion it won't work.

I currently haven't seen any batteries or inverters that support parallel operation of CAN, all i've seen is single Battery to Inverter, the inter battery comms are over RS485, PylonTech have implemented paralleling of groups of batteries but one battery is still master, or you have to use there LV Hub, but again single inverter connection.

There are solutions out there where people have implemented parallel connections by receiving and replicating the CAN bus messages to each CAN Connection (completely separate hardware for each), which is what I intend to do in a future version of my software.

Have you yourself paralleled the can bus to multiple inverters and found it to work?

 

[Ai4px]

The CAN implementation is a specific variant for Battery/Inverter with specific implementation for each battery manufacturer and the inverter has to support each one.

For pylontech (and others but may use different ID's):

The CAN packet format is a 29 bit identifier used in the standard frame format, and the bus transmission rate is 500kbps, pretty much unidirectional other than a "Received packet" response to each packet received, packet ID 305 with 8 bytes of 0x00, only 6 packet ID's are implemented, using User-Defined battery type in Solis Inverters you can reduce the packets down even further.

The packets are sent in a way that every inverter on the bus would receive them and they would take them in, they don't know about each other, there is no way to send to one inverter so then all would reply with ID 305, the software (which I wrote) wouldn't understand the out of packet response.

I expect that the packet ID 305 on the bus and going in to the inverter from another one may cause it to alarm, the inverters aren't the most intelligent at handling the data, I have to be careful with my software otherwise it can hang the task that sends the CAN bus data.

This is why in my opinion it won't work.

I currently haven't seen any batteries or inverters that support parallel operation of CAN, all i've seen is single Battery to Inverter, the inter battery comms are over RS485, PylonTech have implemented paralleling of groups of batteries but one battery is still master, or you have to use there LV Hub, but again single inverter connection.

There are solutions out there where people have implemented parallel connections by receiving and replicating the CAN bus messages to each CAN Connection (completely separate hardware for each), which is what I intend to do in a future version of my software.

Have you yourself paralleled the can bus to multiple inverters and found it to work?

Parallel canbus to multiple inverters is exactly what SMA sunny islands do.

While there can be network segmentation in can bus the packets below 3FF are not gunna be special. They’ll still get the low level ACKs.