YamBMS JK-BMS-CAN with new Cut-Off Charging Logic (open-source)

[ChrisG]

Thank you. Lot for me to unpack there. The 300a comment knowing that inverter can only do 140 was theoretical. My batteries per pack can burst to 1C (100 amps charging) and sustained rating is .5C per pack so I can sustain a charge of 100amp an across both packs.

I also see the inverter max current setting as saving feature. Previously I had it set to max of 140 as I assumed YAMBMS would auto decrease if a physical BMS cutoff charging.

The YamBMS 1 Requested Charge Current seems to be the total of OCP value set in each BMS, correct? There is no separate value in the multi-bms code?

 

[ChrisG]

EDIT 1: @ChrisG: IMPORTANT - did you set that the Inverter TRIPS when Communication with the BMS is lost ? On the Deye Inverter that is setting BMS_Err_Stop, not sure about your Inverter. If communication is lost and NO protection against loss of Communication is enabled, then the Inverter will literally go "Full Power" (even if you are at the Top of the Charge Curve !). Make sure you have that setting (whatever is called) Enabled !

I have no setting but can confirm that if comms are lost it switches to grid passthrough, no battery charge or discharge. If no grid, it shuts down inverter.

 

[Sleeper85]

The YamBMS 1 Requested Charge Current seems to be the total of OCP value set in each BMS, correct? There is no separate value in the multi-bms code?

Yes it's true, YamBMS takes the values you configure in the BMS. The goal is to have well-configured BMS and to reduce the YamBMS parameters as much as possible because there are already a lot of parameters.

 

[silverstone]

Thank you. Lot for me to unpack there. The 300a comment knowing that inverter can only do 140 was theoretical. My batteries per pack can burst to 1C (100 amps charging) and sustained rating is .5C per pack so I can sustain a charge of 100amp an across both packs.

Your batteries can do 10C for that matter during a Fault, BMS or not.

That's what your Cell can handle. Then there is what your Cabling/Cabling can handle (don't know your System so I cannot judge).

What you WANT your system to do should be set in the Control/Regulation Part. That's what determines the "long-term". You don't want e.g. [in DISCHARGE mode] a Synchronous/Asynchronous Motor that is not behind a Soft Starter tripping your system during startup because for like 5s you went 20% above your "nominal" Current (and 1s like +500% maybe). That's still your "Normal Operation" if you start an Electric Drill or let your Lawnmower/Table saw/etc do their Job.

(Quotes because "Nominal" and "Rated" are very loose and User-dependent Terms)

On the other hand, for the medium-long term, you don't want the System to operate in overload and in Faulty Conditions. That's what the Protection Part does. You do NOT want the Protection to kick in during Normal Operation, yet you want to trip when you really need to. It's a COMPROMIZE: too high Setting = never Trip, too low = spurious/unwanted Trip). If you are in control of the System via Software, the Protection should NEVER kick in (unless there are BUGs in SW, wrong Settings, etc).

I also see the inverter max current setting as saving feature. Previously I had it set to max of 140 as I assumed YAMBMS would auto decrease if a physical BMS cutoff charging.

Which ... it should IMHO as well. Otherwise trips the first battery -> immediately after trips the second (and third etc) Battery.

The YamBMS 1 Requested Charge Current seems to be the total of OCP value set in each BMS, correct? There is no separate value in the multi-bms code?

NOT AT ALL. Unless the logic radically changed from Previous Versions.

