martynw

Yeah  I only did enough to get me the pack data (described in that example packet at the end of the documents).
At the moment my Inverter communicates over the RS485 port so I'm using the console and CAN ports for my own logging / reporting.  But I'm going to be switching the Inverter to the CAN port soon because their RS485 implementation isn't very good and I should get better results from the CAN port.
I just need to figure out how I can retain my own CAN port connection simultaneously, it's not something I've looked into yet but I'm hoping I can just split / parallel the cable and connect both the Inverter and my USB CAN on the RPi.
 

This works well for me:
https://www.inno-maker.com/product/usb-can/
It's just £18 on Amazon currently.
 
I believe that you can also use the serial console with the RS485 protocol, at least that's how I've been using it!
I've been sending it a:
7E 32 30 30 31 34 36 34 32 45 30 30 32 30 31 46 44 33 35 0D And getting back:
7E 32 30 30 31 34 36 30 30 43 30 36 45 31 31 30 31 30 46 30 44 34 35 30 44 34 34 30 44 34 35 30 44 34 34 30 44 34 35 30 44 34 34 30 44 33 45 30 44 34 35 30 44 34 41 30 44 34 41 30 44 34 42 30 44 34 41 30 44 34 41 30 44 34 41 30 44 34 41 30 35 30 42 43 33 30 42 43 33 30 42 43 33 30 42 43 44 30 42 43 44 30 30 30 30 43 37 32 35 42 46 36 38 30 32 43 33 35 30 30 30 30 32 45 35 35 33 0D These are the example packets from the RS485 document on page 24 / 25.
 

Yes, the BMS restricts the rate.
I found this out a few years ago because my stack is in the garage and the temperature in there got down to about 5°C during the first winter after I installed it.  The BMS limits both charge and discharge rates on a sliding scale depending on the temperature.
Since then I built a better stack with about 200mm of solid insulation around it and a proper heating and cooling system which helps to keep the temperature > 20°C in the winter and < 30°C in the summer.
This is the chart that I got for the US2000B, presume the newer models would have similar failsafes built in.
 
 
 

Hey,
Hope everybody is keeping safe during the current Covid-19 crisis!
Does anybody have any experience of running a mix of different Pylontech batteries?
I've got a Sofar Solar ME3000SP connected to SIX Pylontech US2000 batteries as follows:
 
2 x US2000B from 07/02/2017
2 x US2000 Plus from 28/02/2018
2 x US2000 from 04/06/2019
 
They are connected to the ME3000SP  via RS485 and one of the latest manufactured US2000 is the master.
The ME3000SP is supposed to automatically configure itself to the Pylontechs and it sets the following:
Battery Capacity: 200Ah
Discharge Depth: 80%
Over Voltage Protection: 54.0V
Max Charge Current: 65A
Max Charge Voltage: 53.2V
Max Discharge Current: 65A
Min Discharge Voltage: 47.0V
 
Based on other posts most of these seem correct, although the Battery Capacity is wrong - I can't change this in the settings, although I can override the other parameters if I want to, but I think the Ah is cosmetic only anyway as I don't think it's used anywhere.
 
