I stumbled on this behavior this morning and see it’s an issue that doesn’t look like it’s been resolved.
https://community.victronenergy.com/questions/87377/dvcc-limit-charge-current-does-not-work.html
I’m keen to see if anyone else has the same experience.
GX: v3.30~15
CAN connected Pylontech Bank.
CCL = 60a and 150a charging to battery.
MPPT’s = Ext Control
Yes, normal. Known issue, and documented pretty well. It may be possible to resolve it, but not any time soon. If you’re feeding into the grid, it uses voltage to do the job. You cannot apply a current limit, otherwise it might end up feeding less energy into the grid or even deadlocking at CCL=0.
I assume CCL is then null and void as soon as you feed in…
Makes me nervous given Victron is therefore ignoring the CCL from the BMS… Is this the same for all batteries?
Yes.
Let me explain a bit about how this works, and also note, this is somewhat legacy. This thing where batteries are lazy about their voltage requirements, and very finicky about their current limits, is a bit newer than people realise. In the beginning this was much less of an issue, it became one over time.
Feeding in of excess DC-coupled PV uses an overvoltage mechanism. The battery is charged to 0.4V higher than the Multi expects to see, and the Multi then activates a regulation loop that feeds energy into the grid to eliminate that 0.4V.
Now imagine you introduce a very low current limit from a battery, one that prevents such an overvoltage from developing in the first place. This would completely break the feature. With some batteries it might still work, but guaranteed, you’re going to lose energy that might have gone to the grid.
Now imagine what it would take to solve this issue. Some options:
Another closed control loop (at the moment the loops controlling this part are all open loops, no feedback), that constantly watches the battery current and increases charge current until it sort of levels out where the BMS wants it. Blindly hope that you get enough of an overvoltage condition going for excess energy to be fed in… (I can guarantee you there will be LOTS of complaints).
Do away with the overvoltage mechanism, and just use the setpoint mechanism to actively force some energy into the grid, again with some control loop. Since loops on the GX are slow, you will lose energy, you probably will have issues with MPPTs hitting the max charge voltage at times and slowing down, death spirals. Won’t work at all with “Keep Batteries Charged”, you’re going to constantly run into issues with either the batteries not fully charged (because you fed in too much) or hitting the max charge voltage and having the MPPTs spool down. The only way to keep the MPPTs open is holding the batteries down.
Document it and let the BMS deal with protection (current strategy).
Tell people to use a PV-inverter if they want to feed that much energy into the grid.
Don’t use batteries that rely overly heavily on current control.
This problem is very much inherent in using DC-coupled PV (on the DC bus) and expecting smooth delivery of the excess on the AC side. You want the full power to pass through the DC bus… just not through the battery!
Thanks @plonkster - That helps a lot. And I agree - the PT BMS should and ilooks like it is dealing with issues.
I don’t know shiite, but sometimes I figure out shiite … like I figured the above out a while ago. 
Not sure if this is the same thing, or related, moving towards a solution?
https://community.victronenergy.com/questions/265862/venus-os-v33010-available-for-testing.html
I know of the one in bold quite well.
Dude… those are all specific to DynamicEss and has nothing to do with that old issue
The Multi needs to be in the right “mode” (have the right flags) set to feed loads with PV while keeping the battery charged. Those flags are not set in optimised mode. That’s why your favourite pet issue persists… cause I cannot set that flag without ticking off the other half of complainants.
Dude, I have NO “pet issue” left to sort. Whatever was has been sorted for years. I just find it interesting when it is noted at times, that’s all … in the right context or not.
EDIT: What I do find very interesting, is how the software keeps on evolving. sometimes new issues see the light, and sometimes older issues disappear due to a totally new approach. It is quite encouraging to see it all happen over the decades, where it was and where it is today, and heading.
Haha, okay maybe I was a bit aspris with calling it your pet issue. Indeed, it comes up a lot because of how tricky it is/was to solve. It came up again when implementing the new peak shaving stuff. And it came up again with DynamicEss whenever a battery charges to 100%. And again this morning a very senior colleague asked me to explain again why this way and not that way…
Most of it is abstracted away in a software layer so that you merely have to tell the system: “Please charge the battery”, and the right thing happens.
Every time something is done regarding to charging to 100%, you must also always remember that 100% can actually never technically be reached. That’s how it must be in the software. When you ask for 100%, the system never stops charging. The current may drop off to 0A, but the tap is kept open to keep it there. That is the bug the changelog refers to above: When people were using DynamicEss (which has to do with energy arbitrage) to charge to 100%, the system would drop into idle mode at 100%, leaving nowhere for the PV to go, but not allowing that energy to be used for loads.
I have thought on this … my old “question”, same “issue” today.
Like the BMSes, one may need two relays, charge/discharge, so that once the batt is 100% SOC, disconnect the charge relay and throw the power to the loads, leaving the discharge delay in play, to draw from the batt.
Or try and handle it via software … as one can do in my case, use Keep Charged. Problem solved IF one uses external software to manage that afterward.
Could also maybe one day solve the DVCC issue as per this thread - more hardware parts needed.