On 2/11/2020 at 2:28 PM, LecLightning56 said:

Thank you very much for your exhaustive advice and instructions. Having tried this out, it does seem to work very well.

I am encountering an annoyance with the PMDG 737NGXu with 'approach hold on'. Even with the benefit of Voxscript, the PNF always responds with 'you must select autopilot or flight director to select such MCP mode' (or words to that effect). Setting 'approach hold on' in MCE with e.g. the PMDG 747 QOTS II is not a problem. Although an annoyance, please investigate and see if this is working correctly with the PMDG 737NGXu (it certainly is not at my end).

Thank you again for the benefit of your kind advice and I look forward to your comments about the PMDG 737NGXu in due course.

OK, tested with very latest MCE version (V2.8.3.2) and couldn't replicate.

It's possible the issue was there in earlier versions.

For FO to select approach mode, you need either FD or AP engaged as well as a valid ILS frequency on NAV1 set (not CDU) (Example 110.300)

I suggest you update to latest MCE package and we'll take it from there.

 

2 hours ago, FS++ said:

OK, tested with very latest MCE version (V2.8.3.2) and couldn't replicate.

It's possible the issue was there in earlier versions.

For FO to select approach mode, you need either FD or AP engaged as well as a valid ILS frequency on NAV1 set (not CDU) (Example 110.300)

I suggest you update to latest MCE package and we'll take it from there.

 

I need to explain myself a bit further. I am using the latest MCE package 2.8.3.2, as you have recommended. What I have been trying is setting up the PMDG 737NGXu on an approach using the FSiPanel 2017 tool. This essentially sets up an aircraft in a trimmed and configured state for an approach which the user specifies in terms of the airport, runway and the type of an approach which is being flown (e.g. ILS, RNAV etc.). I am starting up MCE when the aircraft has been setup on such an approach. The ILS frequency is generally set automatically by FSiPanel 2017 and, for example, for EDDM RW26R, the ILS is 108.70 which is set correctly in the NAV panel of this aircraft (as you have stated). However, when instructing the PNF to set 'approach hold on', I am still greeted by 'you must select autopilot or flight director to select such MCP mode' when both the flight director and autopilot have themselves been selected in an armed state automatically by FSiPanel 2017. I am puzzled by this behaviour unless perhaps MCE is confused by the fact that the FD and autopilot had been set automatically by FSiPanel 2017 prior to the activation of MCE by me. 

If you have any further thoughts or suggestions, then please let me know. Even better if you have the FSiPanel 2017 tool (JP, the developer, is a professional airliner pilot who no doubt uses this tool to hone his own landing skills) in which case if you would very kindly give things a try and report back.

Edit:

I have just done a flight from EDDM from RW26R and following a RH pattern to land on the departure runway. I am beginning to think there might be something wrong with my setup. The PNF responds with a statement that the autopilot is on when commanded, but nothing happens in the cockpit to the CMD button (i.e. off and unlit). Also, when intercepting the localizer, the PNF will still refuse to set 'approach hold on' for the APP button. I shall go away and do a fresh uninstall/reinstall of the PMDG 737NGXu and report back later, but at least this exercise dispenses with considerations of the aircraft being thrown into an airborne situation initailly without having formally taken off.

Edited February 13, 20206 yr by LecLightning56

I have just tried a LH pattern in the PMDG 747 QOTS II from RW19 at KVPS. I seem to have an issue with PMDG aircraft in activating/deactivating the autopilot using MCE. It seems to take forever more with the PNF to engage/disengage the autopilot by which time (particularly on the approach) you have completely missed your cue to fly manually and might just have well pushed the infernal button yourself. I always seem to be fighting the PNF to do anything with the autopilot. Also, with the 747 QOTS II, once having commanded engagement of autopilot, the PNF confirmed autopilot armed but nothing happened in the cockpit to the CMD button (i.e. not depressed and illuminated). Perhaps this suggests a lack of communication between the MCE confirmation and what is physically activated in the cockpit. I can confirm, however, that arming the approach hold did occur in the 747 QOTS II with the PNF. Something is not being passed through into the model in my setup.

