Ability of FO to control NGX flaps gets lost...

[KingGhidorah 209]

Sorry to bug you again with a new NGX issue, but there has been something going on that I just figured out that is really bothersome now that I understand it.

 

First some background.  I have 2 Saitek Throttle Quadrants.  I have my Flap handle on the second one.  Since starting to use NGX with MCE (which has been a long time), I rarely ever touch the flaps handle myself, I just call it out.  The handle remains in the full UP position for the entire flight, never moving.

 

I would notice that periodically the FO would just get totally screwed up.  You call for Flaps 1 and he would give you flaps 2.  You call for flaps 30 and he gives you flaps five.  I couldn't figure out why this would happen sometimes.

 

Now I have.  The second you manually change the flap handle, the FO starts to lose understanding of what the current flap setting is, and starts to screw up the commands..  It's not like the hardware flaps handle is sending a continuously active signal out (especially the way I have it set up in FSUIPC with gated detents that only inform FSX of a change), conflicting with MCE, or is the case of the flaps going right back to the Saitek flaps axis position, it's that the FO copilot just no longer understands the detents.  I imagine if it were the case of an axis conflict, then the flaps would always revert back to the detent corresponding to the hardware axis, but that's not the case.   Oddly enough, sometimes I can take him through the detents one at a time and get him to synch back up again.  Very strange

 

A similar situation happens if the user makes the mistake of loading MCE before NGX has initialized.  I'm not making that mistake of course, but the behavior is similar, as if once I change the flaps manually with my hardware, the FO reverts back to handling the flaps as if it were a default aircraft, instead of using the SDK for the NGX.

 

Please fix this.    As long as the Saitek flaps axis is not moving at the time of the verbal command, the FO shouldn't get hosed up like this.  This might be the case on other airplanes as well, I don't know, and I can check, but I think this is just on NGX.

[FS++ 707]

Please fix this.    As long as the Saitek flaps axis is not moving at the time of the verbal command, the FO shouldn't get hosed up like this.  This might be the case on other airplanes as well, I don't know, and I can check, but I think this is just on NGX.

 

 

Too late for tomorrow's update. But it will be looked at next week.

[KingGhidorah 209]

Yeah thanks for looking and no rush.  I'll try out a few other planes and see if the same thing happens, and maybe test some variations, like if it only occurs if the flaps are still in transit from a manual change, when the verbal command is given, or some things of that nature.

[KingGhidorah 209]

Good news, I think I managed to narrow it down quite a bit further!

 

I briefly tried out the Coolsky dc9 to see if I could reproduce the problem.  I found that I could put my flaps handle in any position, and then when I gave Trav a command to put the flaps elsewhere he would do so correctly.  So that made me think the problem must be limited to NGX.

 

Then I brought the NGX back up again.  Without touching my flaps handle, I told him to go to flaps 5, but then WHILE THE FLAPS WERE STILL IN TRANSIT, changed my mind and told him to go to flaps 2, as I said I was going to test that possibility.  That screwed him up.  He ended up giving me flaps 10.  From that point on he was hosed. 

 

So I killed the MCE process and started again.  I took him through several flaps detents gradually, making sure the flaps were firmly parked in the selected position before going to the next.  He did fine with that. 

 

Then I moved my Saitek Flaps handle to the 25 position and waited until the flaps were no longer in transit.  I then commanded Trav to go to Flaps 5...waited for the flaps to be at flaps 5, then ordered flaps 10, etc.  He did this all fine.

 

So I'm starting to think that this really isn't about the position of my Hardware flaps handle at all.  What I think might have happened before is that I grabbed hold of my Saitek flaps handle, suddenly remembered "Oh yeah, my copilot should be setting the flaps" and then gave him a Verbal command while the flaps were still in transit from the manual movement of my hardware lever.  So naturally I assumed it was the act of manually moving that flap handle that fouled him up, but.............

 

I'm thinking the real problem here is that if another Flaps command is issued while the flaps are still in transit, either from a previous verbal command, or from a hardware axis change,  then he loses all awareness of the everything, and it's very difficult to get him back in synch again.  The reason I don't see it too often, is probably because normally I'm slowing down gradually, and I'm commanding the flaps to go down or up on a very gradual schedule.  I probably didn't see it happen on the dc9 because correctly or incorrectly, that plane's flaps transit very rapidly.  Obviously I can't be 100% sure that this is the bottom line of what's going on or it has nothing to do with the position of my hardware flaps handle like I previously thought, but that's sure what its starting to look like after these latest observations.

 

Again thanks for looking into this, and I hope this observation can help.  Ideally, I would think you always want to have the copilot move the flaps handle to the last commanded position and be able to do so regardless of whether the actual flaps are still moving between detents

[FS++ 707]

 

 

Again thanks for looking into this, and I hope this observation can help

 

It did help. Thanks

 

Now minor issue sorted in latest version (2.5.9.4) for NGX. Will take longer for other aircraft. For some it might not be worth changing the current implementation.

[KingGhidorah 209]

Thanks.  It caused some annoying situations and bad approaches before, but it's not as big a deal even now though, now that I know why it's happening and how to avoid it.