We will do three experiments with the simulator in this session. These experiments I believe validate the value of a multi-node power system with load sharing.
Experiment 1
Will will put a constant load on each node (different amounts), load sharing will be turned off, and there will be no power generation (solar, etc.).
- Node 1 Load=.5 amps
- Node 2 Load=.15 amps
- Node 3 Load=.10 amps
- No Sharing
- No Generation (no solar)
Results
The simulator run-time is set for 7 days. Seven days should be long enough for most field exercises and to see various effects that may change on different days, etc.
This run should not be surprising since each node is on its own. Node 1 runs out of capacity in a little over a day, node 2 lasts about 4 days, and node 3 last almost 6 days. Remember, each node has 28 Ah of capacity and the simulator "drops" the load "off" if the capacity goes to 50% or less (14 Ah). This is the best practice for sealed lead acid batteries to ensure long life.
Experiment 2
Same constant loads on each node, but now load sharing will be turned ON, and there will be no power generation (solar, etc.).
- Node 1 Load=.5 amps
- Node 2 Load=.15 amps
- Node 3 Load=.10 amps
- Sharing ON
- No Generation (no solar)
Results
With sharing enabled we now see the benefits of the system. All the nodes last the same amount of time (about 3 days - Node 1 benefits the most). The way the the load sharing works in the simulator is that when a node's capacity drops below 21 Ah it sets a flag to request external power from another node (EXT on the trace). On a per node basis, looking at Node 1 for example, it will determine which other nodes it can get power from (in this case 2 or 3), then it will set a timer (currently set to 30 minutes, shorter and longer times will be tried in the future) and get power from that node for that period of time. Only one of these transfers can happen at a time. Looking at the graph above on the Node 1 line, you will notice the TIMER trace is active before the other nodes because it is the most heavily loaded node and needs help first. The TIMER trace is basically a saw tooth pattern, showing the timer counting down from 30 minutes. By day two the timers are active on all nodes and the load sharing is rotating between all the nodes in a round robin sequence. The L_ON trace shows whether the load are "on" or "off" for the node. All three nodes drop load at about the same time (late in day 3), though Node 1 sputters (intermittently goes up and down) due to it's heavy load. The nodes will continue to try to request a power transfer even though all the nodes have been depleted in this experiment. The simulation sets the power transfer level proportional to its capacity (at 14 Ah the transfer is nearly zero). This is needed because the nodes may get power from another source (e.g. like the sun when it rises). We will look at that scenario next.
Experiment 3
Here we have the same constant loads on each node, sharing is turned ON, and now Node 2 has generation from solar each day. The simulation code has a solar power curve for each node based on time of day. This was pulled from real data for Los Angeles, CA area from the web site HERE. There is a hourly performance data output section and I selected a day in November to use in the code (see below).
- Node 1 Load=.5 amps
- Node 2 Load=.15 amps
- Node 3 Load=.10 amps
- Sharing ON
- Node 2 generation (Solar)=3 amps
Results
With node generation (solar gains) things get even more interesting. As before Node 1 being the most heavily loaded of the nodes starts transferring power first. But now since Node 2 gets solar power each day it shares the most power out to the other nodes. The XL_ON trace shows when a node is providing power and Node 2 is consistently providing power from mid-day on day one of the graph. By day 3 the cycle of power for each node repeats (by the way, the graph is divided vertically into 7 days). Since the cycle repeats we can see that none of nodes drop load and this is a sustainable condition. The key to this multi-node concept is that the system is equal to "the sum of its parts" and the nodes can be relatively small in capacity individually but when combined, the system can handle higher loads than any single node alone.
Conclusion
I have learned a lot from this simulation and intend to do more experiments in future sessions. I know the simulation is not accurate to real-life in many areas but is very useful for the exploration of this idea. I hope to build components of the real hardware to validate and/or fix the model soon. The simulation has helped me realize that a simple "party line" bus may be the best and simplest way to build this system which will reduce the complexity of building a cross-bar switch and the master/slave A/B port communications. I am thinking of using RS-485 for node the communication and skip the fancy power line modem (PLM). This will require switch coordination so that the 300 VDC bus and RS-485 bus are not active at the same time, but that seems simple enough with isolation relays.
No comments:
Post a Comment