Jump to content
Sign in to follow this  
jstnj

Elevator trim wheel MSFS

Recommended Posts

Hello!

Does anyone know if its possible to use a script similar to a rotary knob where the controller (in this case a Flight Velocity trim wheel) increases or decreases the axis value instead of mapping 1:1 with the axis of the physical controller?

What I am trying to prevent is the "jumping" of the elevator trim access when you disable autopilot, where my physical trim wheel position does not match the position in the sim. I would like the controller to work independently, only incrementing/deincrementing the axis.

 

I tried doing this, but I dont think thats how the "trigger direction" is meant to work because it does nothing in sim, nothing is triggered.

 

 

Any help is appreciated!

Share this post


Link to post
Share on other sites

There is a read variable for trim, could you not use that as a feedback value for keeping your wheel in sync with the sim?


WW5130.png

| i9-10900F - 2080Ti | 32 GB RAM | Win 11 Pro | HC Bravo | AAO | StreamDeck | Air Manager |

Share this post


Link to post
Share on other sites
7 minutes ago, mrm0508 said:

There is a read variable for trim, could you not use that as a feedback value for keeping your wheel in sync with the sim?

It's not a motorized wheel, so unfortunately that wouldn't do anything in this scenario.

Edit: I think I see what you are saying, but my question still stands about how to do that.

Edited by jstnj

Share this post


Link to post
Share on other sites

Does that wheel have stops or is it rotating (and sending data) continuously? And what kind of event does it send, axis or button?

Such a script is possible (INC/DEC with an axis), but when the wheel has stops (where it is not sending any data beyond that point) it can't really work. (= for example when you are already at the stop but need to turn that way). You would have to make sure to turn the wheel to the middle position before engaging it. I've only used scripts like these or the trigger mode of an axis with spring loaded things like joysticks.

Edited by Lorby_SI

LORBY-SI

Share this post


Link to post
Share on other sites
14 minutes ago, Lorby_SI said:

Does that wheel have stops or is it rotating (and sending data) continuously? And what kind of event does it send, axis or button?

Such a script is possible (INC/DEC with an axis), but when the wheel has stops (where it is not sending any data beyond that point) it can't really work. (= for example when you are already at the stop but need to turn that way). You would have to make sure to turn the wheel to the middle position before engaging it. I've only used scripts like these or the trigger mode of an axis with spring loaded things like joysticks.

its spins continuously...however if you look at it in AAO you can see it has limits from 0 - 65535 I think. But effectively its limitless because you can turn the sensitivity waaay down and you can spin it many, many times without reaching the limits.

Edited by jstnj

Share this post


Link to post
Share on other sites

The spinning of the wheel is not the problem, it is the value range. If you are already at 0 or at 65535, you cannot trim any further in that direction, even when the wheel itself can still move physically. 

What aircraft is this for? Default trim controls?

I made a similar script recently for a different purpose, but the principle remains the same:

Script group: "Custom" 
Script name: "Trim"
Script Code: "(L:Custom-Trim)·(L:TrimValOld)·<·if{·1·(>K:ELEV_TRIM_DN)·}·els{·1·(>K:ELEV_TRIM_UP)·}·(L:Custom-Trim)·(>L:TrimValOld)

This script you assign to your wheel axis in AAO. 

See how it works? The script variable contains the axis value 0 to 65535. This is compared to a local LVar that holds the previous axis value to determine in what direction you are turning - and the appropriate trim event is triggered. Then the axis value is saved to the comparison variable for the next check. Make sure to get group and script names right, because they determine the name of the script variable (L:scriptgroup-scriptname). So if you rename the script, you have to change the variable name too.

Edited by Lorby_SI

LORBY-SI

Share this post


Link to post
Share on other sites
9 hours ago, Lorby_SI said:

The spinning of the wheel is not the problem, it is the value range. If you are already at 0 or at 65535, you cannot trim any further in that direction, even when the wheel itself can still move physically. 

What aircraft is this for? Default trim controls?

I made a similar script recently for a different purpose, but the principle remains the same:

Script group: "Custom" 
Script name: "Trim"
Script Code: "(L:Custom-Trim)·(L:TrimValOld)·<·if{·1·(>K:ELEV_TRIM_DN)·}·els{·1·(>K:ELEV_TRIM_UP)·}·(L:Custom-Trim)·(>L:TrimValOld)

This script you assign to your wheel axis in AAO. 

See how it works? The script variable contains the axis value 0 to 65535. This is compared to a local LVar that holds the previous axis value to determine in what direction you are turning - and the appropriate trim event is triggered. Then the axis value is saved to the comparison variable for the next check. Make sure to get group and script names right, because they determine the name of the script variable (L:scriptgroup-scriptname). So if you rename the script, you have to change the variable name too.

This worked @Lorby_SI, thank you!! The only question I have is, is it possible to increase the perceived "sensitivity" by changing the "1·(>K:ELEV_TRIM_DN)·}" to "2·(>K:ELEV_TRIM_DN)·}" etc? I tried this and didn't really notice a difference. For most aircraft your script works perfectly, but for some GA aircraft it would be beneficial to have a ~20% faster response.

