(possible) problem writing into free custom FSUIPC offsets

[shorthauler]

Dear all,

I am using an 8-position-rotary switch for the mode / range function for various aircraft (FSLabs A320, PMDG). All these aircraft on increase or decrease of the knob, not a specific position.

So I had to write a script that diagnoses in which direction the switch is being turned. This is what I did:

Every position (e.g. "2") triggers a specific Lua script. The script first writes into a free custom FSUIPC offset specific to this position. It then checks whether the offset of the position to the left ("1") has been set. If yes, it assumes the switch has been turned to the right. It then clears the offset of the previous position and sends a parameter to increase range or mode. If no, it assumes the switch has been turned to the left and decreases.

This works reasonably well, but if I turn the switch too much, I get jumps and mostly increases where there should be decreases. I am wondering why this is. Any ideas in this forum?

I also have optical rotary encoders that send an enormous amount of parameters per unit of time and there is no problem.

Software is Mobiflight, FSX, FSLABs A320, PMDG 744.

I did a test in Mobiflight where I directly sent keyboard inputs to notepad - no skipping or reversing there.

Best regards,
Holger

 

Script for the first position:

ipc.writeUB(0x66CA,2)                  -- setting the offset of the current position to 2

btnstate = ipc.readUB(0x66C9)    -- reading the offset of the position before (clockwise)
if btnstate == 2                             -- if the switch is turned in clockwise direction, the offset has been set to two at the previous detent
  then
   ipc.writeUB(0x66C9,1)              -- resetting the offset of the previous detent
   ipc.control(70158,16384)         -- command for increasing range
  else                                            -- if btnstate is not 2 it means the switch has been turned counter clockwise
   ipc.control(70158,8192)           -- command for decreasing range
end

Script for the second position:

ipc.writeUB(0x66CB,2)

btnstate = ipc.readUB(0x66CA)
if btnstate == 2
  then
   ipc.writeUB(0x66CA,1)
   ipc.control(70158,16384) -- command for increasing range
  else
   ipc.control(70158,8192) -- command for decreasing range
end

Etc.

[John Dowson]

First, you posted in the User Contributions sub-forum where it explicitly states NOT for support requests. I have moved your post to the main support forum.

I am having trouble understanding what you are trying to do and what your issue actually is...

Normally you would have one mode selector switch/rotary that has multiple positions (e.g. ALT, VS, HDG, etc) and another rotary used to increment and decrement the value determined by the mode selector switch. The second rotary would have either one or two (possibly virtual) buttons in each direction, and you would assign the appropriate inc/dec controls on these buttons and use compound button conditions on the position of the mode selector rotary.

29 minutes ago, shorthauler said:

All these aircraft on increase or decrease of the knob, not a specific position.

Not sure what this means....

31 minutes ago, shorthauler said:

Every position (e.g. "2") triggers a specific Lua script. The script first writes into a free custom FSUIPC offset specific to this position. It then checks whether the offset of the position to the left ("1") has been set. If yes, it assumes the switch has been turned to the right. It then clears the offset of the previous position and sends a parameter to increase range or mode. If no, it assumes the switch has been turned to the left and decreases.

Could you attach your FSUIPC .ini file so that I can see your assignments please, together with your lua scripts.

32 minutes ago, shorthauler said:

This works reasonably well, but if I turn the switch too much, I get jumps and mostly increases where there should be decreases. I am wondering why this is. Any ideas in this forum?

Does the rotary have two buttons (fast and slow) in each direction or just the one? 
You can try activating logging for Buttons & Keys as well as Events, and if you test with the logging console window open then you should be able to see what is being detected and what is being sent in real-time. You can also attach your FSUIPC log file here and I can take a look.

But I am a bit confused as to what you are trying to do and would like to see your ini file and lua scripts before anything else.

[shorthauler]

5 hours ago, John Dowson said:

Normally you would have one mode selector switch/rotary that has multiple positions (e.g. ALT, VS, HDG, etc) and another rotary used to increment and decrement the value determined by the mode selector switch.

Hi John, thank you for looking into this and apologies for posting in the wrong forum.

From the hardware side of things, both selectors are 8-position rotary switches. From the software side, both PMDG and FSLabs only have offsets / parameters to decrease or increase the position of the selector switch. There are no specific offsets / parameters for specific positions of the selector.

I am attaching my Lua scripts (for both PMDG and FSLabs) and the FSUIPC.ini. The Lua scripts are triggered by way of Mobiflight. There is no slow / fast option as Mobiflight looks at an 8-position-rotary-switch as an assembly of eight buttons, not as an encoder. An encoder for Mobiflight is a switch that has three pins (A, B and ground).

So I am trying to emulate a rotary encoder with a direction of turn by way of these scripts.

Best regards,

Holger

Holgers scripts.zip

[John Dowson]

14 hours ago, shorthauler said:

From the hardware side of things, both selectors are 8-position rotary switches.

And does the selector that you are using for inc/dec freely rotate? i.e. can you continually rotate it in one direction?
Rather than using an offset for each position of the selector, why don't you just use one offset that holds the number of the last position the selector held.
You can then read this in the lua script , compare that to the current position (which you can pass in as a parameter), and then decide what to do based upon the difference between these values. So, in the script, you would have the current position c (0-7), and read the previous position p (also 0-7) from an offset, and if
      (p == (c +1) mod 8 ) or (p ==(c+2) mod 8 ) or (p ==(c+3) mod 8 ) or  (p == (c +4) mod 8 ) then decrease
      else increase
then write the current position to the previous position offset, where the positions are 0..7 (for the 8 distinct positions)
Doing it this way, you would only need one lua script for each inc/dec function (rather than one per selector position), and it would still work if a position (or two) is jumped.

[shorthauler]

HI John, I think I get what you mean. I would also need to assign virtual buttons for each position, right? Yes, the switch rotates freely / indefinitely.

[John Dowson]

6 minutes ago, shorthauler said:

I would also need to assign virtual buttons for each position, right?

Why? Each position would just call the lua script with a parameter (0-7) indicating the button number (that called the script). No need for virtual buttons as far as I can tell...

[shorthauler]

I might have used the term "virtual buttons" incorrectly.

My hardware is connected to an Arduino Mega. As far as I know, there is no direct communication between FSUIPC and Arduino (or at least, it is very cumbersome), so the ways I know to trigger Lua scripts is either by buttons or by way of Mobiflight.

[John Dowson]

1 hour ago, shorthauler said:

My hardware is connected to an Arduino Mega. As far as I know, there is no direct communication between FSUIPC and Arduino (or at least, it is very cumbersome), so the ways I know to trigger Lua scripts is either by buttons or by way of Mobiflight.

However you trigger the lua, you just need to pass in the parameter of the selector button number (0 - 7) that triggers the lua and then read that using the ipcPARAM variable so that the script knows what the current position is - the c variable in my previous post.