Can't engage/use CWS
-
@mysticfm , ok, lemme try.
I've used FSUIPC for stuff like this some time ago, before switching to AAO. I find AAO more user-friendly when doing more advanced stuff like scripting.First create (or edit) file with RPN macros. Locate FSUIPC folder,
for me that isC:\Program Files\FSUIPC7.
In there find or create a file namedmyevents.txt
Add these two lines into this file:DukeCwsPress#1 (>L:var_PilotCws_IsDown, Number) 1 (>K:AUTOPILOT_OFF)
DukeCwsRelease#0 (>L:var_PilotCws_IsDown, Number) 1 (>K:AP_PITCH_LEVELER) 1 (>K:AUTOPILOT_ON)This will create macros
DukeCwsPressandDukeCwsRelease.
Now (re-)start FSUIPC. It has to be restarted upon editing the myevents file.
Go to Buttons and Switch assignments window,
press the button to use for CWS,
optionally select Profile specific to apply only to this plane,
enable Select for Preset,
in the Control sent when button pressed field findDukeCwsPressand in the button released field below findDukeCwsRelease,
press OK to close the window, and you should be set.
Now try it out, as a first indication, you should see the CWS button on the virtual yoke move when you press your button, if we set up everything right.Let me know if it works. I haven't used FSUIPC in a while.
-
R Randolf referenced this topic on
-
FWIW my solution is spad is that I have my yoke's pitch rocker controlling trim with a conditional test. IF ATT engaged then incr/decr the AP pitch wheel ELSE incr/decr the standard trimmer. I pretty much copied that from my F28 setup and it works fine on the Dukes.
The only thing that catches me out is when I switch to ATT mode from ALT to start a descent the AP pitch can still be left in the climb position which results in an unwanted pitch up. I may see if I can cheat and do an auto centre of the trim when engaging ATT.
-
@Black-Square said in Can't engage/use CWS:
I haven't found a good way to implement a true CWS mode with the native MSFS autopilot yet, but it will resync your pitch when you release the button. This means you can make small adjustments (while the autopilot is fighting you), or resync the pitch before engaging attitude hold mode.
As is so often the case, your comment has given me inspiration for a possible solution, though! I will experiment later to see what I can do! What I have in mind should work, it's just a question of how well and smoothly.
Is that something likely to make it into the Dukes in a near-term patch? I might wait, if so, rather than experimenting with FSUIPC.
@Randolf Thanks for the pseudo (or correct, haven't tried it) FSUIPC code. If I give it a whirl, I'll let you know how it works. Events/RPN is something I haven't yet tried to do in FSUPIC, just some basic non-standard assignments through LVars and Lua scripting.
-
@jmarkows - I’ve now done a flight with it, and it seems to work fairly well. I had a couple of times where releasing the button caused the ATT mode to resume level flight rather than holding my chosen attitude, but a second try got it to capture in each case.
-
@KRoy7 you're probably not using the PMS50 GTN750 unit, it doesn't seem to like the AP_PITCH_LEVELER event, but instead AP_ALT_HOLD.
However, I copied the ATT button code from the aircraft files and updated my solution. The scripts now look a bit complicated, but seem to work at least with the KLN90B, PMS50 GTN750 and no-GPS setup that I was able to test:
button press:
1 (>L:var_PilotCws_IsDown, Number) 1 (>K:AUTOPILOT_OFF)release:
0 (>L:var_PilotCws_IsDown, Number) 1 (>K:AUTOPILOT_ON) (L:PMS50_APGA_RUNNING, bool) (L:PMS50_APGA_ACTIVE_VERTICAL_MODE, number) 3 == and (L:PMS50_APGA_RUNNING, bool) ! (A:AUTOPILOT VERTICAL HOLD, bool) (A:AUTOPILOT ALTITUDE LOCK, bool) or and or if{ 1 (>K:AP_ALT_HOLD) } els{ 1 (>K:AP_PITCH_LEVELER) } (A:PLANE PITCH DEGREES, Degrees) 15 min -15 max (>L:var_AP_PitchKnob, number)I shared some of my AxisAndOhs templates for the Duke here:
https://gitlab.com/randolf.lemmont/fs-bksq-duke-modsThe CWS button is part of the
Duke APtemplate shared there. -
@Randolf - getting into some Booleans there, I see … which makes sense, as my added flights today indicate the misbehavior is indeed dependent upon the current state of the autopilot. I only wish I knew if FSUIPC also supported this kind of expression; the advanced manual for it is kind of a headache, huh?
-
@mysticfm these expressions will work in FSUIPC also. Just copy the button release long expression and put it on a single line (with space separating each line) behind
DukeCwsRelease#you have in myevents file, replacing the previous version.
Though there may be a way to use multi line strings in that file, but you'd have to read the docs. -
@Randolf - forgive me for having to report this, but the updated release macro doesn’t seem to work any better in FSUIPC at least. The button still activates properly, and engages ATT mode if that mode hadn’t been engaged before … but if I press the button when ATT mode was already engaged, the mode doesn’t get re-enabled upon button release. If this is only an issue for FSUIPC (which I understand you no longer use), don’t worry about it … I can work around it until I learn enough above the macro programming to fix it myself (it looks like the macros use RPN ordering, yes?). If/when I do fix it, I’ll post my FSUIPC version.
-
@mysticfm If you copied the code correctly, it should not be an issue of FSUIPC, it should work the same as for example in AAO, at least I don't see any obvious incompatibilities in the code that would be AAO specific.
Which GPS panel configuration are you using?
If I understand your problem correctly, when you are in ATT mode and press and then release the CWS button, autopilot re-engages but in a different mode than ATT? Which one?
-
@Randolf - I’m confident I copied the code correctly. I’m using the PMS50 GTN 750 (licensed). What happens when I engage the button when ATT is already engaged is that the autopilot re-activates afterwards, but does not re-enable ATT mode (e.g., if it was in HDG + ATT prior to engaging, after releasing the button it will only be in HDG mode).
Edit: here's the contents of my MYEVENTS.TXT file (the DukeCwsRelease is all one line without line breaks, and with spaces where the line breaks were in your AAO example):
DukeCwsPress#1 (>L:var_PilotCws_IsDown, Number) 1 (>K:AUTOPILOT_OFF)
DukeCwsRelease#0 (>L:var_PilotCws_IsDown, Number) 1 (>K:AUTOPILOT_ON) (L:PMS50_APGA_RUNNING, bool) (L:PMS50_APGA_ACTIVE_VERTICAL_MODE, number) 3 == and (L:PMS50_APGA_RUNNING, bool) ! (A:AUTOPILOT VERTICAL HOLD, bool) (A:AUTOPILOT ALTITUDE LOCK, bool) or and or if{ 1 (>K:AP_ALT_HOLD) } els{ 1 (>K:AP_PITCH_LEVELER) } (A:PLANE PITCH DEGREES, Degrees) 15 min -15 max (>L:var_AP_PitchKnob, number) -
@mysticfm it is weird.
If you're up for some debugging, you could try this slight modification of the release script, which "clicks" the ATT button only if it was not on before:
DukeCwsRelease#0 (>L:var_PilotCws_IsDown, Number) 1 (>K:AUTOPILOT_ON) (A:AUTOPILOT PITCH HOLD, Bool) ! if{ (L:PMS50_APGA_RUNNING, bool) (L:PMS50_APGA_ACTIVE_VERTICAL_MODE, number) 3 == and (L:PMS50_APGA_RUNNING, bool) ! (A:AUTOPILOT VERTICAL HOLD, bool) (A:AUTOPILOT ALTITUDE LOCK, bool) or and or if{ 1 (>K:AP_ALT_HOLD) } els{ 1 (>K:AP_PITCH_LEVELER) } } (A:PLANE PITCH DEGREES, Degrees) 15 min -15 max (>L:var_AP_PitchKnob, number) -
@Randolf - sorry to tell you that didn’t work at all … I couldn’t even make the autopilot stay engaged at any point, regardless of the CWS button, not even by hitting the button on the autopilot itself. When I’d release the button, it would engage the autopilot for a fraction of a second and then immediately turn it off again. I’ll go back to the previous script for now, which at least allowed the AP to be used. 😊
