@Marc,

>> Dem möchte ich doch insgesamt vorsichtig widersprechen.
Warum sollte man nicht VNAV nutzen?

Jein. Ja, weil theoretisch (auch laut PMDG, siehe unten) "drag required" auch kommen sollte. Tut es nur an der Stelle nicht.

Nein, weil sich die Aussage speziell auf die NG und eine kleine Praxisdiskussion mit nem Piloten bezog, was man in bestimmten Situation für Modi verwendet und welche eher nicht. Die NG ist wohl eher ein notorischer "VNAV-Disconnector" und macht das auch gerne im normalen Profil schon bei viel Rückenwind. Dazu ist die Speedbrake wohl etwas unkomfortabel für die Paxe. In der Praxis heisst das dann wohl, unbedingt vermeiden, bzgl. VNAV hinter den TOD zu geraten und eher davor schon den Descend einleiten. Oder eben gleich LVL CHG verwenden, wie schon gesagt.

Es scheint, dass Boeing den alten -300/400/500 AP kaum den veränderten Leistungsbedingungen angepasst hat. Ist halt ein low-budget Modell :D.

Scherz beiseite, ich denke bei Flugzeugen mit relativ clean wings und der sich daraus ergebenen Praxis "don't decelarate and descent at the same time" wird man generell vermeiden, weit hinter den top of descent zu geraten ? Insofern wäre die geschilderte Situation dann halt im Sinne deiner Quadratur des Kreises eher praxisfremd ?

@HP,

mehr Unterlagen kenne ich nicht. Ich denke mal, da es gerade beim ersten Release grosse VNAV Probleme gab, wollte PMDG das Thema nicht auch noch im Manual breittreten.

Zum Thema VNAV-Disconnect Bedingungen wurden in deren Forum aber mal etwas ausführlichere Infos gegeben :

-----------------
Now, under "normal" conditions, this is when VNAV will not engage / disconnect

- PATH : speed is over 20 knots above current target (real life : 15, but I relaxed it a bit). You will get the DRAG REQUIRED when speed is more than 10' knots above target.

- if the angle to be flown (inserting an alt constraint for instance) in greater than 7 degrees, VNAV should and will disconnect

- if there is a wpt with a speed restriction and no alt restriction

- if next alt (constraint or MCP) to be reached is under the AC in CLB or above it in DES

- if because of entering a too high cruize alt the path can not be constructed (no time to climb and descent etc.)

--------------------

Michael

@Marc,

>> Ein moderner Autopilot dürfte kaum so unintelligent ans Werk gehen, dass er blind versucht, eine gewisse Vorgaben (hier Höhe) zu erreichen und dabei die Maschine insgesamt in eine Gefahrensituation bringt.

hab noch vergessen, da hast du natürlich völlig Recht, korrigiert werden sollte das schon. Hierzu ein paar Infos aus dem AOM :

"The CDU message DRAG REQUIRED is displayed if an unexpected tailwind results in a siginificant increase in airspeed to maintain path. The CDU message DES PATH UNACHIEVABLE is displayed if the FMC determines that the planned descent profile cannot be accomplished. VNAV disengages if a limit speed will be exceeded."

Letzteres ist es dann wohl, was der PMDG an der Stelle fehlt. D.h., VNAV gar nicht erst zulassen, wenn das Profil eh nur mit einer Gefahrensituation erreichbar wäre oder wenn eh klar ist, dass es zu einer Disconnect Situation kommen wird.


Wo ich dich grad an der "Strippe" habe, noch ne Kleinlichkeit zu deinem Review. Da steht, dass es neben MZALFOTRI noch die normale Shift-Nummer Umschaltung der Panelfenster gibt (Shift-2, Shift-3, etc.). Das funktioniert bloss nicht, weil die Hauptpanelfenster übereinander gestapelt werden und sich so die Framerate halbiert. Wäre schön, wenn PMDG das auch noch korrigieren könnte , erst dann wäre es wirklich ohne MZALFOTRI bedienbar. Dann können sie auch gleich noch ne Option anbieten, letzteres ganz wegzulassen, es gehört ja wirklich nicht in ein authentisches Cockpit. Hat selbst den HLF-Copilot zu bissigen Bemerkungen veranlasst (MZALFOTRI ????, heisst der Designer so?). Ich finde die nur-Mauscockpits generell ein Ärgernis. Aber wie gesagt, eher kleineres Problem, die AP-Funktionalität ist sicher wichtiger.