In general the system is working well, but I want to ensure that it's set up optimally.
As well as the data I can retrieve from the ME3000SP I also have the Pylontechs being queried every minute via the console port so I get a pretty good overview of how the system is performing. In particular I've noticed that the amps remaining / % remaining in each pack can vary throughout a discharge cycle by quite a bit. 
Often the ME3000SP stops the discharge cycle a bit too early as it seems to use the lowest % remaining figure to govern when the Discharge Depth has been met, so for example yesterday it stopped the discharge cycle at 20% but only one of the packs was showing 20%, the others still had a few % more (ranging from say 21% to 25%).
Interestingly the newer US2000 and US2000 Plus always seem to track fairly closely together and the older US2000B usually always seem to have more left when the discharge cycle stops (sometimes I've seen these still sat at 28% for example). What sometimes happens then is that the packs seem to balance amongst themselves, i.e. the ones with > 20% discharge and the others charge.  Sometimes (but not always) this even gets to the point where e.g. all the packs then have ~ 22% in them and the ME3000SP will continue a discharge cycle for a few more minutes.
On a charge cycle they always seem to balance OK based on the data from the console, all cells seem to reach target voltages and all packs hit maximum amps / % remaining (they all show that "bump" in their graphs at the top end).
 
Shouldn't the Pylontech BMS manage the packs a bit better?  I'd have thought during the discharge cycle it would report a % remaining based on some sort of average across all the packs, as opposed to the lowest value?
From my research so far the BMS is also supposed to be able to sleep individual packs when they reach their own discharge depth and the other packs should carry on? That's my understnading from https://midsummerwholesale.co.uk/pdfs/pylontech-intercompatibility-guide.pdf although that in itself is a bit confusing as it mentions that the older US2000B packs only "sleep" when the SOC is <= 0%? As I understand it at 0% it would be dead and a pack should never be discharged that low?
My other thought is to increase the Discharge Depth setting a bit in the ME3000SP.  Since the four newer modules should go to 90% anyway then perhaps that would allow the two older packs to discharge closer to their 80% DOD target?  My only concern there though is that if for some reason the SOC on the older packs somehow became lower the ME3000SP would then allow them to go too far, although in fairness I've never actually seen that in any of the data I've collected so far - they always seem to be higher than the newer packs.
 
Thanks for any thoughts,
 
Martyn

Enclosed is the PDF, which I found to be quite OK for understanding.
The main problem was to extract the CANID from the message, as the CAN packet looks like this:
- First two bytes contain the 11-bit CANID, 1-bit RTF FLAG, 4-bit empty.
- In order to extract CANID you have to crop the empty bits and RTR flag bit.
- Then you have to move 11-bit number into 16-bit number in order to be able to process it in a standard variable

Once you have CANID extracted, reading the Pylontech's operational values, that are stored afterwards in the CAN packet is easy, as they are plain 8bit or 16bit numbers. So, you can use them directly. With the PLC, it's quite straightforward to talk to a CAN interface, as the machine provides you a memory region which is automatically updated whenever there's a new message on the bus. It gives you also a counter that informs you how many messages were received since you've last checked the buffer.
I can imagine that it will be a bit harder on the other platforms, but the logic is the same - just extract the CANID and then parse the memory buffer according to PDF.
Good luck!
 
 
PYLON BMS CAN-Bus-protocol-PYLON-low-voltage-V1.2-20180408.pdf

@youda do you have anything that you can share codewise with regards to processing the CAN protocol?
I did find a PDF which I think relates to the protocol but it's not particularly clear!
I've had some success with the RS232 / console side though, in comparison that PDF was much easier to understand.  I have that working nicely by polling the BMS once a minute, but the CAN broadcast would be useful for a more passive approach for realtime status.
 

No need to be sorry @Youda, your posts are always incredibly helpful to us lurkers 🙂
I'm just slightly jealous of your Pylontech stack not to mention your PV and entire lab setup!  I only have 6 x US2000 at the moment and a 10 panel 3.3kWh solar array.  In the UK, so trying to maximise PV usage and only use the grid overnight when it's cheaper (half price or less).
I will double check my cable, but was pretty sure it was correct, I continuity tested it end to end to make sure the pins were mapped right.
I did wonder if it needed to be a cross-over cable (like you would with RS232 / RS485) but everything I could see about CAN said it's not like that, but maybe worth a shot.
The only other thing I can think is that as the ME3000SP inverter is talking to the batteries on the RS485 side, perhaps that disables the CAN side?
 

All sorted 🙂
Turns out I'd misinterpreted the pinout from the CAN-USB manual, I'd assumed this was the pinout of the board side i.e. pin 1 is top row, far right when looking at the DB9 connector end.  But the pinout is from the perspective of a DB9 *plug* that plugs into the board, so pin 1 is top row, far left.
After sorting that, data is flowing nicely ....................... crazy fast though, need to work out how best to process it now.
I'm a Python or Node-Red (JavaScript) guy, what are you guys using?