So, I am not entirely sure why MCE seems to 'walk away' from doing anything with the autopilot (other than possibly a safety issue), but there are obviously occasions when manual flying of the aircraft is in the best interests of safety (I would presume that most approaches are flown manually in their latter stages).

I have not given up yet with MCE and it could be my system playing up somewhere as explained above, but it does seem futile frothing at the mouth with a PNF who is not interested in playing with the autopilot!

One further thought which perhaps you could assist with is: is MCE intended only for startup to shutdown operations, or should it be able to pick things up at a more advanced stage in the flight, i.e. engines running ready for takeoff or indeed as I have explained above setting the aircraft up directly to practice an approach (with e.g. the FSiPanel 2017 tool)? Why I ask is that when flying the LH pattern with the 747 QOTS II, having touched down and requested reverse thrust to be selected, the PNF rather hilariously went into 'takeoff' mode and started calling out the V speeds! It may well be that I am pushing the limits of acceptable use of MCE and it gets hopelessly confused about the actual flight stage I am in, so please correct me If my expectations of its applications are too great currently but I would have thought that basic commands should be followed fairly succinctly by the PNF, irrespective of the flight mode.

Edited February 13, 20206 yr by LecLightning56

I have just tried the iFly 737-800 on an approach setup by FSiPanel 2017, with success. 'Approach hold on' and 'disengage autopilot' both worked correctly, the PNF does question the Captain when requesting autopilot disengagement but a firm response of 'affirmative' is acted upon and the CMD button is deactivated. Also, no confusion about the flight mode since I was able to request reverse thrust succesfully. So, I am left thinking that my woes are PMDG-related and am not sure if it is unique to me (installation of the product) or if it is MCE which gets confused.

49 minutes ago, LecLightning56 said:

I have just tried a LH pattern in the PMDG 747 QOTS II from RW19 at KVPS. I seem to have an issue with PMDG aircraft in activating/deactivating the autopilot using MCE. It seems to take forever more with the PNF to engage/disengage the autopilot by which time (particularly on the approach) you have completely missed your cue to fly manually and might just have well pushed the infernal button yourself. I always seem to be fighting the PNF to do anything with the autopilot. Also, with the 747 QOTS II, once having commanded engagement of autopilot, the PNF confirmed autopilot armed but nothing happened in the cockpit to the CMD button (i.e. not depressed and illuminated). Perhaps this suggests a lack of communication between the MCE confirmation and what is physically activated in the cockpit. I can confirm, however, that arming the approach hold did occur in the 747 QOTS II with the PNF. Something is not being passed through into the model in my setup.

So, I am not entirely sure why MCE seems to 'walk away' from doing anything with the autopilot (other than possibly a safety issue), but there are obviously occasions when manual flying of the aircraft is in the best interests of safety (I would presume that most approaches are flown manually in their latter stages).

I have not given up yet with MCE and it could be my system playing up somewhere as explained above, but it does seem futile frothing at the mouth with a PNF who is not interested in playing with the autopilot!

One further thought which perhaps you could assist with is: is MCE intended only for startup to shutdown operations, or should it be able to pick things up at a more advanced stage in the flight, i.e. engines running ready for takeoff or indeed as I have explained above setting the aircraft up directly to practice an approach (with e.g. the FSiPanel 2017 tool)? Why I ask is that when flying the LH pattern with the 747 QOTS II, having touched down and requested reverse thrust to be selected, the PNF rather hilariously went into 'takeoff' mode and started calling out the V speeds! It may well be that I am pushing the limits of acceptable use of MCE and it gets hopelessly confused about the actual flight stage I am in, so please correct me If my expectations of its applications are too great currently but I would have thought that basic commands should be followed fairly succinctly by the PNF, irrespective of the flight mode.

No, MCE isn't a scripted adventure with you needing to remember in which flight phase you are or make assumptions regarding your next move (what to say and when).

