Results 1 to 1 of 1
Thread: "Jumping" Encoders / Values
-
10-14-2016, 04:58 AM #1
- Join Date
- May 2014
- Location
- Germany
- Posts
- 4
"Jumping" Encoders / Values
Hi!
I recently started to create a complete set of SIOC scripts for the MCP, EFIS, Airbus Radio and XPDR for X-Plane. While working on my scripts I ran into the problem that the encodes (or rather the displays linked to the encoders) would frequently produce jumping values when quickly turning the encoder... Turning the HDG bug would yield something like 1, 2, 3, 2, 3, 4, 2, 5....
I’m not sure if this is an X-Plane only problem but my guess is that this might also be an issue for FSX/P3D. I've spent quite a bit of time experimenting on how to get encoders ‘just right’, so here is what I found out:
Implementation 1:
This was the first implementation and here the described problem occured. I had a variable linked to the simulator via IOCP that reads and writes the heading. Any changes to this variable will be directly sent to the display. The variable for the encoder directly reads and decrements/increments this variable.
Code:Var 001, name ioc_D_HDG, Link IOCARD_DISPLAY, Device 0, Digit 6, Numbers 3 Var 201, name ioc_E_HDG, Link IOCARD_ENCODER, Device 0, Input 6, Aceleration 6, Type 2 { L0 = &ioc_E_HDG * -10000 &sim_HDG = ROTATE 0 3600000 L0 } Var 301, name sim_HDG, Link IOCP, Offset 101 { &ioc_D_HDG = &sim_HDG / 10000 }
Implementation 2:
The most simple way is to avoid this is to create a variable that stores a local heading value. A script is attached to It to write the heading to the display every time the value is changed. The variable for the encoder reads and decrements/increments this local variable and also writes to the variable linked with the simulator via IOCP. This is apparently what all SIOC scripts for X-Plane published on the OC page do.
Code:Var 001, name ioc_D_HDG, Link IOCARD_DISPLAY, Device 0, Digit 6, Numbers 3 Var 101, name loc_HDG, value 0 { &ioc_D_HDG = &loc_HDG / 10000 } Var 201, name ioc_E_HDG, Link IOCARD_ENCODER, Device 0, Input 6, Aceleration 6, Type 2 { L0 = &ioc_E_HDG * -10000 &loc_HDG = ROTATE 0 3600000 L0 &sim_HDG = &loc_HDG } Var 301, name sim_HDG, Link IOCP, Offset 101
Implementation 3:
The most simple solution I have come up with is to combine both solutions. I use a local variable that my encoder is based on. In addition, I create another local variable where I save the value that I expect to read from the simulator. If this value is set, the code that reads the update from the simulator will discard any other values read until this value is read. If the expected value is read, this saved variable is reset so it is open for new reads. So any out of date reads caused by lag are discarded while the ability of the simulator to trigger independent changes is retained.
Code:Var 001, name ioc_D_HDG, Link IOCARD_DISPLAY, Device 0, Digit 6, Numbers 3 Var 401, name buf_HDG, value -999999 // expected HDG, -999999 = no value Var 101, name loc_HDG { &ioc_D_HDG = &loc_HDG / 10000 } Var 201, name ioc_E_HDG, Link IOCARD_ENCODER, Device 0, Input 6, Aceleration 6, Type 2 { L0 = &ioc_E_HDG * -10000 &loc_HDG = ROTATE 0 3600000 L0 &sim_HDG = &loc_HDG * 10000 // send to sim &buf_HDG = &loc_HDG * 10000 // save to block reading of different values } Var 301, name sim_HDG, Link IOCP, Offset 101 { if &buf_HDG <> -999999 // unacknowledged write operation to simulator in queue? { if &sim_HDG = &buf_HDG // ok, value acknowledged by simulator { &buf_HDG = -999999 } else // obsolete read, discard and reset expected value { &sim_HDG = &buf_HDG } } else // no write in queue, allow updates from the simulator { &loc_HDG = &sim_HDG } }
Best regards
Florian
Candid connections: Platform for casual relationships Live Women Prime Сasual Dating
Super Сasual Dating - Genuine...