Can't engage/use CWS

mysticfm

@Randolf - Once I actually followed your directions correctly :) I do see the CWS button animating. Thanks much … now I’ll see if/how it actually functions with the autopilot engaged.

brennan

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.

jmarkows

@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.

mysticfm

@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.

Randolf

@mysticfm
Hm, that's interesting, I didn't yet run into the problem that it wouldn't hold the new pitch, but had suspicion that it may happen under some circumstances. I'll try to find a workaround.

Randolf

Yea, just found out that it behaves wildly different with different GPS units present. My testing was only with KNS90B, there it seems to work fine. Now trying with PMS50 GTN it doesn't work at all :)

KRoy7

I have solved this issue (e.g. workaround) using SPAD.next as follows (I'm using GTN750/GTN650):

Randolf

@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-mods

The CWS button is part of the Duke AP template shared there.

KRoy7

Indeed I am using the PMS50 GTN750. But I have to send the leveler event twice, as the first press activates GP, second press activates ATT. But so far it's working as desired.

mysticfm

@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?

Randolf

@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.

mysticfm

@Randolf - Thank you for the help. I definitely intend to dig into FSUIPC programming, but for right now I’m too busy trying to learn to fly the Duke along with trying to learn to talk to BeyondATC …

mysticfm

@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.

Randolf

@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?

mysticfm

@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)

Randolf

@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)

mysticfm

@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. 😊

Randolf

@mysticfm oh no, I found a small typo in the expression. I edited my last post, you could try to copy it from there again.

mysticfm

@Randolf - thanks much, I’ll try it again in the morning.

mysticfm

@Randolf - your last update to the FSUIPC macros seems to be working flawlessly. Thank you!

Boy, being able to use the CWS switch goes a long way toward making me like this Century autopilot.