Throttle position

[rcbarend 37]

Hi Eugen,I'm almost 100% sure this is NOT possible.. (as least not from a gauge).Would be a function for FSUIPC or so.. (simular to deactivating trim checkbox))Regards, Rob

[taguilo 33]

Hi all,I hope never is too late to join a thread so much interesting as this one!Eric you asked:"So I ask the question again: How can I make the difference between a throttle movement that comes from the pilot and a throttle movement that comes from the AT system?"Well I guess you can use and to capture the joystick or key throttle movement, and redirect this to a LVar, scaled from 0 to 100, that will control the throttle bitmap and its position, and also set the power via a THROTTLE_SET event.When your LVar reads, ie, 90, you can enable FS9 Autothrottle in TOGA. You will notice power increases, but throttle lever bitmap stays still because LVAr maintains its value, and your joystick is still also, which is a perfect logic. In fact, it seems that it is much more real to imitate Airbus logic than Boeing, who maintain lever movement commanded by AT.This is a basic idea, lack of time to extend too much. But of course I could help If you need to deep more on.CheersTom

[rcbarend 37]

" This is a basic idea ......" Hi Tom,Yes, a very basic idea ...:-lol .. But I'm afraid it won't work...(as always, If I'm wrong I stand corrected).Your method could be used if a pilot doesn't use a throttle axis but ONLY keyboard keys or controller buttons to command the throttles.However, I assume most (if not all) pilots use a throttle axis (1 or more).Now, keyboard/button events (like INCREASE/DECREASE THROTTLE) can be trapped, but axis event (like Throttle_SET or Axis_Throttle_set) CANNOT. Because FS doesn't treat them like all other external event.There's easy proof for that:You obviously heard of the famous "continous event" problem, where a gauge that continuously gives events, interferes with multi-command operations like Pushback, SelectEngine/Exit, etc.Now, if Axis events would behave the same, a "jittering" axis would also cause this problem.. Which it doesn't.I.o.w.: axis events cannot be trapped, and therefore your "intercept" trick doesnot work; leaving the only way out (as described in a previous post): read the throttle position, and (if applicable) correct it.If you're interested: I have made an XML gauge, that keeps a one-four engines throttle quadrant synchronisised, and adds reverse thrust on the all axis. See attachment.I know you can add "reverse thrust on axis" via FSUIPC, but you need a registered version for that. Moreover, that doesn't synchronise the throttles....Cheers, Rob

[taguilo 33]

Hi Rob,Yes, you're right in something, "INCREASE/DECREASE THROTTLE" won't work for a throttle axis capture, BUT, sad to dissapoint you :-(, "AXIS_THROTTLE_SET" DOES work like a charm :-), at least in my FS9-WinXP-CHPRo Yoke config.Actually EVERY "AXIS" command can be trapped by as I guessed, (but honestly haven't tried deeply), the point is, you need to READ the proper parameter to get its value . For example:(A:General Eng1 Throttle Lever Position,percent) (>L:Tot,percent) 8000 (>K:THROTTLE_SET)When you move the throttle lever, you can get the correct lever position from the AVar, however your power will remain FIXED, because of the "8000 (>K:THROTTLE_SET)". I believe there is much to test here.Unfortunately, some bad: AT set ON inhibits the Event trapping, leading to the need of making a custom AT (which is long to code but not difficult at all IMHO)CheersTom

[rcbarend 37]

Hi Tom,Well, I'm not convinced yet about the "trapping" of axis events, but I'll do some more testing :-)Especially when you use multi-throttles.But IF :-) you are right (and FS uses the Axis_Throttle_Set for external axis input) while you use Throttle_set from a gauge, than you have a clear distinction whether an axis change is User-input or Gauge-input.But still, you can only "correct" a set user-input afterwards, not "intercept" it.. Right ??I also know that the axis is disbled when the AT is on; I already made various AT gauges, since I find the FS9 implementation of AT crap anyway..("oscillation").I'll let you know after I did some more tests.Cheers. Rob

[taguilo 33]

