I have an issue with a couple of units.
Both are coming up #67 BMS Communication lost.
Am using Pylontech US5000B batteries and Cerbo MK2.
Have used Old cerbo model prior to the MK2 with no issue.
Have tried;
DIP Switch
New Cable
Another MK2 Cerbo.
and calling supplier of batteries, still same issue.
No packets dropped under services
Battery is not in alarm state.
Could anyone shed some light on this?
Much Appreciated.
Do you have any communication with the US5000s at all? For example, do you have live data in the Device List?
Default CAN config for the Mk2 VE.Can 2 port (physically, same location as Mk1 BMS-CAN) was not 500kbps (might be in current firmware) so check that.
You shouldn’t need to change DIP switches on Pylons ever, unless you’re using more than 15 and an LV-Hub or something.
The pylon talks as normal but sporadically might just stop working.
could go a day or it might go 5 minutes.
Just strange on the 2x Cerbo MK2 systems.
i have it set to LV 500kbits.
I only changed the master “1” on the DIP Switch
The DIP switches should all be set to 0, see the Victron / Pylontech integration guide:
Important note on DIP switches
No adjustment to the DIP switches is necessary, unless you are using a LV-Hub to connect a large number of modules. The address DIP-switches must be set to 000 for correct operation, and the GX device will not detect the battery if you use any other setting. Larger batteries using an LV-Hub is discussed later in this document.
There is a fault in the software. I’m also having a Cerbo MK2 and before I had 3.5x the installation worked fine (correct setup with 500 kbits)
How do we go about rectifying the issue? I have customers that rely on their systems being functional as they are off-grid.
I sold them this Combo from my own personal experience and now they are failing.
In the Cerbo it’s possible to go back to previous versions (before v3.5)
Started at 3.5 on Cerbo, Installed 3.51 and now 3.52 still same problem
Not sure if that would support the software based input ve.can 2, as the cerbo MK2 doesnt have dedicated BMS input anymore.
i have done every conceivable update that is released, even tried rolling OS back and still get the error. Have also installed the OS Large. The new update appears to clear the error alarm but still logs a fault. Have changed battery and also changed BMS cable. Am using genuine Victron BMS to CAN cable. Will also be trying this with PYTES batteries to see if fault continues.
To add some information to this thread.
Have the same client issue using CerboGX mk2 and Pylontech US5000-1C version.
Mk2 was on V3.52 and based on this thread I downgraded to V2.91 to test.
The result was that I had a little bit longer packet life coming in from the BMS but this stops after a while. Without erroring out. It just stops after 30+ packets.
Now I am on RC 3.60-7 and the same happens only faster … only 3 packets come in and then it stops.
I still have Cerbo GX mk1 and I will give that a try if nothing works.
( tomorrow we are installing a client with mk1 and existing US5000 and four new US5000-1c )
Keep you posted.
Hi All
I have a very similar issue that has occurred since update 3.5> onwards.
I’m using a CCGX with BYD 2.5 B-Box and have had the system running for about 6 years.
I’ve done all the advised fixes with cable checks Firmware Updates to all MPPT’s and Quattro’s etc.
As all have said very randomly drops MPPT’s off for charging but when a reboot is done manages to find them and will run.
Seems to sometimes connect in the mornings back to MPPT’s charging then this morning didn’t connect when the sun arrived?
Have touched base with some other Installers and they are also like me, scratching the head.
Is the new UI loading these items up too much now with the CCGX possibly not being able to handle the data?
Is there a patch coning for a new update to rectify?
So I have also tried with Pytes Ebox-48100r and i get the same result. It could go a week with no error and then all of a sudden just drop. Definately not battery related. I have no MK1 Cerbo’s either for roll-out
Are you using the ve can 2 port?
if so there have been a few threads about signal degredation issues affecting its function.
I am using both can ports. One for Multi RS the other for Batteries. Can port 2 for Batteries Can port 1 for Multi RS.
Have switched over and had the same issue with PylonTech. Will Try with Pytes Batteries.
@timsalmon
New UI and CCGX should not be used in the same sentence.
The CCGX does not have the hardware resources to run the newer firmware.
My suggestion is to roll back to v3.4
@thatrickguy
Always the device on the can 2 port is the issue?
I agree LX wit that. Victron should really have made users and instalers aware of this before UI was put out there on auto firmware update.
Actually they recommend not auto updating.
The 3 times firmware is recommended for update
- Initial install
- Troubleshooting steps
- If a new feature is required by the system
For all the new toys and features you need the new toys.
So have swapped around and now the Multi RS drops out sporadically. No battery Drop out on can port 1.