It's a fully interactive crew simulation, with tens of thousands of available speech commands, making no assumptions as to which state the aircraft is in.

Almost all potentially disruptive commands are safeguarded against accidental trigger. THerefore, no need to hold your breath, worrying what may happen when speech engine picks-up "all irs off", "full flaps" or "shutdown engine one". Fo is smart enough to ask you to re-consider the request.

By default, keeping silent for the next 10 seconds or so means "ignore that request"

FO works out flight phase automatically. You can even re-start MCE mid-flight and FO will be in synch.

You can ask him to help you with what you want, when you want, and even using your own speech if you can't be bothered to stick to stock grammar speech.

Had a look at the FSiPanel website.

It does list PMDG 737 as supported and doesn't uise FSUIPC. Verry likely using SDK. 

The dev needs to be aware that the PMDG SDK for the NGXu has changed very slightly. Almost identical with subtle differences that could cause issues.

Aside from that, I suggest you don't run that add-on for a few sessions and report back.

1 hour ago, FS++ said:

No, MCE isn't a scripted adventure with you needing to remember in which flight phase you are or make assumptions regarding your next move (what to say and when).

It's a fully interactive crew simulation, with tens of thousands of available speech commands, making no assumptions as to which state the aircraft is in.

Almost all potentially disruptive commands are safeguarded against accidental trigger. THerefore, no need to hold your breath, worrying what may happen when speech engine picks-up "all irs off", "full flaps" or "shutdown engine one". Fo is smart enough to ask you to re-consider the request.

By default, keeping silent for the next 10 seconds or so means "ignore that request"

FO works out flight phase automatically. You can even re-start MCE mid-flight and FO will be in synch.

You can ask him to help you with what you want, when you want, and even using your own speech if you can't be bothered to stick to stock grammar speech.

Had a look at the FSiPanel website.

It does list PMDG 737 as supported and doesn't uise FSUIPC. Verry likely using SDK. 

The dev needs to be aware that the PMDG SDK for the NGXu has changed very slightly. Almost identical with subtle differences that could cause issues.

Aside from that, I suggest you don't run that add-on for a few sessions and report back.

I have just tried a LH pattern with the PMDG 737NGX (in the absence of FSiPanel 2017) and I can report significant problems. I have been having to repeat multiple times to set the speed and the PNF still does not want to play ball with the autopilot and will not disengage it when requested. So, I am getting very hoarse with the PMDG aircraft (737 and 747), whereas things seem to flow more sweetly with the iFly 737-800. That the PNF is obedient with the iFly aircraft and behaves very stubbornly with the PMDG 737 may not be due to any direct errors on my part. I am not sure that I can progress much further with my investigations on account of repetitive issues with trying to kick the PNF into action. It is as if the PNF with the PMDG aircraft takes a backseat and loses interest, with very sluggish response: why there is a contrast here with the iFly aircraft where things seem to be normal and as expected is very puzzling. 

12 minutes ago, LecLightning56 said:

I have just tried a LH pattern with the PMDG 737NGX (in the absence of FSiPanel 2017) and I can report significant problems. I have been having to repeat multiple times to set the speed and the PNF still does not want to play ball with the autopilot and will not disengage it when requested. So, I am getting very hoarse with the PMDG aircraft (737 and 747), whereas things seem to flow more sweetly with the iFly 737-800. That the PNF is obedient with the iFly aircraft and behaves very stubbornly with the PMDG 737 may not be due to any direct errors on my part. I am not sure that I can progress much further with my investigations on account of repetitive issues with trying to kick the PNF into action. It is as if the PNF with the PMDG aircraft takes a backseat and loses interest, with very sluggish response: why there is a contrast here with the iFly aircraft where things seem to be normal and as expected is very puzzling. 

There is another possibility...

Since "mcpmd73X.dll" in \Prepar3D v4\ folder needs to handle both older NGX and newer NGXu, please check dll is identifying loaded aircraft properly.

Start NGXu in cold and dark.

