Can't engage/use CWS
-
@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 AP
template 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. 😊
-
This post is deleted!
-
@ExcessionOCP here you can find my AAO templates for the Duke. The CWS button is part of the AP template. You can selectively apply parts of the templates if you don't want the extra stuff and if you're not using HC Bravo throttles, you can rebind your own buttons there.
https://gitlab.com/randolf.lemmont/fs-bksq-duke-mods -
@Randolf Thanks! I do have the HC Alpha and Bravo so I think I'll be using most of this! One last question though, I guess the script defines the behaviour of the CWS when it's triggered, but I just wanted to check - do you still have to map a hardware control to the CWS part of the script in order to trigger it?
-
@ExcessionOCP not sure what you mean, but my CWS script implements custom (experimental) behavior that is different from the switch in the virtual cockpit. It has to be triggered for example by button binding. Check the binding for it included in the template. It calls the script with parameter 1 on press and 0 on release.
-
@Randolf Cool, thanks for that - I'm totally new to A&O so apologies for my probably stupid questions :-) I'll have a read through the scripts later (I'm an IT infrastructure engineer so am familiar with scripting) and will hopefully work out what's going on!