chemical batteries don't take nearly that long to react!

The control systems do though

i doubt that very much indeed. it isn't practical to run a switching power supply with feedback latencies of multiple milliseconds

Tesla Megapacks detect and respond within ~100ms when operating in grid support mode. Unsure how that compares to what you’d expect.

https://www.aurecongroup.com/-/media/files/downloads-library...

they have internal control systems that respond a lot faster than that. 100ms is 6 entire cycles of a 60-hertz sine wave, an utter eternity compared to the control mechanisms required to follow that sine wave up and down with pwm/pdm. the 150ms number in that brochure probably has to do with computer networking software, not the battery pack control system itself

but the power conversion control system is relatively slow, taking hundreds of nanoseconds to respond (ten thousand times faster than a few milliseconds). the battery chemistry itself responds enormously faster than that when the current drawn from it changes; the only thing that limits the electrochemical response is the capacitance of the electrical double layer, which in a battery (as opposed to a supercapacitor) is on the order of one nanofarad per ampere. so the tiny changes in the overpotential that turn the electrochemical reactions on or off can take place in well under a single nanosecond

so saying 'chemical batteries that can react in milliseconds' is understating the speed by a factor of ten million. that's like saying 'jet planes that can fly meters per day', 'supercomputers that can do dozens of multiplications per minute', or 'skyscrapers that can reach tens of microns in height'

I think this is a bit of a pedantic take. My reading of the GP is to distinguish systems based on chemical batteries from systems based on gravitational batteries rather than the reaction time of the chemical cells specifically.

Definitely pedantic, but also quite amusing.

you are my kind of person

> so saying 'chemical batteries that can react in milliseconds' is understating the speed by a factor of ten million. that's like saying 'jet planes that can fly meters per day', 'supercomputers that can do dozens of multiplications per minute', or 'skyscrapers that can reach tens of microns in height'

I checked your analogies for jet planes and skyscrapers, and found them to be well within an order of magnitude of ten million, but you're off on your supercomputer analogy by a factor somewhere in the range of a billion.

I couldn't find a hard definition of what constitutes a supercomputer. The bottom of the Top 500 list is in the single-digit petaflop range and an RTX 4090 has 70 or 80 single-precision teraflops, and presumably you need more than a handful of graphics cards to constitute a supercomputer, so let's say 1 petaflop is our threshold for a supercomputer.

The ratio of a petaflop to 12 flops/minute is 5e15, or 5 million billion. Saying "a factor of ten million is like saying 'supercomputers that can do dozens of multiplications per minute'" is like saying 'the moon orbits meters above the Earth's surface'.

thanks for checking my calculations!

unlike the other examples, the category of 'supercomputer' has shifted over time. initially, i was thinking of a cray-1, which is the machine that popularized the term 'supercomputer' https://books.google.com/ngrams/graph?content=supercomputer&.... it was only about 160 megaflops, which is ten million times 960 calculations per minute. that wouldn't normally be described as 'dozens'; it's about an order of magnitude high. so i should have done my calculations a bit more carefully

up to the late 90s, when the term 'supercomputer' had largely fallen out of use, top-end supers were still in the low-digit gigaflops: https://www.hpcwire.com/1997/04/04/tera-mta-computer-posts-b...

you are of course correct that current machines are many orders of magnitude faster than that, and even a single video card is about three orders of magnitude faster

> i doubt that very much indeed. it isn't practical to run a switching power supply with feedback latencies of multiple milliseconds

That's because the control loop for a grid battery doesn't work the way you probably expect. The grid is effectively an infinite sink, so the voltage and frequency you observe "is what it is". You can't change it[^1], so you can't use voltage feedback from the output of your SMPS to drive the PWM. If you tried to do that with any kind of PID loop, you'd always be pinned at either maximum charge rate or maximum discharge rate[^2].

The correct way to do it is with an inner loop that will target a phase angle between grid voltage and your current. An outer loop (with a longer time constant) will set that target angle by comparing the measured grid frequency to a schedule.

> 100ms is 6 entire cycles of a 60-hertz sine wave

Yes, and?

You're measuring a sine wave, not a square with fast edges. Any voltage noise on the line is going to influence the zero-crossing and thus the measured frequency (which drives your battery controller). If you try have your controller do cycle-by-cycle corrections, you're again going to have your battery always at maximum charge or maximum discharge.

[^1] When Tesla's battery in Australia "saved the grid" when Loy Yang tripped offline, it dumped 150MW into the grid so that the rate of change of grid frequency was reduced. Even with the battery running balls to the wall, the grid was still slowing down.

[^2] Assuming that you haven't set your P and I terms to 0.

i appreciate your comment!

it's true, you can drive an h-bridge with a pre-canned pwm waveform whose phase you adjust with a latency measured not just in milliseconds but in seconds, though you'd better have safety mechanisms that respond to a fault on the line faster than that. you don't have to use feedback to generate the control signal! but at least in garden-variety class-d amplifiers reproducing arbitrary waveforms (rather than necessarily a fixed-frequency sine wave), you get better performance if you do use feedback, so it's common practice

(disclaimer, i've never built power electronics, so i could totally be misunderstanding something)

i think you're saying that any kind of a pid loop will alternate between being pinned at maximum or minimum when the plant isn't responding to the control output, unless p = i = 0. i don't think that's correct; i think it's sufficient to not make your p coefficient overwhelmingly large. a sufficiently large i coefficient will also make your control loop tend toward extremes in this situation, but not instantly, and a nonzero i will probably always win in the end when the plant is completely unresponsive. but a moderate p won't have that effect, and d can attenuate it.

also, you can totally use current feedback from the output of your smps to drive the pwm, and that seems to me like it would be a very good idea

> true, you can drive an h-bridge with a pre-canned pwm waveform whose phase you adjust with a latency measured not just in milliseconds but in seconds

I’m not sure what you’re trying to say with this paragraph so I’m not going to respond to it.

> think it's sufficient to not make your p coefficient overwhelmingly large. a sufficiently large i coefficient will also make

What I’m saying is that making the P term small enough not to pin the PWM means that it won’t do anything useful, though I do see I wasn’t originally as clear as I could have been on that point. Either there won’t be enough gain or you will pin the output. There is no meaningful range of values in the middle, especially when the system needs to work outside the laboratory and you can’t tweak the parameters every other day.

If you rely completely on the I term, you’ll have stability problems. So now it requires a lot of D term… and now you’ve gone full circle and we’re back to “the whole thing won’t work without a time constant which makes it totally useless to run a PWM and barely useful for the outer loop.”

> you can totally use current feedback from the output of your smps to drive the pwm, and that seems to me like it would be a very good idea

I did mention that already… along with the fact that you need to set some target for your current feedback using an outer control loop. You can set the target by measuring frequency error averaged across several cycles. Again, you need on the order of 100 ms to make that work.

Whatever way you slice it, the grid backup battery is not going to start exporting power to the grid in less than a cycle, and certainly not in less than a millisecond.

thank you!