If not, no big deal, this script works and thanks a lot for sharing it. I tried to name the thread as something people might catch in a forum search so hopefully others may find it useful too.

Share this post


Link to post
Share on other sites

Hi, any chance of a copy of the script? I have the same problem and all this scripting is gobblygook to me. Thanks in advance,

Share this post


Link to post
Share on other sites
2 hours ago, jstnj said:

his worked @Lorby_SI, thank you!! The only question I have is, is it possible to increase the perceived "sensitivity" by changing the "1·(>K:ELEV_TRIM_DN)·}" to "2·(>K:ELEV_TRIM_DN)·}" etc? I tried this and didn't really notice a difference. For most aircraft your script works perfectly, but for some GA aircraft it would be beneficial to have a ~20% faster response.

You wrote that you can adjust the turning "speed" of the wheel?

You can repeat K-Events by using the (>K:ELEV_TRIM_DN|n) syntax, n being the number of repeats. In your case 1 (>K:ELEV_TRIM_DN|2) . But doing this has a downside too - your trim actions are only half as accurate.

Another option would be to calculate the rate of change = how fast you turn the wheel and use that as the multiplier. This would require 3 scripts, but I'm not sure that this will work so well for trims.

Something like this:

TrimAxisRel 
(L:Custom-TrimAxisRel)·(L:TrimValOld)·-·s1·(L:Custom-TrimAxisRel)·(>L:TrimValOld)·l1·abs·(>L:triprep)·l1·0·<·if{·1·(>K:Custom-TrimDown)·}·els{·1·(>K:Custom-TrimUp)·}

TrimDown
1·(>K:ELEV_TRIM_DN|@triprep)

TrimUp
1·(>K:ELEV_TRIM_UP|@triprep)
 

 

Edited by Lorby_SI

LORBY-SI

Share this post


Link to post
Share on other sites

I'll give this ^ a go, thanks again.

Yes the trim wheel does have a sensitivity setting, but your script seems to not acknowledge any changes in the sensitivity (which I think is expected, glancing at the script itself). Hopefully this one is a slight fix for that.

Man, reverse polish notation is like greek to me...I wish there was a python Simconnect API lol 😞

Share this post


Link to post
Share on other sites
4 hours ago, jstnj said:

I'll give this ^ a go, thanks again.

Yes the trim wheel does have a sensitivity setting, but your script seems to not acknowledge any changes in the sensitivity (which I think is expected, glancing at the script itself). Hopefully this one is a slight fix for that.

Man, reverse polish notation is like greek to me...I wish there was a python Simconnect API lol 😞

That is theoretically what the WebAPI in AAO is for. Write your stuff in Python, LUA, VisualBasic, whatever, call it using the EXEC command from AAO (next version can do Http POST Requests too), return the action using XmlHttpRequests with JSON.

The obvious downside is performance, this is too slow for critical "live" events like the trim.

Edited by Lorby_SI
  • Like 1

LORBY-SI

Share this post


Link to post
Share on other sites

I am relatively new to AAO and wondered if I could do similar without an axis?

I have the Bravo which has a wheel but it uses buttons.

The aim is to not get the big change in trim after the autopilot is switched off just prior to landing.

Thanks

Share this post


Link to post
Share on other sites
36 minutes ago, chrisnoy said:

I am relatively new to AAO and wondered if I could do similar without an axis?

I have the Bravo which has a wheel but it uses buttons.

The aim is to not get the big change in trim after the autopilot is switched off just prior to landing.

Thanks

Not sure I understand that.

What the OP descibes is a situation where a wheel is used to change trim, and that wheel is in an unsuitable position when the AP is switched off - that, as far as I understood, causes the "jump". When you are using buttons, this shoule be of no concern  - the increment/decrement caused by the ELEV_TRIM_UP, ELEV_TRIM_DN events is always the same, and it is usually very small. There shouldn't be any "big change" at all.


LORBY-SI

Share this post


Link to post
Share on other sites

Maybe my understanding is wrong but I assumed that when the AP is on it adjusts the trim to a setting required to fly whatever the plane needs to do whether it is an approach or just a straight and level. Lets say the AP adjusts the trim to -3.0?. When I switch AP off what will my trim value be?

Are you saying that it will be -3.0 and any adjustments I make using buttons just increments this value slightly? I have noticed large jumps do sometimes occur so assumed the two values of trim will be different when AP is switched off.

 

Cheers

 

Share this post


Link to post
Share on other sites
6 minutes ago, chrisnoy said:

Are you saying that it will be -3.0 and any adjustments I make using buttons just increments this value slightly?

When you are only using buttons, yes. The above mentioned events are only for incrementing/decrementing the current trim, they don't carry any positional information. If the trim jumps for you in this scenario, then that must have a different cause. 

Things are different when using the trim axis and a wheel - obviously, as the physical, external wheel control is not moving with the autopilot, so the trim axis value can be way off.

6 minutes ago, chrisnoy said:

When I switch AP off what will my trim value be?

Only the aircraft developer can answer that question. The expected behavior is that turning the AP off will not change the current trim. But what actually happens is determined by the code in the aircraft.

Edited by Lorby_SI

LORBY-SI

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...