Michael

Ja, sicher ist das Überschießen des TOD eine besondere Herausforderung. Aber es ist ja keine Fehlbedienung. In der Realität hat bei drehendem Wind oder sonstigen ATC Anweisungen der Pilot das ja auch nicht in der Hand.

Man kann es also nicht „unbedingt vermeiden“.

Damit muss eine Maschine schon klar kommen.

Ich persönlich habe auch den Eindruck, dass Speedbrakes in der Realität durchaus häufig benutzt werden. Ich habe es jedenfalls schon auf vielen Flügen gesehen.
Die PMDG potenziert das VNAV-Problem aber auch noch aus einem ganz anderen Punkt: Der TOD wird reichlich früh angesetzt. Entweder, man eiert noch 10-20 NM in geringster Höhe rum, oder man handelt sich VNAV Probleme ein...

Ja, „MZALFSDFSDFSFEF...“ ist ein echter Fluch. So schlecht hat das doch noch kein Cockpit gemacht. Wenigstens im Stile von Dreamfleet diese Leiste wegschalten können...

Übrigens
Folgendes Ergebnis ist interessant: Ich habe einen zweistündigen Flug mit der B737-700 gemacht.

Der Verbrauch entsprach dabei bis auf 200kg exakt dem von FOC berechneten Werten. Bei 10 000 kg Sprit kein schlechtes Ergebnis...

..für FOC und die 737...

?

Zehn Tonnen in zwei Stunden? War das eine 737 aus dem Ersten Weltkrieg oder hing der Bremsschirm etwas raus?
;)

HP

Marc,

>> Man kann es also nicht „unbedingt vermeiden“.
>> Damit muss eine Maschine schon klar kommen.

Ja klar, hast schon Recht ;). Bis das repariert ist, kann man es im Sim halt vermeiden. Schlimmer finde ich aber, dass man z.B. constraints während climb oder descend angeben kann und der Flieger vergisst dann (manchmal) seine MCP ALT und fliegt später einfach drüber weg. Wenn man die MCP ALT resettet, wird evtl. ein nachfolgender Constraint vergessen. Schöne Überraschung :rolleyes:. Wenn das in der Realität passieren würde, möchte ich nicht die Kommentare im Cockpit hören.

Yup, Performancedaten, Fuelflow, etc. sind wirklich erste Sahne !
Wo wir gerade bei Highlights sind, mich faszieren die lateralen Funktionen und das Autoland. Letzteres lässt sich auch durch härteste Bedingungen nicht irritieren und fliegt die Kiste ruhig und sicher auf den Boden. Wenn PMDG die VNAV Funktionatität auch noch so bulletproof hinbringt und die fehlende FMC-Funktionalität nachschiebt, wüsste ich nicht wer sowas noch übertreffen sollte.

@HP,

LOL ! :D :D

Michael

waren ja noch 4,9 übrig... :D

http://homepage.ruhr-uni-bochum.de/m...g/tmp/bugs.jpg

Der Flieger ist mit aktivem LNAV- und VNAV-Modus mittig auf der Route. Geschwindigkeit (etwas langsam per default) und Höhe (entspr. Step-Clim Tabelle) sind ebenfalls korrekt.

Aber: Die RTE Page ist ab der zweiten von vier Seiten leer. Die LEGS Page zeigt alle Waypoints. Gleichzeitig zeigt die Progress Page für alle Waypoint „0 fuel“ an und warnt permanent „insufficient fuel“ (gerade gecleart auf dem Bild) an. Der Treibstoff ist mit REM 4,7 mit FOC berechnet und sollte +/- 10 auch stimmen.

Hallo Marc,

ich bin genau da heute morgen auch reingelaufen. Solange du DIRECT entries in deiner ROUTE page hast, läuft alles normal. Das Programm denkt aber, alles wären DIRECT entries. Sobald du auf einem Airway-Segment bist, schmeisst das Programm nach jedem Passieren eines Wegpunkts eine ganze Zeile aus der ROUTE Page raus. Das heisst, wenn du 8 Zeilen in deiner Route Page hast, sind die nach Passieren von 8 Airway-Wegpunkten weg und deine ROUTE Page ist leer.
Ein klassischer Bug ;)

Michael

der bereits behoben ist - SU2 ist nicht mehr weit :)

HansJuergen

PS: der thread hat ja noch Chancen ;)