Pylontech Charging Interrupted by DC Load

2x US5000B, Multi 48/5000, mppt 150/100. Solar charge scenario.
All works fine until I switch on a 48/12 Orion to charge a separate battery, which I do when the Pylons have reached target V. Once the Amps drop to where the Pylons lock in 100% SOC and CCL of zero, the batteries discharge to the Orion rather than the mppt stepping up. This continues down to a V of ~ 50.1, when CCL opens up a little and the mppt responds. The process repeats…

image

The white line (natively the reporting is a bit spiky) shows the DC Load being switched in at 11:20, off at 14:00 and another short burst at 16:00 before I ran out of sun.
The 48V Orion has no comms of course, so I have a Smartshunt allocated as a DC load. But the Pylon/Victron setup doesn’t seem to allow for this.
What to do now??..

  1. On your GX device have you set “has DC system” to enabled in the “System Setup” menu so DVCC knows that it should allow for DC loads.

  2. Is this the only DC load on your system. If it is then you could set the SmartShunt to be “DC system” type rather than just a type of load.

I don’t believe that “has DC system” changes DVCC in any way, it just creates a separate tile.
It has some effect when limiting max charge current and a DC system shunt is used.

The MPPT’s are controlled by the BMS and won’t be aware of loads on the battery until the voltage drops and/or the BMS sends different limits.

The ‘Has DC System’ is ticked, but that only seems to initiate a by-difference plot. Smartshunt allocated thus…
image

Sure BMS control. but GX should be telling it about the dc load. It doesn’t though, so hoping I’ve missed something setting up. This sort of thing is easy to overlook, so I might have even missed it had I not wanted to set up an Assistant to switch the Orion. Cant decide on the parameters to switch with now.

This must be a bug. If not, how to deal with it?

The shunt should be set to DC system iirc, not generic load.

If “DC meter” is selected, you can select the following types:

Solar charger, Wind charger, Shaft generator, Alternator, Fuel cell, Water generator, DC-DC charger, AC charger, Generic source, Generic load, Electric drive, Fridge, Water pump, Bilge pump, DC system, Inverter, Water heater.

When connected to a GX device, the type, the current and the power is shown in the user interface, and this information is also available on the VRM Portal.

When the GX device is also configured as type “has DC System”, the GX does more than just recording and visualisation:

  1. The power shown in the DC system box is the sum of power reported by all battery monitors configured as such. Having multiple meters can be useful, for example, in a catamaran, so that the DC systems in the port hull and in the starboard hull are being measured.
  2. The DC system current is being compensated for when setting DVCC charge current limits to inverter/chargers and solar chargers. For example, when a load of 50A is being measured, and CCL by the battery is 25A, the limit given to the inverter/charger or solar charger is 75A.

Ok, I’ve changed Generic Load to DC System. I can’t test it under solar charge until tomorrow, but at least the DC Power tile shows the shunt value rather than the by-difference calc. Ya learn something every day!
I’ll report tomorrow how it works. I’m hopeful, thanks for that…

@nickdb @pwfarnell
Unfortunately no change. The battery still cycles after I switch in the Orion. I find this very disappointing, as might other users rolling with it, possibly blissfully unaware that their expensive batteries are being shifted between 50.1V and 52.3V (99 to 100% SOC) on a cycle that’s unintended. And probably not balancing cells much at all.

Of course if there’s a fix, I’m still asking. I expect there isn’t, and in that case would ask that Victron take a closer look at what they could do about it. This isn’t trifling stuff like VRM ignoring DC loads in stuff like Consumption figures, it’s about the health of expensive batteries.

Frankly, I expect better… but thanks guys for your help so far, my rant not aimed at you…

@JohnC I hear you, I have seen similar queries before.
Not being a DC loads guy, not something I could test.
I can understand why it happens, but would agree there must be a better way to handle it.

Do you know many amps are the Orion drawing?
Do you have access to Venus OS and dbus-spy?
If yes, go to com.victronenergy.system and find the /debug/batteryoperationallimits/currentoffset and put there a value just a little tad higher than the Orion is drawing. For example, if Orion is drawing 5A, put 6.

Thanks for the suggestion @alexpescaru, but no, I’m not into Linux. I’ll maybe change to an AC charger, have a couple lying about. Also change the shunt to 12V battery monitor.
And wonder forevermore why Victron can’t allow a shunt to be used for DC power (both in and out) on a ‘compatible’ managed battery?..

Cerbo GX manual, section 11.3, note 3

  1. DC Loads may not be accounted for, unless a SmartShunt or BMV-712 is installed and correctly configured as a DC meter. For example, without the DC load monitor a configured maximum charge current of 50A and DC Loads drawing 20A, the battery will be charged with 30A, not with the full allowed 50A. With the SmartShunt configured as a DC meter, maximum charge current configured at 50A and DC system shunt reports a draw of 25A, then the chargers are set to charge with 50 + 25 = 75A.If you have one or more shunts configured for “DC system” (when more than one, they are added together), then the DVCC charge current limit compensates for both loads and chargers. It will add extra charge current if there is a load, and subtract it if there is another charger in the DC system. DC “loads” and “sources” are not compensated for in either direction.

To me this means that DVCC with a managed battery should be allowing for DC currents if a SmartShunt is set as “DC System”. Perhaps it does not work once the battery is full and CCL is zero. Try turning the Orions on and off before the batteries are full as a test once the SmartShunt is definitely set as DC system.

Not exactly. The mppt is unaware of the loads so just provides the current limit for charging, the loads use part of that so the battery doesn’t receive the configured limit. With the shunt they compensate for the dc load. Unfortunately normal usage with a full battery can’t be compensated for especially when ccl drops to near zero.

Indeed this only happens when CCL goes to Zero when the battery has dropped to essentially accepting zero current. The SOC bobs as 100%, and stays like that until V drops to near 50.1V, when SOC goes to 99% and CCL 40A over the 2x batts. Turning off the Orion before V gets that low seems to let in a bit of bleed ~0.5A. So it does creep back to full V after a time. This pic from the shunt showing the Orion drawing ~300W for only a couple minutes…
image

To me this cycling isn’t satisfactory. It essentially means that all DC discharges aren’t possible with full batteries. Even if you’ve added a shunt to quantify it. I might be able to use the Orion when running a genset, which I only do at lower SOC, but for harvesting a bit of excess solar power I can’t use it…

You could always start the orion a little earlier. As in when the pylons are throttling charge rather than ending it. (Around 90%) That way the production is happening and consumption is being produced for.
Are you sure it is not just volt drop under load. Pylons tend to do that?
Saw tooth pattern on some pylontec systems (on the voltage) is a known thing. So there is a possibility is related to that.

Indeed, what I’ve described is actually possibly the cause of such ‘known’ sawtoothing. I’m not happy designing it into my system. In both my pics you can see how stable V is without the Orion.
Sure there’s workarounds, but in the dark depths of winter extracting that little extra solar has merit. Goes against the grain a bit, but I might schedule the Orion to work in the dark hours. In the washup I get back the solar in the following day, hey… And I might add in a 230ac/12dc charger for genset use in winter, it has a little capacity left over the Multi’s 70A charge limit.
Thanks for your help @lxonline Alex, love your work.
But I can’t help but consider this a bug awaiting a fix…