VM-3P75CT & Multiplus 6k5 Ping-Pong with PWM Induction cooking

DIY
, , , , ,
1

Hi all,

Over the past month i have been testing my new victron setup. A little context:

  • Single phase Victron 6k5
  • 3 Phase house
  • Grid meter: VM-3P75CT via ethernet
  • Induction plate: etna AKI680ZT
    • This is a 2-phase (7.4kW) cooktop but wired 3 phase, 2 pucks are on phase 1 (same as victron AC-in) and 2 pucks are on phase 2, 3 is unused
  • ESS compensating all loads.
  • Ping from GX to Energy meter is 1.2ms

All “normal user” loads are on the AC out of the 6k5. Heatpump, Induction plate, EV Charger, are on the AC in side.
What i observed (like many of you did before) is that the 6k5 is unable to compensate on the AC side for the cooktop

Finding 1

When the cooktop is set to a medium-high setting (level 7), the PWM pulses are roughly 4 to 5 seconds long, pulling around 1250W:

kookplaat_analyse_zelfdefase_7_2
kookplaat_analyse_zelfdefase_7_21200×600 86.3 KB

As seen in the measurement above (i polled the energy meter at 10hz)

  1. Red areas (Grid Import): The cooktop switches on instantly. The ESS starts to ramp up, but takes several seconds to reach the target. During this time, I am buying power from the grid.
  2. Green areas (Grid Export): Just as the inverter reaches the 1250W target, the cooktop switches off. The inverter now blasts -1200W peak into the grid before it manages to ramp down.

I did a little financial impact calculation: Despite the terrible efficiency, the battery still covers about 60% of the energy needed for this cooking session.

Finding 2:

Things get worse on lower settings (level 4). The pulses still hit ~1250W, but they only last for about 1 to 2 seconds.

kookplaat_analyse_zelfdefase_4
kookplaat_analyse_zelfdefase_41200×600 99.7 KB

Because the pulse is so short, the ESS barely has time to start ramping up before the cooktop turns off again. The result? Almost 100% of the required energy is imported directly from the grid, rendering the home battery effectively useless for this specific cooking session.

I used the 10Hz data to calculate the speed at which the inverter adapts its output based on the grid meter data.

  • Ramp-up speed: ~309 Watts / second
  • Ramp-down speed: ~358 Watts / second

To compensate for a 1250W induction pulse, the Multiplus needs 4 seconds to reach the target. This kind off explains why short pulses (level 4) are completely missed, and medium pulses (level 7) cause massive overshoots.

The AC-Out Comparison

To rule out hardware limitations of the inverter itself, I turned on my Oven (3kW) on the AC-Out side. The compensation was instantaneous (fully compensated in 200ms). The inverter has the physical capability to deliver the sudden power surge (it should be in case of LOM), but it refuses to do so when compensating a load on AC-In via the grid meter.

My temporary workaround

As these pulses are easily detected (not much devices pulse like this, but my espresso machine also does it a bit too). I run a node red flow that will set the Self consumption from battery from All system loads to Only Critical loads When this behavior happens. Although it’s financially better to have this overcompensating behavior (it still covers some of the load). It puts extra stress on the inverter. Result:

image
image1920×1114 441 KB

And the inverter stays quiet. But i rather have a better compensation.

My Questions for you / Victron R&D

The 10Hz VM-3P75CT meter is incredibly fast, so the bottleneck seems to be either the VE.Bus communication or hardcoded firmware limits.

  1. Is the ~310 W/s ramp-rate limit a hardcoded restriction forced by European Grid Codes (EN 50549-1) to prevent grid destabilization? My opinion would be that a constant 0 on the meter would be more stable than this kind of pulsating behavior.

  2. If this is not a strict grid code limitation, are there any ongoing developments in the “Fast ESS” architecture to safely increase this ramp-rate for internal VE.Bus looping, allowing the system to get closer to AC-Out performance?

Thanks for reading, and I’d love to hear your thoughts on this! (and thanks for all the amazing other topics, they helped me a lot in my journey)

2

Yes, this is a restritopn imposed by the grid code standard, and yes it would be better for the grid if the rate was normalised at the meter / connection point. Unfortunately this is outside of the scope of thinking of the people who develop these standards, very often they have limited experience with complex grid connected battery inverter systems.

3

Yup, the more i read into this the more this looks like something we need to live with, in these docs it’s also mentioned that:

Hard coded rate limiting in the inverter/charger firmware: as per ESS version 162 it is set to 400W per second. The reason for this rate limiter is that without that there are regulation problems (overloads and such) when the mains is weak (long cables and such resulting in a relatively high impedance). More information on that here, as well as in the main ESS manual.