Rob,For multiengine throttles, "AXIS_THROTTLE1_SET", "AXIS_THROTTLE2_SET", etc should work.Now what I found so far, this event is being fired continuosly, I mean, it can be trapped at every cycle. I discovered in(A:General Eng1 Throttle Lever Position,percent) (>L:Tot,percent)...If you read the AVar, it shows the NEW position AFTER the event trapping, what means it just happened, and, as you said, it can't be "technically" intercepted, only "monitored". However, If you make a change like 8000 (>K:THROTTLE_SET) inside the structure, and read the AVar immediately after, you'll get the NEW value set by the (K:THROTTLE_SET)event, and THIS value will be returned by the simulator (ie a constant and FIXED power, no jitters). Finally, if you assign the AVar value to a LVar like (L:Tot,percent) inside the , and then use this LVar to set throttle's bmp position, it will match with the joystick's throttle lever position, REGARDLESS of the actual power. Am I clear enough?Waiting anxiously for your own testing results :-)Tom

[rcbarend 37]

Hi Tom,This gets better and better (and more confusing)Let me begin to say that you were RIGHT about trapping the axis events. Yes, it IS possible.. But there's a lot more to it, as you read from the following observations.And of course, my conclusions are only based on what I can observe.The test code I use: (G:Var3) ++ (>G:Var3) (P:LOCAL TIME,seconds) (>G:Var5) (G:Var1) ++ (>G:Var1) (P:LOCAL TIME,seconds) (>G:Var4) 8000 (>K:THROTTLE_SET) (A:General Eng1 Throttle Lever Position,percent) (>G:Var2) "Display the values of Var1 - var5" Note that the update freq. is 1 sec !!So the display is updated once per second.Besides this gauge, I use the default B737 ThrottleQuadrant gauge to observe the behaviour of the throttles (so the bitmap of the throttles is in ANOTHER gauge, based on reading the standard FS throttle variables).Then I slowly move the throttle axis of my CH yoke.Now, what I would have expected, if I stop moving the throttle:1. The value of Var1 and Var3 is the same (since each AxisTrottleSet event gives 1 ThrottleSet event.2. The value of timestamp Var5 (last ThrottleSet event) is 1 sec. later then timestamp Var4. Since the last TrottleSet event is trapped in the next gauge schedule3. Var2 displays ALWAYS the actual (physical) throttle position (so not 50%), since the A:Var is updated ONLY in the next gauge schedule after a generated ThrottleSet event.4. The visible lever in the ThrottleQuadrant gauge moves for a second, and then is set to 50% (because the gauge is scheduled once per second).Now, what really happens:1 and 3: as expected2. Sometimes Var4 and var 5 are equal, sometimes Var5 is 55 or even 110 msec. later (so NOT 1 second)4. While I am slowly moving the throttle lever on my yoke, the visible lever keeps moving as well; ONLY if I stop moving the lever, the visible gauge lever is Immediately (so not after 0-1 sec) set to 50%.My conclusions:1. Both OnEvent traps are NOT sequential (code order), but run in parallel, where the ThrottleSet trap always lags a bit behind the AxisThrottleTrap. This explains why the visible gauge lever keeps moving when I keep moving the physical lever.2. The event traps are NOT scheduled like the rest of the xml gauge (at 1 sec. , the display part). Very unexpected.Instead, FS processes them (and the trap code)as soon as possible. But it cannot keep up with the stream of events, hence the occasional difference in timestamps Var4 and var5, plus the fact that the visible 737Quadrant lever keeps moving while I move the physical yoke lever.The latter is also proven by the following:In the code above, I replace the AxisThrottleSet by a ThrottleFull trap. Now, if I repeat the same test (and keep key F4 depressed continuously), I see:In my XML gauge display (still at 1 sec schedule):- Var1 and var3 are constantly counting, but always equal.- Var4 and Var5 are always equal.- The visible lever on the 737Quadrant gauge is ALWAYS positioned at 50%, and doesn't jitter.In short, quite unexpected behaviour (at least for me).....What I also conclude from this test:1. You can use AxisThrottleSet and ThrottleSet traps, to distinguage between a user moving the physical lever and the xml gauge giving ThrottleSet commands.2. If you use local or L:Vars to display throttle bitmaps, you can avoid "jittering" bitmaps, but ONLY if these bitmaps use the L:/G: vars to display position, NOT the A:EngThrottlePosition variables.So it won't work for existing ThrottleQuadrant gauge.Any comment ???Cheers, RobEDIT: Allthough I haven't tried, the above probably also applies if you use individual throttle axis (1,2 etc. variants of the events)Also: I wonder if using a registered version of FSUIPC (when using throttle axis calibration) would have any influence.I'm almost certain it will be different, since FSUIPC cannot use AxisThrottleSet event, because these events (unlike ThrottleSet) cannot be commanded with negative values to command reverse thrust on the axis.So it must use either ThrottleSet events OR write directly to memory.In both cases, the "trick" of differentiating between AxisThrottleSet events (from the physical throttle lever) and ThrottleSet event (given by the gauge) is gone... SO still no solution :-)The behaviour of the EVenttrap code versus other XML code (schedule-wise) in the gauge reminds me a bit of Interrupt handlers in realtime C-code ... Maybe this IS implemented in a simular way...

