I have Growatt SPF 5000 ES inverters, I connect them always with LFP batteries with BMS communication, also via RS485 only, I would like to know, some of the batteries I install have RS485 and CAN communication, which one is better ? And why ? The distance between the battery and inverter doesn't exceed 2m

Just 2 different communication protocols, none is better than other.

1 hour ago, zivva said:

Just 2 different communication protocols, none is better than other.

I beg to differ. CAN protocol has effortlessly taken over RS-485's market segment. Even though these two might seem similar, RS-485 lacks many features that gave CAN the ability to become superior. As a result, the CAN bus seems to be replacing it in most industrial applications. CAN is not only fast, accurate and robust, but it has many other features that RS-485 has failed to offer.

Right ... But in the present case, CAN or RS485 or even the Jurassic RS232 make no difference ...

18 minutes ago, zivva said:

... But in the present case, CAN or RS485 or even the Jurassic RS232 make no difference ...

Yes i agree.

4 hours ago, TaliaB said:

I beg to differ. CAN protocol has effortlessly taken over RS-485's market segment. Even though these two might seem similar, RS-485 lacks many features that gave CAN the ability to become superior. As a result, the CAN bus seems to be replacing it in most industrial applications. CAN is not only fast, accurate and robust, but it has many other features that RS-485 has failed to offer.

Yes, I agree with you. Because CAN has a elegant and deterministic data link layer, while RS485 only specifies the physical (electrical) layer. And as a result there is complicated adhoc protocol variations per RS485. For example, the Pylon RS485 protocol covers about 15 or more pages, whereas the identifiers for CAN is described on one or two pages.

What makes it worst is they use RS485 for the configuration computer to entertain settings, firmware download and logs etc.  Whereas can messages only contains info relevant to bms needs of the host inverter. 

BUT if the host inverter has implemented the RS485 exactly correct as intended, then there is no difference in performance from the consumers point of view. 

Edited July 2, 20242 yr by BritishRacingGreen

So why would companies bother to make CAN comms if they are what I see as "useless" in the batteries ?, as the RS485 does the same job if I got it right 

2 hours ago, BritishRacingGreen said:

What makes it worst is they use RS485 for the configuration computer to entertain settings, firmware download and logs etc.  Whereas can messages only contains info relevant to bms needs of the host inverter.

 The major problem in RS-485 is the congestion of signals. This is generally due to multiple nodes trying to send data simultaneously on the bus, resulting in overload. I.had this problem in an automation setup from a Siemens S7-300 plc sending data to multiple Lenz frequency drives synchronized to start up at exactly the same time but had endless problems. I then did a Can to Profibus convertion with means of Helmholz CAN bus gateway and it worked like a charm. 

Edited July 2, 20242 yr by TaliaB

16 hours ago, Taher Sylla said:

So why would companies bother to make CAN comms if they are what I see as "useless" in the batteries ?, as the RS485 does the same job if I got it right 

Cause some brands of inverters have chosen to only use CAN. For no particular reason as in that case RS485 does the job.

So to be compatible with those brands (SMA, Schneider, ...), BMS manufacturers use both protocols : RS485 & CAN ... And a dozen of variations for each of them cause it would be too easy if BMS communication was standardized ...

Edited July 3, 20242 yr by zivva

The automotive industry went through pretty much the same development phase.
The CAN bus technology was the only option ultimately post the numerous modules all feeding the main processing module.
Old K-line data lines sufficed up to the 90s but the ever increasing amounts of data and their buses dictated CAN bus transition for all manufacturers.
The demand on ever more data exchanges between Inverters and Batteries and other computer modules with their software analysis tools will ultimately saturate the RS485 technology.
Until such time the RS485 can still be used to do the basic BMS-Inverter comms. But the industry will eventually standardise with CAN just like the Auto industry did.
 

4 hours ago, zsde said:

But the industry will eventually standardise with CAN just like the Auto industry did

The automation industry has already pretty much adopted can bus as one of their fieldbuses. All midrange and higher  industrial microcontrollers  have can bus as standard these days , as is the case with uarts (RS232/RS485). Can bus has just so many advantages over RS485 in terms of protocol specification , real-time capability, deterministic latency  etc ,  etc .

BUT RS485/RS232 will stay with us for decades to come.  One of the reasons is Modbus RTU , which will never go away. It is the oldest and most  ancient transport protocol in the industry , but integrators just love it to no ends.  The main reason why RS485 will not disappear in the Lithium BMS industry is due to the need for user level configuration tools. All BMS manufacturers entertain a Windows-compatible app in order to change BMS settings , view logs , update firmware etc. Now the reason they dictate RS485 or RS232 for this , is because there exist a comprehensive layer of abstraction for serial UARTS . In short this is a UART-USB dongle  which exposes a subset of USB endpoints in order to create a unified CDC (Communication Device Class)  driver in Windows. The end result is the good old COM1,COM2,COM3 etc serial port enumerations that we grew up with. What this all means is you can grab a cheap CH340 dongle or an higher-end FTDI dongle , add a cheap RS485 driver chip , plug it into Windows and there you have exposed COM1 or COM2 . Now what this means is that the windows software developers of BMS  implements a standard serial port UART API , and it does not get easier.

In contrast , there exist no USB Emulation Class in the industry for can bus . So although  you do get CANBUS-USB dongles they are proprietary and you require a very special Windows driver for it , and you need to expose an API LIBRARY  in order for the third party to integrate the dongle into their application software. Furthermore CANBUS-USB dongles are expensive.

 

EDIT : Linux has a canbus stack called socketcan but it has not been agressively adopted like the CDC class for uarts . 

 

 

 

Edited July 3, 20242 yr by BritishRacingGreen