P3D v4 (A:AUTOPILOT ALTITUDE LOCK VAR, feet) and (>K:AP_ALT_VAR_SET_ENGLISH)

[ark1320]

I am trying to understand the relationship between (A:AUTOPILOT ALTITUDE LOCK VAR, feet) and (>K:AP_ALT_VAR_SET_ENGLISH).
Am I correct that (A:AUTOPILOT ALTITUDE LOCK VAR, feet) is the Avar that represents the result of the event (>K:AP_ALT_VAR_SET_ENGLISH)? And if so, the code

(A:AUTOPILOT ALTITUDE LOCK VAR, feet)  (>K:AP_ALT_VAR_SET_ENGLISH)
doesn't do anything since the Avar is the value from the K event in the first place.

So, for example, both lines below produce the same result because after the first line the value of the Avar is 12500.

12500 (>K:AP_ALT_VAR_SET_ENGLISH)
(A:AUTOPILOT ALTITUDE LOCK VAR, feet)  (>K:AP_ALT_VAR_SET_ENGLISH)

Or am I confused?
Thanks,
Al

 

[rpmc]

Am I correct that (A:AUTOPILOT ALTITUDE LOCK VAR, feet) is the Avar that represents the result of the event (>K:AP_ALT_VAR_SET_ENGLISH)?

That's right.


So, for example, both lines below produce the same result because after the first line the value of the Avar is 12500.

12500 (>K:AP_ALT_VAR_SET_ENGLISH)
(A:AUTOPILOT ALTITUDE LOCK VAR, feet) (>K:AP_ALT_VAR_SET_ENGLISH)

Maybe yes but I suggest you check it to be sure. Events are queued and executed in order at the end of the gauge update cycle. If these two lines are executed one time only and in the same gauge update cycle, I'm not sure, without testing it myself, that the AVar is updated to 12500 before the second line, (A:AUTOPILOT ALTITUDE LOCK VAR, feet) (>K:AP_ALT_VAR_SET_ENGLISH), is executed. Depends when the AVar is updated.

Bob

 

[ark1320]

Maybe yes but I suggest you check it to be sure. Events are queued and executed in order at the end of the gauge update cycle. If these two lines are executed one time only and in the same gauge update cycle, I'm not sure, without testing it myself, that the AVar is updated to 12500 before the second line, (A:AUTOPILOT ALTITUDE LOCK VAR, feet) (>K:AP_ALT_VAR_SET_ENGLISH), is executed. Depends when the AVar is updated.

Bob,
Ah, good point -- thanks. And thanks for the chart!
Al

 

[WarpD]

In my opinion... this:

(A:AUTOPILOT ALTITUDE LOCK VAR, feet)  (>K:AP_ALT_VAR_SET_ENGLISH)

is nonsense-code. It's taking the value that is set by (>K:AP_ALT_VAR_SET_ENGLISH) and setting it again. For the life of me I can't possibly fathom a reason to read the value and set it to what it is already set to. Why?

 

[rpmc]

Yeah, I agree, but I took it as just an example to expand on his question, not so much as a snippet from working gauge xml?

Out of curiosity, I tested the code as written and there is indeed a sequencing issue as suggested. If, for example, (A:AUTOPILOT ALTITUDE LOCK VAR, feet) was 10000 before the two lines of code were executed, then it remains 10000 afterwards even though 12500 (>K:AP_ALT_VAR_SET_ENGLISH) is the first line. Looks like all the queued events are executed before the A:Vars are updated. If you don't play around with gauges for a couple of months you forget this stuff.

Bob

 

[ark1320]

In my opinion... this:

(A:AUTOPILOT ALTITUDE LOCK VAR, feet)  (>K:AP_ALT_VAR_SET_ENGLISH)

is nonsense-code. It's taking the value that is set by (>K:AP_ALT_VAR_SET_ENGLISH) and setting it again. For the life of me I can't possibly fathom a reason to read the value and set it to what it is already set to. Why?

Exactly so! That was a contrived example to confirm my understanding of the relationship between the Avar and the K event, and why I said

(A:AUTOPILOT ALTITUDE LOCK VAR, feet)  (>K:AP_ALT_VAR_SET_ENGLISH)

doesn't do anything since the Avar is the value from the K event in the first place.