[taguilo 33]

Hey RobGreat research!:-) Actually I think "AXIS_THROTTLE_SET" DOES support negative numbers; the problem is the aft physical position of the lever sends kinda "0" signal by default. Via FSUIPC calibrating I guess this "0" may be changed to , eg ,-16384 , and then "AXIS_THROTTLE_SET" could send, eg, -16384 (full reverse) with lever full aft, 0 (idle) with lever at middle and 16384 (full power) with lever full forward. But, now that we can trap this event, it should be possible to handle reverse power by code interacting with lever position. And I don't see the worth of trapping "THROTTLE_SET", since by this method you can't use the A:EngThrottlePosition variables as a mean of actual power, but rather as an "offset" position for a bmp display, and of course not directly but readed inside the through a LVar as you said (and I agree), to avoid jitter.At last, if you want to make a custom autothrottle, just use N1, SPEED, etc numbers to control it, like Jan commented before.Happy Findings!Tom

[rcbarend 37]

Hi Tom,See my post #28 for what I tested with Axis_Throttle_Set.I still think that trapping both Throttle_Set and Axis_Throttle_set can be usefull, because this gives you a good indication whether your own gauge commanded the throttle last, or the user did by moving the physical axis.In fact, I'm already converting my Reverser/Synchroniser gauge to use this new "trapping" function.Cheers, Rob

[Guest Eugen]

Hi,I have tried a number of different things to try to manage the throttle but my throttle overrides my xml commands and I get increase /decrease behavior.My idea for a way to work around this would be to unassign the throttle manually in fs9 and then code a c-gauge which reads the throttle position via directx and then communicate it to a L-var in a xml gauge. From the xml gauge the throttle could be set as needed.What do you think could that work ?Would any of you C-coders be interested to code such a gauge?BrgdsEugen

[rcbarend 37]

Hi Eugen,Yes, that would work..I just can't help you here, because I cannot create C-gauges.The reason you do see overrides, is that your throttle is probably jittering.But, if you make your code with the suggestions made above (with the traps for Axis_Throttle_Set and Throttle_Set commands) AND make your own throttle quadrant with the bitmaps IN the same gauge, it IS possible to avoid these "jittering" throttle bitmaps.Although of course the actual throttle in FS is still influenced by jittering, but you won't notice that because of the (relatively) slow reaction of the engines on throttle movement.Note however (I checked this with Pete Dowson, see his forum) that if you use the FSUIPC throttle axis calibration, FSUIPC also generates Trottle_Set command. So the distinction between pilot-throttle setting and gauge-throttle setting is gone. But even then your can solve it, by comparing your last-written command with the next read throttle value:- If it's the same: No external throttle input- If there's only a very small difference: caused by a jittering throttle axis- If it's a bigger difference: the pilot has moved the external lever(s)My statement is: if properly coded in XML (with throttle bitmaps position based on internal variables and NOT on the A: variable) it is ALWAYS possible to have non-jittering bitmaps.(with or without FSUIPC or jittering axis).But of course, directly reading axis position via DirectX, and processing it in your own gauge, IS the best solution. Just not available now :-)Cheers, RobCheers, Rob