There may be some details like this that are different between Boeing aircraft that we missed.
IRL at least on the 757/767 and A320 the AP doesn't disenage at all on its own!
It's funny to watch in the real sim when pilots are trying to vacate the runway via a suitable taxiway only to find out that the still engaged AP prevents that.
Max.M Sounds pretty dangerous to me if it disconnects on it' own at 80kts during the roll out, especially during a CAT III landing!!!
Don't know about the newer 737s, but on the older 737s the AP disengages at touchdown because the AP doesn't have a rollout capability.
Sounds pretty dangerous to me if it disconnects on it' own at 80kts during the roll out, especially during a CAT III landing!!!
You are right, I might have read a source for another aircraft. The AP *might* disengage at full stop, or needs to be manually disengaged; but I could not find enough sources to support either sides. The AP should not disengage at 80kts at all.
When release new aircrafts, some older aircraft may have some uniformity errors. For example, some functions have been implemented on the B737 but not on other Boeing aircraft. The features on the 737 appear on other aircraft. Sometimes the same mistakes as those made by PMDG Boeing aircraft will occur.
But I think this is understandable, because maintaining uniformity in code writing between models can facilitate timely correction of problems. Some features still need to be completed.
What is gratifying is that these aircraft are continuously updated by IPACS in a short period of time. And all have the necessary cockpit functions. It is hoped that IPACS can continue to solve these problems through the accumulation of time. 
Aerofly FS 4——————PMDG777 in Prepar3D v5——————Real B777 in PilotsEYE
I used published a continuously updated post in 2022. Although I was not an experienced player at that time. The IPACS's update implements a large part of the functions that have been mentioned.
Keep in mind that there are also different systems and software versions installed in real world aircraft. Just because you see it in one video does not mean it doesn't exist in a different aircraft.
Keep in mind that there are also different systems and software versions installed in real world aircraft. Just because you see it in one video does not mean it doesn't exist in a different aircraft.
Jet-Pack (IPACS) This sentence pointed out something to me. Perhaps it's not about different system versions between aircraft but rather about the nature of input parameters. Here, I should apologize for my earlier assumptions. The aircraft systems are operating normally, but the set parameters are not.😂
After consulting the PMDG forum, I discovered that this minor error had already been fixed in the PMDG737 for MSFS2020. Maybe I should shift my focus to their upcoming PMDG777 for Microsoft Flight Simulator instead of the outdated P3Dv5.
According to clues provided on the PMDG forum, the appearance of the 'NO V SPD' prompt after landing is achieved through a timer. Their developers emphasized that modifying data should come from documents provided by the manufacturer rather than videos. However, I still couldn't find this clue in publicly available materials.
Because I was overly convinced that this error was happening at all times, I overlooked some other potential possibilities.
You previously mentioned, 'Could also be a different logic depending if you perform a full flight or if you started the flight on (short/long) final approach.' I reflected on this statement, and in the just-completed full flight, the correct result appeared. 'NO V SPD' did not appear prematurely. Although this wasn't my first time conducting a full route flight, it was something I had overlooked in previous tests—being too certain about the incorrect fact to notice the correct scenario.
After a series of comparisons, I found the true cause of this issue:
2. When I manually input the APP REF page, I manually entered VREF, and everything simulated correctly after landing.
So, the only difference is: the data input by the game is a smaller number, while the data I input is a larger number. Therefore, the conclusion is clear: the smaller number is not the actual input, or it merely displays a number on the PFD without providing the Fly-By-Wire with the actual V-speed. Thus, discrepancies occur after landing with the smaller number, while manually inputting the number presents no issues.
Perhaps the next step is to figure out how to transform the smaller number into the larger number without modifying any aircraft system logic. That's it. Once again, I apologize for my earlier assumptions!
Inserting a VREF deletes the V2 speed in our implementation. The VREF is then displayed in capital letters to show that it is a manually entered value and not an automatic value from the FMS.
The NO VSPD label probably does not check if the VREF speed value exists yet, but we can change this in an update.
The FMS resets after landing after about 30 seconds. This may not be exactly how the Boeing FMC works. But when it resets the V-Speeds are deleted together with most manually entered values.
Guys I finally found the reason!
After numerous testing, it turned out that the ROLLOUT feature WITH REVERSERS (the non R/T mode always worked) is available and working. However, the only way for it to work is to engage thrust reversers in a veryyyyy short window: AFTER touchdown BEFORE auto brakes activation. (In the 777 it would be when the back of the main landing gear is on the ground and the front still in the air)
Since these features are implemented and the only problem is the timing, IPACS can we a fix in the near future? Please?
The autopilot has no input from the autobrake so this logic can't be right. As far as I know the autopilot remains engaged when you use reverse when the airplane remains on the ground. If you pull reverse in flight then the autopilot disengages. It might be that you bounce and the ground sensor momentarily sends weight off wheels signal and the autopilot then disengages.
The autopilot has no input from the autobrake so this logic can't be right. As far as I know the autopilot remains engaged when you use reverse when the airplane remains on the ground. If you pull reverse in flight then the autopilot disengages. It might be that you bounce and the ground sensor momentarily sends weight off wheels signal and the autopilot then disengages.
Thanks for the clarification, I didn't use the correct term. However I tried everything and the only time it works is when I engage while the gear is like this:
Once the main gear is fully down it doesn't work...
btw I'm on the Mac version.
