Wearing Flash by Charge Current Limiting?

Modifications
, , , ,
1

hi all :slight_smile:

I intend to ‘dynamically’ limit the charge current of the battery, mainly at low temperatures.

I intend to use DVCC für this purpose, obviously /Settings/SystemSetup/MaxChargeCurrent but unfortunately this does not regard the DC Load (changing in my system, another inverter), so I need to continuously calculate

MaxChargeCurrent = intended_charge_current + dc_load_current

The calculation is no problem BUT

  • does it wear the flash if I continuously (1sec) re-write SystemSetup/MaxChargeCurrent?
  • is there another variable I could use for this purpose?
  • what about /battery/512/Info/MaxChargeCurrent? may I utilize that for my intend?

Any tips/info for me that might help?!

thank you very much & greetings!
Phil

2

@alexpescaru I think I need your help :folded_hands:

If the MaxChargeCurrent mechanism would take the /Dc/System/Current into account (like it does with the vebus_dc_current of the Multi), then everything would be fine and I could simply set MaxChargeCurrent to a constant, intended value.

And indeed it does,

grafik
grafik868×563 39.9 KB

but only in case ‘if it is based on a real measurement’:

grafik
grafik686×342 19.7 KB

Do you have an idea why that?

I tried writing W/a1234567890b/system/0/Dc/System/MeasurementType to {"value":1} but it isn’t accepted or overwritten.

Do you see any problem in doing a change like that?

grafik
grafik685×316 19.5 KB

The only reference to dcsyscurrent is the calculation of max_charge_current (see above):

grafik
grafik589×351 19.3 KB

Why doesn’t it take the value from /Dc/System/Current?

thank you very much or your advice!!

3

or perhaps even better to change it to

grafik
grafik809×470 27.3 KB

?!

4

It’s not a good idea to change any “/Settings/…” variable on a periodic basis.

In dvcc script there are some maxchargecurrent.setter functions that get called periodically, especially based on the current limit (CCL) sent by the managed batteries.

Follow those paths and adjust based on your needs.

Your idea is OK if it’s not influencing anything else in your system.
Script designers had to take into account many situations and probably this is why they put those conditions.

I, for one, I adjust in a similar manner the system’s “idle/parasitic” current consumption, in order to not discharge from the battery and create those “sawtooth” battery voltage curves.

5

thank you!

Can you tell me where/how the ‘core control’ of the charge current is done?

I wonder why it’s not done based on the measured current value of SmartShunt or BMS and only in absence of both, take the ‘artificial’ sum of all those powers in the system into account

newvalues['/Dc/System/Power'] = dc_pv_power + charger_power + fuelcell_power + alternator_power + vebuspower + inverter_power - battery_power
try:
	newvalues['/Dc/System/Current'] = newvalues['/Dc/System/Power'] / newvalues['/Dc/Battery/Voltage']
6

As the tuning of the charge current is an important thing, the “core control” as you say is all over.
Starting from timer function, then on _update_solarchargers_and_vecan function and from there on set_networked function.

You can always try and dare to make modifications of your own… Who dare wins…:wink:

7

ok, as far as I understand set_networked, the ‘core control’ is done by the MPPT chargers and they do it ‘open loop’ without feedback of the battery-measured value… In that case it makes sense to ‘command’ the current based on the ins and outs of the system.

But then I do not understand why the scriptmakers say “An estimated/calculated value of dc loads is not too useful, so we ignore them completely.” I have up to 60A dc load - not to regard that means charge current limitation isn’t worth a penny.