Again you are confusing what a PROTECTION setting is (Current > Threshold for e.g. 1s -> TRIP/Disconnect) and a REGULATION/CONTROL setting is (the JK BMS "asks" the Inverter for this current, so of course if this current is too high, that's the wrong user Setting IMHO). BUG aside that it should be Nbat*min(IBat_Ref_each)

The "Overcurrent / OCP Current Value" is what the JK BMS (by itself !) does as last-resort SELF-PROTECTION and is NOT used by the ESP32 BMS.

The "Requested Charge Current" should be a user-defined parameter which ONLY the ESP32 BMS uses for REGULATION (and Protection to some extent IMHO) and is NOT used by the JK BMS (it has no way of knowing it even exists).

So, unless things changed radically from previous versions, it's 2 completely separate parameters.

And I don't know how it was implemented in the End, but I would expect N Batteries -> N Controllers -> N Current/Voltage References -> Global Controller: UBat_Charge = min(UBat_Ref_each) , IBat_Charge = Nbat*min(IBat_Ref_each)

 

[silverstone]

Yes it's true, YamBMS takes the values you configure in the BMS. The goal is to have well-configured BMS and to reduce the YamBMS parameters as much as possible because there are already a lot of parameters.

Did you change that in this new Release ? I'm getting a bit nervous here about Protection/Control being "too close" i.e. NOT decoupled enough.

 

[ChrisG]

Did you change that in this new Release ? I'm getting a bit nervous here about Protection/Control being "too close" i.e. NOT decoupled enough.

To be very clear, if I change my individual BMS OCP value, those OCP values show up in the YamBMS 1 Requested Charge Current total which is what I’ve been saying all along. It’s right at the edge of trip.

If I enter directly on the BMS’s or in the yambms JK-BMS 1 max charge current and yambms JK-BMS 2 max charge current, these values stay in sync between physical BMS and YAMBMS. The total of the two is the Requested Charge Current to inverter.

 

[silverstone]

To be very clear, if I change my individual BMS OCP value, those OCO values show up in the YamBMS 1 Requested Charge Current total which is what I’ve been saying all along. It’s right at the edge of trip.

Well that's a bummer. I'd like at least a "multiplier factor" or something like that. As I showed in my previous Screenshots these used to be 2 distinct Parameters (as they should be IMHO). I didn't know that Part got changed/removed .

Otherwise as I said Protection and Regulation starts to merge and you get all weird sort of Behaviors. Well during Charge I guess overloads are more rare than during Discharge, but still ...

Only one Setting which implies Peak = RMS is a bad idea IMHO. And again, only min(IBat_Ref)*Nbat shall be passed as Requested Charge Current, otherwise you have an unstable-producing Controller, AKA a controller that makes a Situation Worse (trip the first Battery, trip the second Batter because it gets overloaded, ...).

EDIT 1: The Protection (JK BMS at 0.001 s Interval for Current / Short-Circuit I believe it's even 100 us ???) is MUCH FASTER than the Control (ESP32 BMS at 1s Interval), so to think we like to allow a small spike / measurement Noise to trip a healthy System is just weird ...

 

[Sleeper85]

@silverstone

Indeed I forgot the OCP multiplier factor as I thought I would at the beginning. I'll fix that. What do you think of 0.9?

 

[ChrisG]

To be very clear, if I change my individual BMS OCP value, those OCP values show up in the YamBMS 1 Requested Charge Current total which is what I’ve been saying all along. It’s right at the edge of trip.

If I enter directly on the BMS’s or in the yambms JK-BMS 1 max charge current and yambms JK-BMS 2 max charge current, these values stay in sync between physical BMS and YAMBMS. The total of the two is the Requested Charge Current to inverter.

Maybe I should have said it that clearly three pages ago, but my data supports it anyway. Looking forward to a fix.

 

[silverstone]

@silverstone

Indeed I forgot the OCP multiplier factor as I thought I would at the beginning. I'll fix that. What do you think of 0.9?

I'd say it should be dynamic. And Ipeak/IRMS ~ 2 in my Mind it's much more relaxing (so 0.5 if you look at the other way around).

EDIT 1: For a pure "charge" profile, without ANY load step, 0.8 might be enough. But if you consider than you have a steady AC load which all of a sudden disappears (NEGATIVE load step on the Battery), the current might jump up quite a bit, because the Inverter doesn't want to let the DC-Link Voltage shoot up (and the Battery is a MUCH higher "Capacitance" / Capacity Value than a few mF DC-link Capacitors). EDIT 4: unsure about the time constant, maybe the PV / MPPT Channel has a lower time constant, so the reaction there could be much faster than say the DC/DC with Medium Frequency Transformer like we have on the Deye. Of course it's much worse in an OFF-Grid Setting because Power has nowhere else to go (not an "infinite AC bus" like on Grid-Connected Systems).

EDIT 2: For @ChrisG where the Measurement Noise/Offset might be quite significant (~ 40A "nominal" of his Application vs maybe 10-20 A noise/error), I'd err towards a 0.5 factor instead.

EDIT 3: @Sleeper85 the most important Part for me is that IBat_Charge_Ref = Nbat * min(IBat_Ref_each), i.e. if one Battery has IBat_Ref_X much smaller than the average, then charging shall stop/slow down as to avoid trips. I believe this is (one of) the reasons for @ChrisG reported Issues. Otherwise it's the same as parallel fuses/breakers/semiconductors/resistors/inductors/etc: the one that is overloaded is the first to blow/trip/burn, then the second one will soon follow ...

EDIT 5: Actually @Sleeper85 , what do you do if you have a current that is too high ? Do you do a Negative Feedback Loop and reduce the Voltage / Reduce the requested Current by Kfb * (Imeasured - Imax) ? Of course the goal should be to never be in such Situation (see EDIT 3).