ohh, it stays lit as long as I am at that position. that I can confirm

These LEDs:

Edited January 5, 20242 yr by Lorby_SI

7 minutes ago, Akila said:

ohh, it stays lit as long as I am at that position. that I can confirm

Then something must have been wrong with the assignment. The Key Up action with value 0 can only be on button 21, and on none of the others - OK? The others have only Key Down and nothing else. And 21 is the crucial one, that is the button that must stay lit, or the whole scheme won't work.

I will try to replicate this on my hardware somehow.

Edited January 5, 20242 yr by Lorby_SI

yes I followed your instruction and it seems the "release" is stronger then the "press" of the next button.

from B21 to B22 it goes back to RTO in the plane (which is the release/ even Up of B21), the rest are working fine.

 

 

 

 

Edited January 5, 20242 yr by Akila

OK, I think that I've successfully replicated the issue. I have assigned the selector positions to the switch on my Bravo same as you did = the lowest button has no assignment to simulate your missing button. The others I have assigned as described

Here is what I am seeing, please confirm if it was the same for you:

1. I can turn the selector full up and the selector in the cockpit follows
2. I can turn the selector full down and again the selector in the cockpit follows
3. I can go back up to the "OFF" position and it still follows
4. the problem starts, when I turn it to the right again, to "1": then the knob in the cockpit goes back into "RTO" instead of advancing to "1".

Apparently the Key Up event of the lower button overrides the Key Down of the higher one. That is obviously a bug that must be looked at.

My work around is to assign "Repeat Slow" to the "1" position (button 22 in your case). This will pull up the selector in the cockpit to the correct position. It looks weird with the selector first going down, but it works.

5 minutes ago, Akila said:

rom B21 to B22 it goes back to RO (which is the release/ even Up of B21), the plane the rest are working fine.

Confirmed, happens for me too. Activate "Repeat" "Slow" on Button 22. Not pretty but a viable work around.

The strange thing is, that the down/up messages are queued, exactly in the order they are coming in. They can't just trade places. That would mean that the interface is sending them in the wrong order in the first place.

Edited January 5, 20242 yr by Lorby_SI

yeah, it works that workaround . I picked repeat "fast" but also repeat "slow" works. with fast I noticed it switches back to b22 faster from RTO position.

Edited January 5, 20242 yr by Akila

By the way, thank you very much for all your help and instant respond. never experienced such instant support to that level of details.

Edited January 5, 20242 yr by Akila

I've looked at the AAO code and ran a quick test. The down/up events are coming in in the correct order, and they are processed in the correct order too. This is starting to look like an issue with the PMDG logic. Maybe it doesn't like it when things happen too quickly. Not sure what I can do about that.

10 minutes ago, Akila said:

yeah, it works that workaround . I picked repeat "fast" but also repeat "slow" works. with fast I noticed it switches back to b22 faster from RTO position.

I just chose "slow" to minimize unwanted/unnecessary events. But this is starting to look like it is actually the only option. I will try a script with a time-release for that button, slow down the value "2".

maybe if you can test an option of delayed release. like the other settings you have with long click and fast turn that could be configured with milliseconds.

or maybe delayed press. for B22? not sure. just a direction for your brilliant mind to think of.

Edited January 5, 20242 yr by Akila

15 minutes ago, Akila said:

maybe if you can test an option of delayed release. like the other settings you have with long click and fast turn that could be configured with milliseconds.

or maybe delayed press. for B22? not sure. just a direction for your brilliant mind to think of.

That's actually not the issue. I figured it out. The key up event on button 21 is fired both ways, right? Doesn't matter if you turn down to RTO or up to "1", the Key Up will always fire. So when turning up from OFF to "1" the PMDG logic is recieving position 0 and position 2 requests in quick succession. They have a queue of some kind working in there, and when the events happen too fast one after the other, one gets "swallowed"

I can work around this with scripts.

First script is for the Key Up on button 22. It will set an internal LVar:
1·(>L:rto_armed)

Second script is for the Key Up on button 21. It evaluates that LVar and resets it. So the code is only executing when you are coming from position "1" but not when you turn back up from RTO 
(L:rto_armed)·if{·0·(>L:rot_armed)·0·(>K:#70092)·}

This will make it work correctly. But there is a downside - if the knob is in the "OFF" position when you start AAO, it won't go down to RTO. You have to turn it up/down first.

Maybe the repeat is actually the better solution - I also noticed that when you turn the knob too fast, the plane will "overlook" some events, probably because of this issue. The Repeat would then make sure that the selector goes into the right position. Or thrustmaster could add another button below 21...

 

Edited January 5, 20242 yr by Lorby_SI

18 minutes ago, Akila said:

or maybe delayed press. for B22?

You could do that with a script too if you want to try that.

(SPLIT:200)·2·(>K:#70092)

The event happens at least 200ms after the fact.

Edited January 5, 20242 yr by Lorby_SI

1 hour ago, Lorby_SI said:

I also noticed that when you turn the knob too fast, the plane will "overlook" some events

Yes I have noticed that too, I thought it was my controls not managing to pass the command as it was to quick.

  

1 hour ago, Lorby_SI said:

You could do that with a script too if you want to try that.

(SPLIT:200)·2·(>K:#70092)

The event happens at least 200ms after the fact.

As for the script, I am not sure even how to write one and use a script. I just started fooling around with AAO few days ago, I am pertly new to it.
Even though I owned it since it was 1st released when it was still v1.x (beginning of September 2020), I never used it as I never really had a need for it as I did not have any controls apart from yoke and pedals. it was just sitting there at my Simmarket download basket. but now I kinda need this kind of a program as I have the TCA, so I started playing around with it in the past few days for the 1st time if you believe it or not. I managed to configure everting apart from that Autobrake that drove me nuts until I gave up on it and headed off to this support forum. 
Looking at the menus and options available in the tool, it seems very sophisticated capable program, I will need to spend good few hours or even days combing through the documentation to really start getting to know this program and I am not sure I can do it in timely matter. I just don't know how to use your code you posted in your replay and convert this to a script to load, well not yet at least

 

Edited January 6, 20242 yr by Akila

Does AAO have the ability to scan a joystick's current button state?  I manage this with a Lua script in a different program by reading the throttle quad button state and OR-ing buttons 21-25 bitwise and then sending the appropriate control based on the result.

btn 21 is bit 0, btn 22 is bit 1...btn 25 is bit 4.

You have six valid values:

0 (00000) = Disarm
1 (00001) = BTV
2 (00010) = Lo
4(00100) = 2
8(01000) = 3
16(10000) = Hi

I wait until I have four valid and matching results at 125ms intervals to ensure I don't catch the switch states in between knob positions while the knob is being rotated.  This also has the advantage of properly setting the control without need for an initial btn up or down event to sync the TCA's knob position with the sim panel control's state.