"TAKEOFF SPEEDS DELETED" message

[Martin Baker]

Martin,

If the loadsheet comes back as "compliant" you don't update anything before take-off. That's the point of the "compliant" message - it means no before-take-off updates are necessary.
At appropriate time after take-off you then enter the updated values.
Peter.

Thanks, Peter - for some reason I read your message the other way. Now I'm clear! Martin.

[Jeroen Hoppenbrouwers]

Good idea, but that might look like a feature of the real FMC and confuse the students ... :-)

In blue! In blue! PS1 compliant    :-D

[G-CIVA]

Steve, the new option will be on the Instructor > Model > FMS page and will replace the old "V1 disable" bit in the Preferences.

I think BA and Qantas inhibit the V1 computation only. Is it still the case or are all three V speeds manually entered?

Hardy,

Regarding the "V1 Disable" - sounds like a more elegant solution.

You probably know the answer to the V Speeds display regarding the NG FMS.

Qantas however did not & probably will not opt for it (NG FMS) since their fleet will be gone in just over 18 months ... on their aircraft the crew have to manually enter all the V Speeds ...



Cheers

[Hardy Heinlin]

When I entered the temperature, the V-Speeds were deleted as usual, but the related FMC message "TAKEOFF SPEEDS DELETED" didn't appear.

Now I can tell you more about it. This is intentional. The reset logic will only be armed when 30 seconds have passed since the last situ file was loaded. This delay is necessary to assure all weather parameters are stabilized. Thereafter, when you change a relevant parameter or when the weather changes such that it causes a V speed deviation greater than 1 knot, the FMC will reset the V speeds and trigger the message as expected.

I'll keep this delay because the systems are pretty interactive and sensitive; I don't want to risk any nuisance effects just for getting a shorter stabilization delay after situ file loading.

Of course, this won't happen in real life as there are no situ files to be loaded in real life. But for the sim operation such tricks are necessary.

(For example, there's another delay for the MCP ALT push button's multifunction. It only functions when 10 seconds have passed since the last situ file loading. The delay is necessary because a lot of interactive FMC parameters need to be stabilized before the FMC can decide which of the multiple functions is to be executed and what target needs to be set.)


Regards,

|-|ardy

[Jeroen Hoppenbrouwers]

Just asking: if you would load a new .situ and immediately stop motion, this would still allow all relevant variables (except motion-related) to stabilize? So if you would switch, stop, count to 30, release, you would have prevented any of the artificial temporary lockouts?

Hoppie

[Hardy Heinlin]

It's mainly about OAT and things like that. E.g. when a real-world weather situ is loaded, the data may change within the next 30 seconds. The point is to avoid any long-term motion freeze when a situ is loaded (or when a new network client is connected).

But nevermind. I just implemented an exception for manual takeoff ref changes. So the initial 30 sec delay will just affect weather related V speed resets. Manual changes may now reset them immediately after situ loading.


|-|ardy

[Hardy Heinlin]

The modifications discussed in this thread are now implemented in PSX 10.74:

http://aerowinx.com/board/index.php?topic=4191.0


|-|ardy

[Dirk Schepmann]

Vielen Dank Hardy!

I didn't have the time to follow this thread in the past days and still can't believe that this is already fixed in an update. I was not aware of the 30 second delay. After reading your explanations I understood and hope that you didn't implement this feature only because of the complaint of a hobby simmer. 😉

Best regards,
Dirk