Well, I could have known this before, hopefully there will be improvements in the future that allows us to loosen this hardcoded limit, it would greatly improve self-consumption in my use case.

4

Switching off LOM does this overrules the hardcoded limit?

Also ‘regulation problems (overloads and such) when the mains is weak’ this is something that is mostly not the case why not using higher rate standard who is reduced when the mains is weak? Or instead off hardcoded rate a rate that can be set higher for who has not weak grid. Better would be that the system dynamic reduces his rate when the need is there.

5

You could always switch to inverter only when you cook, then back to on.when you are done.

6

Have you tested this? I highly doubt this will remove the AC Feed in ramp up time, but will test tonight to confirm.

I agree with @Sdb that it would be highly beneficial to have control over this, if not limited by gridcode regulations, It will make improve grid stability (removing the ping pong) in most situations.

7

I hate also that PingPong the ESS is doing. In fact the regulation is running always after the facts mainly due physical limits but also that hardcoded ramp-up delay. If this could be reduced the ESS would run mush stabler. Its possible off-grid so on grid should also be possible. In principle I can switch off lom as I have griddisconnection just after the gridmeter (Enphase Q relais).

8

It will take it out of the equation as the inverter is forced to supply everything.

9

Get yourself an RS instead then. The low-frequency inverters will never be able to respond as fast as the transformerless variants. Physics.

10

I have performed this test, and when setting the Multiplus to Inverter Only mode. No energy gets compensated on the AC-IN side:

image
image1200×600 91.7 KB

So in that case my earlier idea to just compensate loads on AC-OUT after pulses are detected is a better solution.

11

Considering that inverter mode opens the AC IN relays, it would be physically impossible to use AC IN in any form..

12

Agreed, but wanted to confirm that the statement of @lxonline, but maybe LX did not fully understand that the induction cooktop is on the AC-IN side of the inverter. As it was a small test it could be easily confirmed.

The current state is that this is a hardcoded limit in the firmware and would require Victron to loosen this up. For me the statement “weak mains” is not applicable, as the house i live in is just over a year old with very stable voltages/mains, and as stated before.

13

Ah, ok.
Yes, it is, especially for grid-side loads, a hardware and coding (including grid codes) limitation.
You would have more joy with it on AC OUT, but, regardless, when large loads kick in and out, you would see the setpoint wobble a little.
I typically disconnect my system from grid when the universe is going to plan. This stops any setpoint related use, not that it is a large amount, it’s just annoying if you want to try maintain a zero use system
Something I just had to learn to accept was a result of the architecture,

14

Also true, but my setup doesn’t allow that. It’s a 3-phase cooktop and I only have a single inverter (connected on AC-IN) as my base loads don’t justify the investment for two additional multiplusses.

On the AC-OUT, I’ve measured a 3kW instant load being fully compensated in under 200ms in ON mode with mains connected, which is perfect. This proves the system is capable of fast response (as it also needs to in a case of LOM)

However, the friction remains: if the 400W/s ramp rate was introduced specifically to prevent issues on ‘weak mains’, this implies this is a firmware-imposed stability buffer rather than a mandatory Grid Code requirement. While I understand the need for stability on those weak lines, applying this as a throttle feels conservative for my use case, where a higher ramp up would actually improve grid stability due to less ping-ping behavior.

For those of us with a robust grid connection, this limit causes unnecessary grid import/export. It’s a bummer that we can’t relax this limit to improve self-consumption on AC-IN loads. I hope a Victron representative can weigh in on whether a ‘fast’ toggle or other setting for strong grids could ever be a possibility.

15

Did you consider an out-of-the-box solution like the one I use for electric kitchen gear (coffee, hot water, sous-vide heater): a thirteen a dozen 48V inverter. And/or rewiring the cooktop to single phase if your comfortable with such a thing.

19

While there is a hardcoded limit, this is necessary to accommodate the many, many users, fixed and mobile/marine that do have highly variable grids.

But this also only focuses on the third documented reason for rate limiting and ignores the first two (which also covers the low-frequency architecture)

Response times and ramp speed

There are multiple factors that determine the response time to a (digital-) command to feed in:

  1. Latency and communication speed of all components in the communication chain: ModbusTCP or MQTT, GX Device, MK3 microprocessor, ESS Assistant, internal communication in the Multi itself.

  2. Rate limiting imposed by the used Country Grid code. Code “Other” has no rate limiting, Code “Europe” allows installer configurable rate limiting, many other codes have fixed a powerup ramp up.

The last point referring to grid recovery.