Phil, You comments are excellent and are well taken. As you say this has to be managed. One of the ways we planned to manage the system is to have deadbands on the buss voltage. Another way is to have a simple way that the units can communicate to each other as to their state. I have also been thinking of using a common system such as the IHU to send out a number which is it's opinion as to the voltage of the bus. That way all units on the line would have a value to check against their measurement. That would provide a reference for all to use. Of course this needs to be discussed more to flush out various situations. I am planning to bring a small team together to put together an interface specification or protocol for this power system. Perhaps you could participate on that team and lend your valuable expertise and experience.
I will be traveling the rest of today.
Lou McFadin W5DID w5did@mac.com
On Oct 11, 2006, at 9:19 AM, Phil Karn wrote:
Jim Sanford wrote:
The situation you describe regarding load sharing between multiple parallel sources, without oscillations and circulating currents, is no different than the situation where there are multiple AC generators operating in parallel. In that case, the speed governor (which sets frequency) has a frequency vs load characteristic that is not flat. This forces stable real load sharing, even when generators of different capacity are paralleled. Similarly, the voltage regulator has a non-flat voltage vs. reactive load characteristic. This forces stable sharing of reactive load.
I'm not sure this is the exact same situation. A generator is not a stored energy device (ignoring flywheel effects). It can't produce more electrical power out than the mechanical power going in. A battery or cap, on the other hand, can produce almost arbitrarily large powers until it is depleted.
I agree, this is all manageable.
My thoughts on this comes from experience with related problems in home photovoltaic power systems.
In the late 1990s, the Trace SW4048/5548 inverter models were very popular. These 4/5.5 kVA inverters are bidirectional; power can flow from the AC side to the 48V DC side as well as from the DC side to the AC side. This is useful in maintaining a battery bank at a constant voltage despite varying PV production and DC load, but it also led to problems in systems with more than one unit.
Two inverters are commonly used in larger (e.g., 5kW) grid-tied systems. They were typically wired in parallel on the DC side and connected to opposite 120V phases on the AC side.
Even if you set both inverters to the same "sell" voltage on their DC side, small differences in their internal voltage references often result in very different inverter power levels. You could even see one inverter "buying" (converting AC to DC) while the other "sold" (converting DC to AC), obviously a wasteful situation. This problem could have been easily avoided with a small dead band around the DC operating setpoint. This could also shut down the inverter at night, avoiding its idle power consumption.
Another problem comes from the use of a PV charge controller with this inverter. In a grid tied PV system, the charge controller is basically a safety device that protects the battery against an inverter or grid failure. Normally you always want maximum power from the PV array because the grid is an infinite energy sink and we can sell whatever we produce. During an outage or failure, though, we have to back off PV production to match local consumption. It does this whenever the battery bus voltage rises above a set point.
But the inverter is also trying to control the DC bus voltage. If you don't set them both up carefully, the charge controller could shut down the array unnecessarily. Again, an inverter dead band would have been very useful.
The bottom line is that all the devices on the DC bus must somehow coordinate their operation. If they communicate implicitly through DC bus voltage, then they need to agree on just what is meant by every possible value of bus voltage.
--Phil
Via the Eagle mailing list courtesy of AMSAT-NA Eagle@amsat.org http://amsat.org/mailman/listinfo/eagle