Al

 

[rpmc]

doesn't do anything since the Avar is the value from the K event in the first place.

technically, that's not really what is going on ... see my edit to #5 above

 

[gaabne]

Great Event versus A-Vars table - something I was dreaming for long time.
Some relations are not obvious at all - does this exits for other Avars/Event family ?

Gérard

 

[WarpD]

doesn't do anything since the Avar is the value from the K event in the first place.

technically, that's not really what is going on ... see my edit to #5 above

That's strictly a process loop delay. Because when you're inside your "code", the sim only provides a snapshot of the variable value. There isn't a single variable that updates instantly and especially not to a gauge's code's "viewpoint". Despite it being an XML gauge, it's still treated like a C/C++ gauge in that it's update section is processed 18.2 times per second.
Even for a C/C++ gauge... once in the PRE_UPDATE service ID cycle... no matter how many times you call lookup_var to get the value for AUTOPILOT ALTITUDE LOCK VAR... it will return the value from the latest "snapshot" that was done before calling the PRE_UPDATE.

 

[rpmc]

Thanks. I wasn't trying to suggest that any update occurs instantly, decoupled from the gauge update cycle. Just making the point that the xml gauge developer should be mindful that all queued events are processed sequentially at the end of the update cycle and after that, A:Vars are updated.

 

[Geoff_D]

Since this is being discussed here, I will jump in here (rather than starting a new post in the MSFS area -- as I am assuming the same problem exists in P3d, that I a seeing in MSFS)

