Hi, I have 5 JK BMS PB connected in parallel on their RS 485 network. The master is connected to the cerbo via CAN. This operation works well.
However, it is possible to sniff the modbus network to get the cell data and more for each bms. I successfully do this with the JK windows app connected via a USB RS485 adapter.
If I plug it into the cerbo it appears on ttyUSB0 and I have read the correct data from it with some test python apps. But something happens causing the network to get disrupted when plugged into the cerbo. This is without me running any programs. The master BMS stops successful communication with the other BMS leading to the SOC, CCL etc fluctuating based on the number of BMS currently in communication.
The communication on the network is all in response to master communications. So if other traffic is injected from the cerbo this would cause issues.
Does the cerbo automatically start polling USB rs485 devices? If so, is there a way to turn off this behaviour?
thanks Andy
I don’t believe that something is using the port. The idea of polling is a protocol level thing.
It could be a hardware problem, depending on the adapter you use.
Think about it… With Windows JK app, you connect that USB-RS485 adapter to another device.
Now you are trying to connect that adapter with the same device where also the BMS CAN interface is connected…
Who knows…
As many differential communication implementations, the RS485 network needs, depending on speed, a termination resistor.
Also, some even use a pull-up and a pull-down resistor to 5V and GND.
Are you connecting the GND on CAN connection?
Are you connecting the GND on RS485 connection?
If yes, it could create a strange GND loop that interferes with the communication.
Venus only supports batteries connected via BMS.CAN, and occasionally VE.CAN. Other interfaces are not supported. What it does support is well documented in the cerbo manual.
JK BMS is also unsupported, so, here be dragons.
He already has valid, working, BMS.CAN connection.
I believe he is talking about connecting another non-BMS “source” of information on the same Cerbo.
Thanks for your replies. I am not trying to connect it to the CAN or to try and use it for any control purposes. I was merely going to sniff the rs485 network.
The JK BMS has a CAN output that is currently connected to the CAN Bus. This is left as it was. It also has two other RS485 ports allowing daisy chaining of all the JK BMSs. The master is ID 0 and all the others have increasing numbers.
On my windows machine I plug into the daisy chain and just read the traffic passing over the wire. I was trying to do the same on the cerbo so I don’t need another device. I have successfully read the data on the cerbo so in principle it does work.
I’m more of a software guy so knowing when to GND or not is not my forte. I can’t remember if the wire I made up is connected to GND. I don’t think I did. The CAN wire may well be as it is a pre-made wire. It might be the one that came with one of the victron devices as it is a lovely blue colour. I’ll check them tomorrow with my tester.
Nick, as far as the JK BMS on CAN bus, I can appreciate it isn’t supported. However, so far it has worked very well for 5 months now. I’ve got back up protections re voltage limits etc so hopefully the dragons won’t be too nasty.
Don’t connect GND on any connection, CAN or RS485.
Only CAN-H and CAN-L on CAN connection and only RS485-A and RS485-B on RS485 connection.
Both connections are differential ones and the battery is already connected to the system GND through the (-) minus wire.
Also is a dangerous thing to connect GND on the connector, because if by any chance the battery (-) minus terminal will disconnect, all big currents will flow through the CAN or RS485 GND connection !
Correct. Pheonix may also be right.
It’s not the first time when I am hearing that if you are using the same USB to XXX converter who’s PID and VID are already defined on the Venus OS, the OS will interfere with your communication.
You may need to disable that serial driver first.
Hi, it was indeed the serial-starter that was disrupting things. I tried briefly running the script last night but it didn’t work. I ran the script then went to the shed and plugged in the device.
It turns out the device needs to be plugged in first. Having read the script it deletes links from a folder created at /dev/serial-starter. This folder doesn’t exist until the device is plugged in.
So successful steps.
plug in device into usb0
run /opt/victronenergy/serial-starter/stop-tty.sh /dev/ttyUSB0
add command to my /data/rc.local script
Life is good again and I can go to the next step. Thanks for the poke in the right direction.