Engage battery (so the CDU becomes available) and establish contact with ground mechanic with "cockpit to ground" or "ground from flight deck.

Once mechanic replies, ask him to connect ground power with command "ground connect ground power " or "mechanic connect ground power.

The GPU connection is done with clicks via the FMC CDU

Make sure the clicking sequence is OK and that GPU becomes available.

Is it the case?

 

1 hour ago, FS++ said:

There is another possibility...

Since "mcpmd73X.dll" in \Prepar3D v4\ folder needs to handle both older NGX and newer NGXu, please check dll is identifying loaded aircraft properly.

Start NGXu in cold and dark.

Engage battery (so the CDU becomes available) and establish contact with ground mechanic with "cockpit to ground" or "ground from flight deck.

Once mechanic replies, ask him to connect ground power with command "ground connect ground power " or "mechanic connect ground power.

The GPU connection is done with clicks via the FMC CDU

Make sure the clicking sequence is OK and that GPU becomes available.

Is it the case?

 

I have followed your instructions and everything works as described. I just repeated a LH pattern with the iFly 737-800 and again everything went very well, with the PNF very responsive and all commands followed accordingly. Very stark contrast to the PMDG experience. One other thing, when attempting to set a course of 196 degrees in both the iFly 737-800 and the PMDG 737NGXu, every attempt resulted in a course of 096 degrees being set. Not sure if this is a bug.

Edited February 13, 20206 yr by LecLightning56

5 minutes ago, LecLightning56 said:

I have followed your instructions and everything works as described. I just repeated a LH pattern with the iFly 737-800 and again everything went very well, with the PNF very responsive and all commands followed accordingly. Very stark contrast to the PMDG experience.

Do one more test with older NGX if you have it.

The CDU clicking sequence is different.

That would rule out any issue with MCE confusing NGX with NGXu and vice versa.

The requests you make to FO are handled the same way. I mean behavior is the same.

Issue could be with reading autopilot switches state in those dlls inside \Prepar3D v4\MCE dlls\ folder. There is a different one for each supported complex aircraft

I forgot one more thing. Make sure "Prepar3D.exe" is set to run as admin.

What about leaving FSiPanel out of the equation.

It could be that it's not reading data from NGXu correctly and keeps fighting FO's actions.

14 minutes ago, FS++ said:

Do one more test with older NGX if you have it.

The CDU clicking sequence is different.

That would rule out any issue with MCE confusing NGX with NGXu and vice versa.

The requests you make to FO are handled the same way. I mean behavior is the same.

Issue could be with reading autopilot switches state in those dlls inside \Prepar3D v4\MCE dlls\ folder. There is a different one for each supported complex aircraft

I forgot one more thing. Make sure "Prepar3D.exe" is set to run as admin.

What about leaving FSiPanel out of the equation.

It could be that it's not reading data from NGXu correctly and keeps fighting FO's actions.

Right, I have done the test with the older PMDG 737NGX and it was successful. I have left FSiPanel out of the equation in all my recent tests. 

One further thing, when attempting to set a course of 196 degrees in both the iFly 737-800 and the PMDG 737NGXu, every attempt resulted in a course of 096 degrees being set. Not sure if this is a bug.

I am not sure what your test criteria were for your investigations, but I would invite you to try the PMDG 737NGXu from e,g, the default airfield of KVPS (Eglin AFB), flying a LH pattern departing and returning to e.g. RW19 at KVPS, using MCE for autopilot selection and for speed/flaps approach hold etc. and report your findings. I have horrendous problems with this aircraft whereas the iFly 737 does as expected. 

I call on other NGX (or NGXu) users to perform the test suggested above to see if it's a common issue. Thank you.

10 hours ago, LecLightning56 said:

I shall go away and do a fresh uninstall/reinstall of the PMDG 737NGXu and report back later.

This may have caused a side issue.

The NGX has a specific option that must be enabled in order for aircraft to provide data, otherwise, Fo won't see MCP switches status

