@Youda did you need to do anything to get the CANBUS data working?

I'm trying to connect to my US2000 master (I have 6 total connected to a Sofar Solar ME3000SP via RS485) using a USB-CAN interface ( http://www.inno-maker.com/wp-content/uploads/2019/02/USB-CAN-Module-Manual-v1000_EN.pdf ) on a Raspberry Pi.

All seems to be OK wiring wise based on the Pylon manual and I can bring up the can0 interface, but absolutely zero data flows :-(

Aiming to read the data via Node-Red eventually and transmit over MQTT, but first need to actually get some data!

 

Thanks for any pointers!

Martyn

11 hours ago, martynw said:

All seems to be OK wiring wise based on the Pylon manual and I can bring up the can0 interface, but absolutely zero data flows 😞

How did you check for data?

So some things I learned over the years. First things first, is the bus terminated? You must have a 120 ohm terminator both sides. If the cable run is really short, just one will do.

Second, I asume you have the device correctly set up. I can't see in that document what driver it uses. I'm more familiar with the MCP2515 chip, which you pretty much active by loading the right device tree overlay. I do love the ISO1050 line interface used in that. That's the isolated one. That adds a lot of safety.

Third, your can interface must be brought up correctly. With something like:

ip link set can0 up type can bitrate 500000 restart-ms 100

Pylontech batteries run at 500kbaud.

Then you can hopefully see some traffic on the bus using candump, eg on my beaglebone:
 

root@beaglebone:~# candump can0
  can0  351   [8]  3A 02 64 00 64 00 A4 01
  can0  355   [8]  32 00 64 00 00 00 00 00
  can0  356   [8]  B4 14 64 00 F0 00 00 00

And once you got all that working, then you get to the code part of actually opening the device and reading from it with the socket interface.

13 hours ago, martynw said:

@Youda did you need to do anything to get the CANBUS data working?

I'm trying to connect to my US2000 master (I have 6 total connected to a Sofar Solar ME3000SP via RS485) using a USB-CAN interface ( http://www.inno-maker.com/wp-content/uploads/2019/02/USB-CAN-Module-Manual-v1000_EN.pdf ) on a Raspberry Pi.

All seems to be OK wiring wise based on the Pylon manual and I can bring up the can0 interface, but absolutely zero data flows 😞

Aiming to read the data via Node-Red eventually and transmit over MQTT, but first need to actually get some data!

 

Thanks for any pointers!

Martyn

 

Hi @martynw

I'm using a PLC Tecomat Foxtrot that has an external CAN module, DIN rail mounted. Therefore, I can't really give you an advice that would be directly aplicable to your Raspberry.
Sorry mate 😕

Just couple of hints:

• Set your CAN interface to 500K baud.
• Close the "Bus Termination Jumper" on your interface board. I have BT enabled on my module too, see below.
• Pylontech CAN port has a built-in BT. No need to add anything on this side. Just plug the RJ45 cable in.
• On the Pylontech side, CAN L/H data is on the Pins 4&5, GND is pin 2. If not working, swap the L/H wires.
• Normally, it's okay to use data pins only, but I've rather connected GND of my CAN module to the pin 2, too.
• My CAN cable (UTP) has roughly 6m and works fine.
• There's no need to send any command to the battery - it broadcasts all in info in the neverending loop on the CAN bus.

If you did all the above and the battery is still silent, I would suggest you this:

• Disconnect anything (inverter) from the battery's RS485 port.
• Move all the battery's DIP switches in to the default position = down.
• Power cycle the battery.

 

 

Edited August 8, 20197 yr by Youda

3 hours ago, plonkster said:

How did you check for data?

So some things I learned over the years. First things first, is the bus terminated? You must have a 120 ohm terminator both sides. If the cable run is really short, just one will do.

 

Thanks @plonkster that confirms a few things I was already doing. 

The USB-CAN interface has a jumper to enable / disable termination, so I've got that covered.

I was bringing the interface up like so:

ip link set can0 up type can bitrate 500000 restart-ms 100 listen-only on

ifconfig can0 up

I read that listen-only can help prevent unwittingly sending stuff by mistake, so was using that, but tried without too.

Sadly candump can0 just sits there doing nothing. 

ifconfig -a shows:

can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I'm (perhaps incorrectly) assuming that this should behave like a normal ethernet connection i.e. RX packets would increment if something were being received?

1 hour ago, Youda said:

 

Hi @martynw

I'm using a PLC Tecomat Foxtrot that has an external CAN module, DIN rail mounted. Therefore, I can't really give you an advice that would be directly aplicable to your Raspberry.
Sorry mate 😕

Just couple of hints:

• Set your CAN interface to 500K baud.
• Close the "Bus Termination Jumper" on your interface board. I have BT enabled on my module too, see below.
• Pylontech CAN port has a built-in BT. No need to add anything on this side. Just plug the RJ45 cable in.
• On the Pylontech side, CAN L/H data is on the Pins 4&5, GND is pin 2. If not working, swap the L/H wires.
• Normally, it's okay to use data pins only, but I've rather connected GND of my CAN module to the pin 2, too.
• My CAN cable (UTP) has roughly 6m and works fine.
• There's no need to send any command to the battery - it broadcasts all in info in the neverending loop on the CAN bus.

If you did all the above and the battery is still silent, I would suggest you this:

• Disconnect anything (inverter) from the battery's RS485 port.
• Move all the battery's DIP switches in to the default position = down.
• Power cycle the battery.

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?

 

 

@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.

 

11 hours ago, martynw said:

@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!

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!

 

Quote

 

VAR
  arrayofcandata : array[1..32] of TCSJ_datr;    //built-in type TCSJ_datr for PLC Tecomat CAN SC-1102
END_VAR

// receiving from CAN SC-1102, copying from SC-1102 memory to buffer array
Memcpy(length := SIZEOF(TCSJ_datr)*32, source := void(CSJ_CH7_REC1.Datr1), dest := void(arrayofcandata[1]));
   if CSJ_CH7_REC1.Mesr > 0 then                            //some CAN messages just arrived
     FOR i := 1 TO CSJ_CH7_REC1.Mesr DO
       //extract CANID from buffer array
       Memcpy(length := sizeof(B1CANID), source := void(arrayofcandata.Data[0]), dest := void(B1CANID));
       B1CANID := ROR(IN := B1CANID, N := 8);          //rotate bitwise to perform bit-format conversion
       B1CANID := B1CANID/32;                                   //shift 5 bits to crop and get a valid CANID number
       //now I have the CANID extracted

       //case based on CANID
        CASE B1CANID OF

          16#355 :        //CANID 0x355 SOC, SOH
             Memcpy(length := sizeof(B1SOC), source := void(arrayofcandata.Data[2]), dest := void(B1SOC));
             Memcpy(length := sizeof(B1SOH), source := void(arrayofcandata.Data[4]), dest := void(B1SOH));

          16#356 :        //CANID 0x356 Voltage, Amps, Temperature
             Memcpy(length := sizeof(B1VOLT), source := void(arrayofcandata.Data[2]), dest := void(B1VOLT));
             Memcpy(length := sizeof(B1AMP), source := void(arrayofcandata.Data[4]), dest := void(B1AMP));
             Memcpy(length := sizeof(B1TEMP), source := void(arrayofcandata.Data[6]), dest := void(B1TEMP));

        END_CASE;
     END_FOR;
   end_if;

 

 

PYLON BMS CAN-Bus-protocol-PYLON-low-voltage-V1.2-20180408.pdf

Edited August 22, 20197 yr by Youda

45 minutes ago, Youda said:

Enclosed is the PDF, which I found to be quite OK for understanding.

Oh that's much better, very different to the PDF I had where half of it was Chinese and the other half that I could actually read didn't make much sense!

Thanks for the other pointers too, should make it much easier to get some code together.  The console / RS232 protocol was pretty simple to process in node-red but I think the CAN bus is too fast for that (just logging the CAN data caused the Pi CPU to climb rapidly) so I'll probably need to do something more real-time.  Maybe python (although possibly that's still a little slow) so might end up dusting off my C skills.

 

