This is something that happens in multi-parallel pack setups with independent BMS for each parallel pack. The problem is that the BMSs need to be able to communicate to each other and figure out how to behave based on the pack voltages and possible faults from the other BMSs.
Here’s an example of a such setup. We have 2 packs with each of their own BMS and they will be connected to the same charger. Note, the values used are arbitrary, but somewhat realistic.
- Both packs are at 45.0V, no charger connected.
- Charger is connected and pack #1 starts to charge first, it’s voltage rises to 46.0V with the 4Amp current.
- Pack #2 starts to charge also. This causes the current to pack #1 to drop as the current now is spread to also pack #2. At the moment of starting the charge pack #1 is also at a higher voltage than pack #2, so pack #1 will actually for a short moment drop in voltage, exaggerating the current “drop” (4.0A → 0.5A momentarily) it sees at this moment and this might cause the termination current limit to trigger. (this is what @philo is seeing)
- After a short moment the two packs will even out both in voltage and charging current.
The above explanation is a generalized description of why the behavior @philo was seeing is happening.
But there are other possible scenarios where bigger problems may happen, say both packs are even and charging, but the other pack triggers a fault (e.g. bad crimp on a sense wire that causes intermittent dropping of a sensed cell voltage for it) and it starts to spend a lot of time in a fault state. If it’s intermittent then it might see the step 3 described above a multiple times, but if the fault stays on then it might completely stop charging, now you might have one pack at 50.0V and the other at 46.5V and this will most certainly cause the BMS to start ping-pong behaving while charging (basically the higher voltage pack won’t charge and the lower pack will and then the roles reverse at the next charging event).
I have been thinking about “parallel mode” firmware feature to support exactly this use-case to make sure that these possible fault behavior can’t happen or at least is handled better (say one BMS has a fault, which then trigger all the other ones to stop charging as well, to not increase any imbalance between the packs), but it has been on the backlog for some time now, as I haven’t quite figured out the whole system level implementation plan, as there is quite a lot of complexity.
I think I would implement on a user configurable parameter level so that there would be a $-parameter for parallelPackCount, 0 would be normal one pack mode and then 1 would indicate that there is 1 parallel pack, 2 → two parallel packs, 3 → parallel packs and so on. CAN ID 10, would be the master BMS, parallel pack #1 would be 11, pack #2 12 and so on. That is essentially what the user would have to configure, the parallelPackCount to the correct amount on all the BMSs and then make sure the parallel packs have their CAN IDs set to sequentially 10, 11, 12, 13… based on how many there are of them.
The parallelPackCount being non-zero means that the BMSs would be either master or slave, depending if their CAN ID is 10 or not. The master BMS can then poll the slave BMSs for their pack statuses and voltages and can detect if they drop out and stop charging for all the packs. Similarly the slave BMSs can detect the master dropping out, if they don’t get any polling from the CAN ID 10 BMS and they can then stop charging independently after a polling time-out period expires.
Yes… This would feel like a good way to approach this at this moment… 