I am trying to implement in a KAP140 AP, changing the ALT hold value in 20ft steps
(This happens in the RL AP, if you are in ALT mode, and press the UP / Down Buttons, as opposed to using the rotary switch, which will do 1000 and 100 ft increments .

The problem I am having, is that either
Reading AP_A:LT_VAR_SET_ENGLISH only returns Altitude Rounded to nearest 100 ft
or
Setting K:AP_ALT_VAR_SET_ENGLISH only sets the Altitude Rounded to nearest 100 ft

("Strange" rounding occurs about about xxx25 ft)

I tried keeping track of the Hold Altitude with my own ApAlt variable
I can obviously inc and dec that variable by any about , 100ft 20 ft 1 ft etc

case "KAP140_Knob_Inner_INC":
this.ApAlt = this.ApAlt + 1;
SimVar.SetSimVarValue("K:AP_ALT_VAR_SET_ENGLISH", "feet", this.ApAlt);
this.CurrAlt = (SimVar.GetSimVarValue("AUTOPILOT ALTITUDE LOCK VAR", "feet"));
var x = this.ShowStatus(this.ApAlt + "#" + this.CurrAlt);
break;

ApAlt is the variable I am keeping track of what I want the AP Alt to be set to

var x = this.ShowStatus(this.ApAlt + "#" + this.CurrAlt); is a routine to show Variables in the Gauge (Crude -- I need the better way !!)

So it is displaying the my wanted ApAlt, and the AP read CurrAlt HOLD ALT

As I INC up the value, ApAlt increments correct by (in this case) 1 ft
But CurrAlt jumps at about APAlt = xxx25 ft and can only be in 100's of feet resolution
.
ApAlt: 3518 3519 3520 3521 3522 3523 3524 3525 3526
CurrAlt: 3500 3500 3500 3500 3500 3500 3500 3600 3600

Same happens when I DEC

So how do I set the AP to have a Hold Altitude with 20 ft resolution


(Note: Yes, I am using the Knob, not the Buttons for this test -- In RL the knob only does 1000 & 100, while the Buttons do 20 (short press) and 500 (long Press) )

 

[WarpD]

Answered in your own post

 

[Geoff_D]

Answered in your own post

Thanks .....

 

[rcbarend]

So how do I set the AP to have a Hold Altitude with 20 ft resolution

You simply can't ; that is, by using the standard AP events and vars.
Reason: the core software appears to force/round AUTOPILOT ALTITUDE LOCK VAR to multiples of 100 ft .

The way it's rounded may be peculiar, but that's hard-coded too. (it's obviously not < or > xx50, as one might expect).
Also, the var isn't settable via SimConnect, so that's no option to.

Heck, I even tried to fool the sim (tried that in FSX) by editting a saved flight file (.flt) in which I editted e.g.
AltitudeValue=3000
to
AltitudeValue=2180
And immediately after loading that flight, the value of (A:AUTOPILOT ALTITUDE LOCK VAR,feet) is 2200.

This is in FS9, FSX and P3D.
And I would be highly supprised if this would work differently in MSFS (can't test that, since I don't have MSFS)

Rob

 

[taguilo]

So how do I set the AP to have a Hold Altitude with 20 ft resolution

Hi Geoff,

First let me say that UP & DN buttons, when operated in ALT mode, do not change the preselected altitude displayed. A single press will trigger a 20 ft up/down altitude change; a long press will trigger a 500 ft/min vs up/down and the altitude will remain the adquired at the moment the switch is released. This procedure is only for small altitude adjustments, not recommended for variations of more than 500 ft of the preselected reference (as per the real POH).

Now, it is possible to code this in XML (I've done that), but it's a bit tricky. Unfortunately I cannot post the routine I use but I can give you some hints:

-(A:AUTOPILOT ALTITUDE LOCK VAR, feet) value, which is the preselected altitude, remains unchanged.
-(A:AUTOPILOT ALTITUDE LOCK VAR, feet) control is not used, because of the 100 ft step limitations.
-Vertical Speed simple PID is applied to maintain the new altitude between parameters.


Tom

 

[rcbarend]

Now, it is possible to code this in XML (I've done that), but it's a bit tricky. Unfortunately I cannot post the routine I use but I can give you some hints:

Hi Tom,
Now you are making me very curious .....LoL

Cheers, Rob

 

[rcbarend]

Well that was helpful, as normal !!! - an you didn't even throw me a peanut.

I think he was referring to his answer in your newly created MSFS "thread" , instead of to your post in this thread.
Look at the timestamps ...

 

[Geoff_D]

Hi Geoff,

First let me say that UP & DN buttons, when operated in ALT mode, do not change the preselected altitude displayed. A single press will trigger a 20 ft up/down altitude change; a long press will trigger a 500 ft/min vs up/down and the altitude will remain the adquired at the moment the switch is released. This procedure is only for small altitude adjustments, not recommended for variations of more than 500 ft of the preselected reference (as per the real POH).

Now, it is possible to code this in XML (I've done that), but it's a bit tricky. Unfortunately I cannot post the routine I use but I can give you some hints:

-(A:AUTOPILOT ALTITUDE LOCK VAR, feet) value, which is the preselected altitude, remains unchanged.
-(A:AUTOPILOT ALTITUDE LOCK VAR, feet) control is not used, because of the 100 ft step limitations.
-Vertical Speed simple PID is applied to maintain the new altitude between parameters.


Tom

Ahhhh .. I did not fully comprehend that, by reading the RL KAP140 manual.

So the ALT display on the gauge should not change, this in effect just introduces a temporary "offset/Correction", I assume until such time that the Alt is adjusted again by the rotary controls, or re-initialized to the current altitude (to the nearest 100 ft)

The only indication you will get then is that your "reached" altitude could be offset by +/- 500 ft.

Does this Offset only become settable once the plane is within the +/- 200 ft of the demand altitude, and if the plane is outside that windows, the Buttons have no effect and the offset is zeroed ?

Back to the Drawing Board !!!!

 

[taguilo]

Now you are making me very curious .....LoL

I'm sorry I can't tell more, as the KAP 140 I designed is included in some commercial projects.

So the ALT display on the gauge should not change, this in effect just introduces a temporary "offset/Correction", I assume until such time that the Alt is adjusted again by the rotary controls, or re-initialized to the current altitude (to the nearest 100 ft)

Yes, it is kinda offset correction. Bear in mind the altitude preselect is an optional feature, but ALT up/down adjustment is available for all KAP configurations.

The only indication you will get then is that your "reached" altitude could be offset by +/- 500 ft.

Yes, but actually those 500 ft offset are the max recommended; you can indeed level the aircraft at whatever altitude resulted from the moment you release the up/down button.

Does this Offset only become settable once the plane is within the +/- 200 ft of the demand altitude, and if the plane is outside that windows, the Buttons have no effect and the offset is zeroed ?

No "altitude limit" when keeping the UP/DN button pressed.


Tom