Issue found with the electricity

[DestroyFX]

1 - You should not be able to draw 300A from the APU (it's the same generator as the engine generator). You can turn everything ON without turning a Generator ON and actually fly.

2 - When you put the "Current" Dial to the APU, you always get the reading from the first BUS only. (I have improved the code where you have the original "It's evil hack" comment to add all BUS if your actually using the APU or 0 if your not using the APU. I did not add a check to blow a fuse I you draw to much juice, yet

3 - When you turn everything ON, you get 150A reading for Engine generator 1 & 3 and nothing bad append. The GT40 rated for 111A (it seam to be ok to pump up to 130A).

I found that paper about the powergrid of the tu-154m. The generators are the same, just need a confirmation if the system act the same way.

Also, what append if you actually draw to much juice on a generator, I guess it just a circuit breaker tripping but it's good to know. Also, if it's a circuit breaker, which one it is?

[kroki]

Yup, we are aware that electrical system is broken in many ways. My personal believe is that it should be rewritten from scratch rather than patched here and there. This is however a huge task.

Also, what append if you actually draw to much juice on a generator

If you mean main engines' generators, then any two out if three can fully power the plane, and if you left with only one you have to disable toilet pumps and kitchen water boiler IIRC.

[DestroyFX]

Yes, two is fine if you don't need anti-ice :)

[kroki]

Confirm, you made me recall that anti-ice indeed requires all three.

Re electrical current figures above: even in Russian language we do not have a complete documentation for every instrument and subsystem. So most per instrument current requirements are assigned more or less arbitrarily.

[DestroyFX]

I began to look and work on that. Got documentation here and here so it can be improved.

[kroki]

Re electrical system:

1. You are free to rewrite it completely, provided that the result won't be worse than the current one.
2. The current idea of registering consumers on the bus is a good one.
3. However instead of keeping track of consumer add/remove events current implementation at every invocation traverses the list of all consumers and calculates the sums anew - bad.
4. Currently you can't do setlistener() on .../busXXX/volts, because volts is constantly changing and the listener is invoked every frame which kills performance. So we need a .../busXXX/ok interger property, which is either 0 or 1, so that we can safely listen on it.
5. What do you think about the following proposal?: for every bus implement a list of callbacks for power up and power down events. So instead of checking the power at many places consumer implementation could register a callback that will be called when power state changes.

[kroki]

Or maybe I misunderstood you and you plan to only fix bugs mentioned above? In this case I'd say that the fixes won't live long, as we will rewrite the system completely anyway.

BTW, what's the state of engineer panel task? Will you do it later, or are you not interested in it any longer?

[DestroyFX]

The engineer panel have the switchs but I have to make model for the gauges and multi-select switch. I was out of time lately so I did not work on the model for a while. I plan to release it before the electrical system and yes I think I might rewrite it. I plan to keep total load of the different buses in memory and add/sub from it with apparatus are turned on or off. Adding the ok integer for each is a good idea and it can be controlled by other thing than the generator availability, Like the main circuit breakers for the buses.

[DestroyFX]

Are those are the circuit breaker and if so, do they have a on/off and a tripped state (like in the middle between on and off) ?

[kroki]

AFAIK they are indeed circuit breakers and have two positions: on and off.

[kroki]

What do you think about the following proposal?: for every bus implement a list of callbacks for power up and power down events. So instead of checking the power at many places consumer implementation could register a callback that will be called when power state changes.

After thinking a bit more I realized this is a bad idea since setlistener(".../busXXX/ok", ...) will do the same.

Thanks for the picture archive!