Go to \Prepar3D v4\PMDG\PMDG 737 NGX\ folder and open "737NGX_Options.ini"

Make sure you see

[SDK]
EnableDataBroadcast=1

If not, manually add those lines.

Normally, when you install MCE, it automatically edits the ini file. But when you remove aircraft to re-install it, the setting goes away.

Do the same for the other NGXu variant under  \Prepar3D v4\PMDG\PMDG 737 NGXu\ folder.

 

10 minutes ago, FS++ said:

This may have caused a side issue.

The NGX has a specific option that must be enabled in order for aircraft to provide data, otherwise, Fo won't see MCP switches status

Go to \Prepar3D v4\PMDG\PMDG 737 NGX\ folder and open "737NGX_Options.ini"

Make sure you see

[SDK]
EnableDataBroadcast=1

If not, manually add those lines.

Normally, when you install MCE, it automatically edits the ini file. But when you remove aircraft to re-install it, the setting goes away.

Do the same for the other NGXu variant under  \Prepar3D v4\PMDG\PMDG 737 NGXu\ folder.

 

I have checked both entries and they match these lines. Hopes initially raised but may have to sleep on this one and hopefully another user may report his/her findings shortly so that we can compare notes.

I seem to have made a little progress today. Things are a little better with the PMDG 737NGX but I am still having autopilot problems. What seems to be happening is that when a command to arm is autopilot is given, the CMD button is activated but then an autopilot disconnect warning is sounded in the cockpit, with a response by the PNF that a fault has occurred and the autopilot could not be switched on. Bizarrely, the CMD button remains illuminated and the aircraft continues to fly as if under autopilot control (with the CMD button illuminated). It could be that the autopilot is simply just not being engaged correctly by MCE which explains why it has been loath to select 'approach hold on' on account of MCE thinking that AP had not been engaged (despite the CMD button remaining illuminated). This sounds like a bug, but I am not sure if it is domain of PMDG or if there is something amiss in MCE.

If I fly a pattern without MCE, the autopilot can be engaged successfully without a warning sound in the cockpit. It looks as if something may be amiss in MCE.

One further thing of note, the PMDG 737NGX does have setting in the FMC for realistic/unrealistic autopilot engagement. Which do you recommend for MCE?

Edited February 14, 20206 yr by LecLightning56

Let me try to offer some (limited) experience and comments:
I do not own the NGXu (yet). So, for the NGX:

having touched down and requested reverse thrust to be selected, the PNF rather hilariously went into 'takeoff' mode and started calling out the V speeds! It may well be that I am pushing the limits of acceptable use of MCE and it gets hopelessly confused about the actual flight stage I am in…

I remember having had a similar experience a copule of times (at most) when making circuits for testing purposes, with the FO believing to handle a T/O. It may happen that the plane does not transition to the “landing mode” (I do not recall the specific details of this, though. Prior altitudes?). It is for this reason that on touchdown the autopilot is disconnected first thing (I use the autopilot master bar command).

have just tried a LH pattern with the PMDG 737NGX (in the absence of FSiPanel 2017) and I can report significant problems. I have been having to repeat multiple times to set the speed and the PNF still does not want to play ball with the autopilot and will not disengage it when requested.
I never experienced this. In general, I have a feeling that a complete or reasonably long flight should be performed, maybe some “ FO misconceptions” do creep in.

In general, the conditions controlling the final leg of the flight are very complex. Reference should be made to the Boeing FCOM, Chapter 4: Automatic Flight, particularly to the Go-Around Section (4.20.16 onwards).

Lastly:
when attempting to set a course of 196 degrees in both the iFly 737-800 and the PMDG 737NGXu, every attempt resulted in a course of 096 degrees being set

I asked a similar question some time ago, it is a true effect. I recall that this is indeed a deliberate choice, in order to avoid possible confusion. One should use a complete phrasing such as “one hundred ninety five”, since three-digit numbers beginning with "1" might be misinterpreted as Radio frequencies.

Hope it might help
Giorgio