Version: SU4 1.16.19
Frequency: Consistently
Severity: Blocker
Context: in flight
Bug description:
The Pneumatic system in MSFS 2024 needs a lot of work, there are far too many flaws and issues as it stand with it, making is pretty much impossible to be fully used by aircrafts at this stage, the following issues were observed after several days of attempting to implement a full bleed system as per Embraer diagrams:
-
Single PACKs modules are not supported, the system believes each engine should have 1 PACK.. this is not the case, several aircraft out there use single cooling system units, which run independent of engines. Typical example Phenom 100E and Phenom 300E, there are NOT Two packs (one for each engine), there is a compressor unit, heat exchangers, and refrigerant coolant passing thru fans an evaporators. Since the MSFS Pneumatic systems only provides PACKS as cooling devices (a part form RAM AIR) the most logical way to provide cooling is by installing 1 PACK which would simulate those components to mix cool air with the hot air valves.
However if you only put 1 PACK, when engine 1 is OFF and engine 2 is Running, no pressure runs towards the single PACK unit despite of junctions and valves operating correctly.
Adding a “dummy” second pack, and leaving it’s circuit off, then allows the single pack to receive air pressure from any engine, which confirms, the system is limiting bleed to packs based on a configuration that is symmetric..
-
PACKS are limiting the bleed lines of the entire system, even when there are lines full of pressure from engines into lines going to outlets / hot air independently of PACK units, if the pack is OFF (as switched off not powered off) the system stops providing bleed pressure to the entire simulation. This is incorrect since the engine is still providing flow, is just the PACK / Cooling device is not set to be ON, the hot lines need to continue having bleed pressure, allowing anti ice systems and other to continue operating. This bug has been reported on another topic already, but I wanted to have the feedback her for Asobo review.
-
PACKS Can drive the circuit power output above the configured electrical load of the circuit, for example I set my
CIRCUIT_PNEUMATICS_PACKto have a voltage of 28V and max amp of 190 as per IRL. If the flow on the pack / volume is very high, it can drive the power output up to 500 - 700amps at high flow (which was set at 1.0), this trips the configured circuit breaker set at 250Amps and the system collapses because the PACK is now dead (unable to power on).I understand the objective is to put more load into the circuit as the PACK works harder, but it should never exceed the consumer configuration in the electrical circuit, if it is working at 100%, the load power output should be 100%, not 600% to 900% as I saw it doing it.
The work around was to configure the PACK flows a bit higher of what the engines can supply, otherwise at high altitudes, you can have undesired effects, leading also to circuit overload scenarios and unrealistic output loads in relation to the real world. Phenoms in the real world while they are on ground at max cooling during hot days, the max amp would be between 135A to 190A (depending of fans speeds and setpoints in the cockpit) and as you climb, this reduces to 30A - 80A as the compressor drive needs to work less intensive. So the concept you guys have is good, but it should not exceed the configured MAX POWER LOAD in the electrical circuit.
-
Setting a PACK minimum and max output outside the default AreasMinTemperature and AreasMaxTemperature parameters in the general configuration for PNEUMATIC will results in the console logs saying the pack is configured wrong, and the minimum output and maximum will be overridden.. yet I see on the debug the temperatures following the PACK parameter, so what’s the correct way to do it? makes no sense.. and I think this is a contributing factor to problems in the cabin failing to stay at set point.
-
Areas are cooling off / heating off FAR TOO FAST towards ambient temperature when the ECS is stopped, for example, consider an aircraft flying at 15,000 feet, sunny, day.. outside temperature is -8C, the cabin temperature reaches 25 CÂş Set point, you turn off the PACKs, or cut the flow of air to the areas and in a manner of 20 seconds the areas are now at -8C. This is totally unrealistic, IRL it would take quite a while for the heated areas to reach a setpoint to outside world, up to 30 minutes in some cases depending of the setpoint outside. This applies to lose cooling or lose heating.. in both cases the result was unrealistic.
-
I am unable to understand how to configure the #bleed parameter for the Areas, the example given in the documentation is very confusing, 1st it says the parameter is required as areas are always linked, this is not true, you can have managed areas that are not linked at all to the passengers sections, for example, cargo heating areas on the baggage, these would have no bleed into other areas at all.. Second, if I have two Areas: Cockpit → Main cabin, I have no idea how to see the #bleed since the example is for a 3 area array from the Boeing max example, I attempted to set it as: #Bleed:2, 0.15:1 (2 areas) but the system complained on the logs about this and not matter what I did, the log never cleared, examples you guys have, have also areas with no #Bleed configured, and yet if I do this, the debug logs complain utterly about it and never gets cleared.
-
Opening the cabin door didn’t had any effect on temperature equalization for the areas.. despite they were configured to have this on the opening names configuration. IMO this should also be a configurable setting, some doors are smaller than others, you could have windows that are very small, main doors, etc.
-
The documentation says Lines support a parameter of Volume, this is not the case, once I put this parameters in the lines, the entire system didn’t compile.. looks like volume configuration on the lines is not supported. Documentation is also talking about APU inside the lines.. so probably something is there wrong in the documentation.
-
The debug PNEUMATIC was unable to force the wings anti ice ON, no idea why.. so unable to test it.. looks like it cannot force the anti-ice system index 0 to ON / OFF, if I create a second outlet of WingDeice type, then the index 1 is able to come on / off.. but not the index 0.
-
Often as you climb with Areas that are very small in M3, the PIDs lose grasp of what s happening and the entire temperature set points go high wired.. is like there is a battle between the PACK PID trying to control an Area vs a HOT Valve trying to do the same.. and suddenly a HOT Valve is left closed always, because you are very high now, the area equalizes too quick to outside temp (unrealistically) and now the pack is unable to keep the warm, resulting in having an area at -8C from a set point of 24C while two other areas remain at 24C.. then suddenly it switches back to HOT air and it jumps from -8 to 30C in few seconds.. granted it could be PID tweaking, but I was using the Boing configuration to see if I was having problems with my config and same problem occurred, same issue with the advance airliner sample provided.
-
FANS are not working properly either, I could not make them work.. maybe a miss configuration, the example of the larger airliner says there are fans going to the MIXER, but is not true, there are no fans configured.. same thing in the Boeing 737 MAX, so no idea if this is my fault or something I am doing wrong.. IRL Phenom has a ground cooling FAN connected to the external world, so this goes ON and pushes fresh air to the MIXER, similar to RAMAIR, but is a FAN.. so this is something to consider to allow developers to do.
Overall the system is promising, but I feel there are far too many bugs with it that makes it very difficult to be adopted, I am now in the process of writing my own ECS Simulation as otherwise I cannot move several projects forward, I understand the team is busy with SU4 / PS5, I am happy to wait until we can discuss this further and help you guys improve this system much more so more developers can have a better use of it.
I will be providing a project privately by the end of the week so you guys can use to test what I am describing above, etc. but note I achieved these issues also with the examples provided in the SDK documentation.
Many thanks for your attention.
Raul