Thanks again!

Martyn

 

 

Edited August 22, 20197 yr by martynw

Hi guys,I

Please excuse my ignorance with thius, I have no clue at all about data transfer and coms.

I'm having trouble with he ME3000SP coms. I have a generic lithium battery that has a Chinese BMS with a RS232 coms connection. I think I have the protocol used by the battery BMS.

I'm trying to find the coms protocol used by the ME3000SP, sounds like you guys may have the information needed for me to try a mash something together to get it talking to my battery.

Any help greatly appreciated

Thanks Chuck.

On 2019/04/18 at 9:17 PM, Elbow said:

Hi,

I’m using RS485.  I didn’t put terminators on but no doubt I should.  I found a project on Github and modified it to publish to mqtt. If that makes sense to you i’m happy to share the code.

Hi...Could you share the code please?

Are you communicating to PLC?

Thanks in advance

Hi @Youda, I have a similar issue: I can read my Pylontech batteries via RS232/console.  I can read other Lithium BMS batteries via RS485, but I can't read my Pylontechs via RS485, they simply don't respond.  Did you ever manage to get a response from your Pylontechs on RS485?

On 2019/08/22 at 11:23 PM, Youda said:

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 successfully read the CAN data from my Pylontech battery now, but I don't how to determine which battery sent the CAN message.   As an example, I receive this message, but I assume it's for the entire bank and I won't have individual battery metrics?

Received frame: 0x355

Received data: 81, 95

As it says, If you have one battery it's the single battery if more than one it's the average of the pack.