AlMassimo Posted June 1 Report Posted June 1 Hello, I am trying to use the calculator code in myevents.txt in order to write the controls for pmdg 737. I created a simple myevents.txt under the FSUIPC directory. This is the content of the file : B737SPDDEC#38408 (>K:ROTOR_BRAKE) B737SPDINC#38407 (>K:ROTOR_BRAKE) B737HDGDEC#39008 (>K:ROTOR_BRAKE) B737HDGINC#39007 (>K:ROTOR_BRAKE) I have an (old!) opencockpits MCP V3, so I must use SIOC to control its functions. This is the part of the code that should activate the first 2 events // AP ENCODERS -------------------------------------------------------- var 0171, name E_SPD, Link IOCARD_ENCODER, Input 0, Aceleration 2, Type 2 { IF &E_SPD = 1 { &FS_PAR = 1 &FS_CONTROL = 4194304 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_SPD = -1 { &FS_PAR = 1 &FS_CONTROL = 4194305 &FS_CONTROL = DELAY 0 10 } } } But when I move the SPD encoder nothing happens. The same for the HDG encoder. I opened the .log file and I can find nothing about myevents.txt, and also the console doesn't show any activity when rotating the encoders (I activate logging of the events and I can see all other events). What am I doing wrong ? Did I miss something ? I hope that someone can help me. (BTW I solved the problem using LUA, but it seem to have a great lag so it's a pain to set the values rotating the encoders, maybe this also can be improved setting some params but I have no clue) Thanks for helping me Massimo
ark1320 Posted June 1 Report Posted June 1 4 hours ago, AlMassimo said: Hello, I am trying to use the calculator code in myevents.txt in order to write the controls for pmdg 737. I don't understand the above because I think the rotor K-event refers to a helicopter rotor, not some aspect of a B737. But I am not familiar with Open Cockpits equipment and maybe they have "repurposed" that K event somehow. Regardless, the FS2020 SDK says the below (and the FS2024 SDK says something similar). So maybe try (K:ROTOR_BRAKE_ON) in place of (K:ROTOR_BRAKE) if some type of rotor brake event is really what you need to use.
AlMassimo Posted June 2 Author Report Posted June 2 All controls for PMDG 737 are sent by a parameter associated to the K:ROTOR_BRAKE command, that was "free" since the 737 doesn't have a rotor. The problem is that I can't see any effect by adding the file myevents.txt, I suppose I should see something in fsuicp.log file, or in the console, but nothing happens. Probably I did something wrong. I'll try with other events, like parking brake or other common commands...
John Dowson Posted June 2 Report Posted June 2 14 hours ago, AlMassimo said: I created a simple myevents.txt under the FSUIPC directory. This is the content of the file : B737SPDDEC#38408 (>K:ROTOR_BRAKE) B737SPDINC#38407 (>K:ROTOR_BRAKE) B737HDGDEC#39008 (>K:ROTOR_BRAKE) B737HDGINC#39007 (>K:ROTOR_BRAKE) Why are you creating your own presets rather than using the one provided (by MobiFlight), e.g.: PMDG_B737_MCP_HDG_DEC#39008 (>K:ROTOR_BRAKE) PMDG_B737_MCP_HDG_INC#39007 (>K:ROTOR_BRAKE) PMDG_B737_MCP_IAS_MACH_DEC#38408 (>K:ROTOR_BRAKE) PMDG_B737_MCP_IAS_MACH_INC#38407 (>K:ROTOR_BRAKE) 14 hours ago, AlMassimo said: This is the part of the code that should activate the first 2 events // AP ENCODERS -------------------------------------------------------- var 0171, name E_SPD, Link IOCARD_ENCODER, Input 0, Aceleration 2, Type 2 { IF &E_SPD = 1 { &FS_PAR = 1 &FS_CONTROL = 4194304 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_SPD = -1 { &FS_PAR = 1 &FS_CONTROL = 4194305 &FS_CONTROL = DELAY 0 10 } } } I am not sure what that code is (is it from SIOB?), but it looks like that will be (eventually) using offset 0x3110 to send the preset control using a control number. Control numbers for presets are difficult to calculate and you shouldn't use them really. To send a preset via an offset, use the preset name and offset 0x7C50. Otherwise, check that you are using the correct control number. You can use FSUIPC's logging facilities to see what is being sent. Do you have the events.txt file installed? If so, control numbers 4194304 and 4194305 will trigger the 1st and 2nd preset in the events.txt file (not in the myevents.txt file). You should use the preset name via offset 0x7C50, not the control numbers which can change, 11 hours ago, ark1320 said: I don't understand the above because I think the rotor K-event refers to a helicopter rotor, not some aspect of a B737. But I am not familiar with Open Cockpits equipment and maybe they have "repurposed" that K event somehow. It is the aircraft developers (PMDG in this case) that have re-purposed the Rotor Brake event to implement custom controls. This is done by several aircraft developers that re-use the Rotor Brake control. 11 hours ago, ark1320 said: Regardless, the FS2020 SDK says the below (and the FS2024 SDK says something similar). So maybe try (K:ROTOR_BRAKE_ON) in place of (K:ROTOR_BRAKE) if some type of rotor brake event is really what you need to use. It is deprecated but can still be used - and must be used for the custom controls to work, not K:ROTOR_BRAKE_ON . This FAQ entry shows how to to use the PMDG custom controls via the Rotor Brake control: 21 minutes ago, AlMassimo said: The problem is that I can't see any effect by adding the file myevents.txt, I suppose I should see something in fsuicp.log file, or in the console, but nothing happens. Probably I did something wrong. I'll try with other events, like parking brake or other common commands... Yes - use logging to see what is being sent. If using presets, set Debug level logging in the WAPI to see the calculator code/preset being used. John
John Dowson Posted June 2 Report Posted June 2 Rather than using presets, you can just use the Rotor Brake control directly, e.g. var 0171, name E_SPD, Link IOCARD_ENCODER, Input 0, Aceleration 2, Type 2 { IF &E_SPD = 1 { &FS_PAR = 38407 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_SPD = -1 { &FS_PAR = 38408 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } } } i.e. use control number 66587, for the Rotor Brake control, with the parameter (38407, 38408, etc) indicating the actual custom control to be used. John
AlMassimo Posted June 2 Author Report Posted June 2 6 hours ago, John Dowson said: Rather than using presets, you can just use the Rotor Brake control directly, e.g. var 0171, name E_SPD, Link IOCARD_ENCODER, Input 0, Aceleration 2, Type 2 { IF &E_SPD = 1 { &FS_PAR = 38407 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_SPD = -1 { &FS_PAR = 38408 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } } } i.e. use control number 66587, for the Rotor Brake control, with the parameter (38407, 38408, etc) indicating the actual custom control to be used. John Thanks John, I started using the code you suggested, but for some reason every time I act on a different encoder, the last command is sent, and only after that the new encoder sends the new command. So eg. if I have set the altitude to 10000 ft and then try to set the speed from 190 to 200, when I rotate the speed the first impulse still changes the altitude (eg to 10100), and only after I can modify the speed, as if the old par was still in memory and not substituted by the new parameter. The same happens when I change dir of rotation, after some increases the first counterclockwise tick still increases the value, and only the second starts decreasing. This is pretty annoying. With lua this doesn't happen, but as I said it has a lag much too big for an encoder (it's Ok for switches and buttons) so I tried other ways. What I cannot understand is why fsuipc is ignoring the content of myevents.txt (is it Ok to place it under the same directory of fsuipc?) apparently it could solve the issues since probably the replicated old command is a bug of SIOC as far as I can say.
John Dowson Posted June 2 Report Posted June 2 53 minutes ago, AlMassimo said: I started using the code you suggested, but for some reason every time I act on a different encoder, the last command is sent, and only after that the new encoder sends the new command. So eg. if I have set the altitude to 10000 ft and then try to set the speed from 190 to 200, when I rotate the speed the first impulse still changes the altitude (eg to 10100), and only after I can modify the speed, as if the old par was still in memory and not substituted by the new parameter. The same happens when I change dir of rotation, after some increases the first counterclockwise tick still increases the value, and only the second starts decreasing. This is pretty annoying. Sorry, but I can't help if assigning in SIOC - I have never used and know very little about this. But you should be able to use FSUIPC's logging facilities to work out what is happening. 53 minutes ago, AlMassimo said: What I cannot understand is why fsuipc is ignoring the content of myevents.txt Why do you think it is doing this? What does your log file show? You should see a line indicating the number of presets loaded, e.g. Quote 2859 19048 Calculator Code presets have been loaded and are available for use Can you show me / attach your FSUI{C7.log file. There can be many reasons why a preset is not working, you need to narrow it down why (is the preset actually being sent on the button press/release? Is it being received in the WASM? Is the WASM even installed? etc). 57 minutes ago, AlMassimo said: is it Ok to place it under the same directory of fsuipc? Yes - that is the only location where this file is read from. 59 minutes ago, AlMassimo said: it could solve the issues since probably the replicated old command is a bug of SIOC as far as I can say. Not sure what this means, but using the presets/calculator code is exactly the same as using the Rotor Brake control directly, and if you are having issues with those then you will have the same issues when using the presets.
AlMassimo Posted June 4 Author Report Posted June 4 Hi John, thanks a lot for your patience. Here you find myevents.txt and log file, I can see no trace of my presets in the log... I used myoffsets in the past and they worked fine, surely I'm doing something wrong. Massimo FSUIPC7.log FSUIPC7.ini myevents.txt
John Dowson Posted June 4 Report Posted June 4 3 hours ago, AlMassimo said: Here you find myevents.txt and log file, I can see no trace of my presets in the log... Your log file shows that you are using the events.txt file, as you have 18994 presets loaded: Quote 704 7248 18994 Calculator Code presets have been loaded and are available for use The control numbers for the presets in your myevents.txt file will certainly not start at 4194304 (which will be the number for the first preset in the events.txt file). If you want to use control numbers for the presets in the myevents.txt file, you should not use (i.e. delete and do nor install when you re-install). However, it is far better to use the preset name to send a preset, as I suggested, or just use the Rotor Brake control (with the appropriate parameter). You cannot see the presets being logged as you have disabled logging in the WAPI. To see the preset/calc code being sent, you need to set Debug level logging in the WAPI. 3 hours ago, AlMassimo said: I used myoffsets in the past and they worked fine, surely I'm doing something wrong. The myOffsets.tct and myevents.txt are completely different.
AlMassimo Posted June 4 Author Report Posted June 4 Hi John, thankyou, I suspected that I had to remove events.txt but I thought that myevents were always found starting from the address 4194304, but I was wrong. I knew that using events.txt I had to follow your instruction to reach the address of a specific event, and seemed too complicated and variable updating events list. I will also try the string offset 0x7C50 procedure, but I must check how to do that in SIOC, probably is simple but at the moment I have never tried that. I see events list in fsuipc.log even if I haven't se debug in WAPI, but I cannot see myevents ? Odd to me, but that's no problem. So probably it will be all ok after I remove events.txt. Sorry I wrote myoffsets instead of myevents, but I meant myevents. I also use myoffsets to import specific A vars that seems not have an offset assigned. I use lvars inside fsuipc.ini, your software has so many powerful features! I'm sorry I cannot use it directly, since I have to deal with SIOC programming... but fsuipc allows to keep on using this outdated software even with most of the new features of MSFS 2020 and 2024, included the extremely powerful calculator code. I just wonder if it's possible to speed up lua, because it seems strange to have this lag, seems like if it updates 1-2 times per second, is this correct ? Thanks for your invaluable support,
John Dowson Posted June 4 Report Posted June 4 15 minutes ago, AlMassimo said: I suspected that I had to remove events.txt but I thought that myevents were always found starting from the address 4194304, but I was wrong. Yes - I should really load the myevents.txt file first and start the numbering from there. But, as I say, using the numbers is not recommended as these can change. 16 minutes ago, AlMassimo said: I see events list in fsuipc.log even if I haven't se debug in WAPI, but I cannot see myevents ? The presets you saw in the log are the ones NOT loaded (and hence not available) due to some sort of errors. Loaded presets are NOT logged anywhere (there are usually far too many for this!). If you set WAPI Debug level logging (Log->WAPI->Debug), this will log the calculator code from a preset when it is sent the the WASM to be applied to the aircraft. 19 minutes ago, AlMassimo said: I just wonder if it's possible to speed up lua, because it seems strange to have this lag, seems like if it updates 1-2 times per second, is this correct ? Lua does seem to run rather slower in MSFS 2020/2024 than in other flight simulators (there are already several support topics on this), but it should not be that slow. They are a lot faster if they are already running and re-act to events, rather than being started on a button/key press (as they need to be compiled each time before being ran if/when assigned to run on a button or key press). Lua scripts may also run faster when FSUIPC is manually started, rather than being auto-started by the FS (although YMMV). Sorry but I can't really help much if using SIOC as I have never used this. Does FSUIPC not see your buttons? If so, you can try assigning directly in FSUIPC rather than assigning in SIOC.
AlMassimo Posted June 4 Author Report Posted June 4 Hello, all clear now, thanks. As soon as possible I'll test if removing events.txt all works fine. As for lua, I configured ipcready to launch B737,lua so it should be running all the time and not be called by the specific command. My workflow is this : - I change a button or encoder position on my OC MCP or radio panel - in SIOC I detect the change of the input and I set to 1 or 0 a custom offset (or to -1 or 1 for encoders) eg A001 - in LUA I monitor the offset A001 and when changed lua calls the function "ENC_HDG" - the function ENC_HDG checks if A001 is -1 and execute a line of calculator code, or if it's 1 and then execute another line of calculator code - another function in lua checks the value of the MSFS autopilot heading value (via offset, or LVAR or whatever) and writes the value to a custom offset eg "A020" - the offset is read by SIOC and sent to the hdg display All works fine (and could solve all the problems) but when I rotate the encoder fast to change hdg eg from 100 to 270 it takes a lot of time, since hdg value changes very slowly and many ticks are missed. If I do the same calling directly the command (ROTOR_BRAKE) using the 0x3110 control offset all works very fast but as I said changing parameter (moving another encoder) the first action still changes the previous control... I hope that calling an event instead of sending a control could solve this issue (but I'm not sure it is different after all, probably the previous event will be called as well). If lua were faster I would solve completely all problems. I will try to see if starting fsuipc manually changes something. Is it ok to shutdown fsuipc and then restart it manually without modifying the "auto-start with MSFS" feature ? Last thing : I cannot detect the hardware buttons or encoders out of SIOC, afaik there is no way to see the controls in OpenCockpits modules neither in Mobiflight not in Fsuipc, this is a pity but as I said the OC panels are pretty old now (10 years maybe...)!
John Dowson Posted June 4 Report Posted June 4 3 minutes ago, AlMassimo said: As for lua, I configured ipcready to launch B737,lua so it should be running all the time and not be called by the specific command. My workflow is this : - I change a button or encoder position on my OC MCP or radio panel - in SIOC I detect the change of the input and I set to 1 or 0 a custom offset (or to -1 or 1 for encoders) eg A001 - in LUA I monitor the offset A001 and when changed lua calls the function "ENC_HDG" - the function ENC_HDG checks if A001 is -1 and execute a line of calculator code, or if it's 1 and then execute another line of calculator code - another function in lua checks the value of the MSFS autopilot heading value (via offset, or LVAR or whatever) and writes the value to a custom offset eg "A020" - the offset is read by SIOC and sent to the hdg display Ok, but I find this rather confusing as you previously posted some code (presumably from SIOC) that was trying to use the custom control numbers for presets. If you are using lua, why not just send these commands (either via presets or the Rotor Brake control) from the lua script? You can also add logging statements (using ipc.log) to check/test the performance, although I would not actually set Lua Plugins logging as this can slow things down even further. You can also use offset monitoring to see when offset A001 changes and get the timestamp of that, which could help see where the delay is coming from. 10 minutes ago, AlMassimo said: I hope that calling an event instead of sending a control could solve this issue (but I'm not sure it is different after all, probably the previous event will be called as well). Events and controls re the same thing... I think you mean preset (or calculator code), which will translate to the same event anyway - it will just go via the gauge execute_calculator_code function rather than via SimConnect. 12 minutes ago, AlMassimo said: Is it ok to shutdown fsuipc and then restart it manually without modifying the "auto-start with MSFS" feature ? Yes. You can try that to see if the performance improves. You can also try moving the lua execution thread off of core 0/1 by setting an affinity mask - this may improve performance if the first cores re highly loaded. You can do this using the ini parameter LuaAffinityMask - see 18 minutes ago, AlMassimo said: Last thing : I cannot detect the hardware buttons or encoders out of SIOC, afaik there is no way to see the controls in OpenCockpits modules neither in Mobiflight not in Fsuipc, this is a pity but as I said the OC panels are pretty old now (10 years maybe...)! Ok.
AlMassimo Posted June 4 Author Report Posted June 4 1 hour ago, John Dowson said: You can also try moving the lua execution thread off of core 0/1 by setting an affinity mask - this may improve performance if the first cores re highly loaded. You can do this using the ini parameter LuaAffinityMask - see Interesting! That could be, since probably core 0/1 are most stressed by MSFS 2024. I remember a parameter on lua that sets the maximum frequency of updates (can't remember where) and it was aboyut 10 times per second, should be enough to follow an encoder even if I rotate it pretty fast... Sorry if I'm creating some confusion, because as I said I tested many different solutions. The SIOC code is the bridge between OC modules and Fsuipc --> MSFS so I use it in 3 ways : 1 - change an offset and let LUA do what is needed (working perfectly but slow for encoders and displays) I use this for altitude that has lower delta (I can use 1000 ft steps) 2 - call a control by setting a parameter and then activating offset 0x3110 with the command 66587 (K:ROTOR_BRAKE) : works but replies the last command I think it's critical this line : &FS_CONTROL = DELAY 0 10 that means send param 0 to FS_CONTROL (0x3110) after 10 milliseconds (I think) in order to free it for the next command; apparently this could be the issue. Perhaps the time is not enough or doesn't work properly. In LUA isn't needed any delay. 3 - call a custom event that activates the ROTOR_BRAKE command with the needed parameter (to be tested after deleting events.txt hoping to find proper addresses) (4) - set the 0x7C50 with a string containing the name of the preset (still to be tested) currently I am testing a mix of these methods, so I'm sorry this can be confusing!
John Dowson Posted June 4 Report Posted June 4 37 minutes ago, AlMassimo said: Interesting! That could be, since probably core 0/1 are most stressed by MSFS 2024. Yes, but this can depend heavily on the system and configuration. 38 minutes ago, AlMassimo said: I remember a parameter on lua that sets the maximum frequency of updates (can't remember where) and it was aboyut 10 times per second, should be enough to follow an encoder even if I rotate it pretty fast... There are various polling parameters that can be tuned, but you need to determine where the bottle-neck is first. And over-tuning can make things worse. But you probably won't get more than 5 or 6 clicks/button presses a second on rotaries when using lua (in MSFS2020/2024), Also, be aware that many rotaries have two buttons in each direction, one activated on a fast turn and another on a slow turn. There is also a lua script that can convert rotaries with a single button in each direction to work with 2 virtual buttons in each direction instead (see Rotaries.lua in the example lua scripts). What you would normally do is assign the fast rotary button to a large delta, and the slow button to a small delta, so the increments/decrements on a fast turn are a lot larger than a slow turn. 51 minutes ago, AlMassimo said: 2 - call a control by setting a parameter and then activating offset 0x3110 with the command 66587 (K:ROTOR_BRAKE) : works but replies the last command I think it's critical this line : &FS_CONTROL = DELAY 0 10 that means send param 0 to FS_CONTROL (0x3110) after 10 milliseconds (I think) in order to free it for the next command; apparently this could be the issue. Perhaps the time is not enough or doesn't work properly. In LUA isn't needed any delay. You shouldn't need to do this (i.e. set the parameter to 0 first). And it is writing the control number that triggers the event being sent, so this should be written AFTER the parameter has been written. So, what is probably happening is that the previous parameter is being sent when you write the control number. Try writing the parameter first before the control number, and no need to reset to 0 or add a delay. But I think there is an issue with offset 0x3110 in that the control is not triggered if the value is not changed, so maybe this was added to get around this? With direct assignments to rotary buttons, I get a 15-35ms delay between each recognised button press. However, it will be a lot slower in lua. In the next few days I can write a short lua script that waits on an offset change, and assign the rotary buttons to set the offset, and I will se what speeds I can get. Note also that some rotaries alternate between emitting button presses and button releases. For such rotaries, you can assign to both the press and release to double the throughput. John
AlMassimo Posted June 5 Author Report Posted June 5 Hi John, as usual you go beyond any expectation in getting deeper and deeper into an issue, and you find solutions that I couldn't even imagine... I'm so grateful to you for this excellent support you grant to the users of your beautiful software! I can't understand why this issue with old control called by a new one seems to appear only with B737 "rotor_brake" command. Normally I send different controls for different encoders, so this problem doesn't appear. In this case I send a different parameter to the SAME control. EG for increasing or decreasing AP HDG normally you have 2 different control codes, not 2 parameters for the same control... Maybe I could send a fictional (unused) control after each real control, so the next will change the unused variable and not the one changed before the new encoder is triggered. The fast option in lua sounds very interesting. If I could change the HDG by 5 or 10 instead of 1 it should be OK after to have a slower 1 step for fine tuning. It would be fantastic if you could do some experiment!
John Dowson Posted June 5 Report Posted June 5 (edited) I have made a few tests here. Some observations: 1. my rotary buttons alternate between presses and releases, so I assign the same control to both the press and release 2. only offset changes will cause an event to be triggered, i.e. if you are writing the same value, no event gets triggered. Observation 2 is the killer here, and it means that you have to reset the value in the offset to pick up further changes. However, this is best done in the function that handles the offset event. This is the lua I am using for this test: Quote function offsetUpdated(offset, value) -- First, reset the value in the offset (so subsequent changes will call an event) -- Note this should be a number that is not used/written to trigger an action ipc.writeUB(offset, 0) if value ~= 0 then ipc.log("**** Offset changed: " .. value .. " ****") else ipc.log("**** Offset reset: 0 value received ****") end end event.offset(0xA030, "UB", "offsetUpdated") ipc.log("**** eventSpeedTest lua running on offset 0xA030 ****") And I assign my rotary buttons as follows: - clockwise slow, assigned to Offset Byte Set (on 0xA030) with value 1 - clockwise fast, assigned to Offset Byte Set (on 0xA030) with value 2 - anti-clockwise slow, assigned to Offset Byte Set (on 0xA030) with value 3 - anti-clockwise fast, assigned to Offset Byte Set (on 0xA030) with value 4 With these assignments, I can get up to 7 or 8 slow button changes per second: Quote 699890 Button changed: bRef=0, Joy=174, Btn=14, Pressed 699890 [Buttons] 84=P174,14,Cx0100A030,x01 699890 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 699890 Monitor IPC:A030 (U8) = 1 699922 LUA.4: **** Offset changed: 1 **** 699922 Monitor IPC:A030 (U8) = 0 699968 LUA.4: **** Offset reset: 0 value received **** 700000 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 700000 Button changed: bRef=0, Joy=174, Btn=14, Released 700000 [Buttons] 89=U174,14,Cx0100A030,x01 700000 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700031 Monitor IPC:A030 (U8) = 1 700062 LUA.4: **** Offset changed: 1 **** 700062 Monitor IPC:A030 (U8) = 0 700109 LUA.4: **** Offset reset: 0 value received **** 700140 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 0004c000} 700140 Button changed: bRef=0, Joy=174, Btn=14, Pressed 700140 [Buttons] 84=P174,14,Cx0100A030,x01 700140 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700172 Monitor IPC:A030 (U8) = 1 700203 LUA.4: **** Offset changed: 1 **** 700203 Monitor IPC:A030 (U8) = 0 700250 LUA.4: **** Offset reset: 0 value received **** 700281 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 700281 Button changed: bRef=0, Joy=174, Btn=14, Released 700281 [Buttons] 89=U174,14,Cx0100A030,x01 700281 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700297 Monitor IPC:A030 (U8) = 1 700312 LUA.4: **** Offset changed: 1 **** 700328 Monitor IPC:A030 (U8) = 0 700359 LUA.4: **** Offset reset: 0 value received **** 700406 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 0004c000} 700406 Button changed: bRef=0, Joy=174, Btn=14, Pressed 700406 [Buttons] 84=P174,14,Cx0100A030,x01 700406 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700422 Monitor IPC:A030 (U8) = 1 700453 LUA.4: **** Offset changed: 1 **** 700468 Monitor IPC:A030 (U8) = 0 700500 LUA.4: **** Offset reset: 0 value received **** 700547 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 700547 Button changed: bRef=0, Joy=174, Btn=14, Released 700547 [Buttons] 89=U174,14,Cx0100A030,x01 700547 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700578 Monitor IPC:A030 (U8) = 1 700609 LUA.4: **** Offset changed: 1 **** 700609 Monitor IPC:A030 (U8) = 0 700656 LUA.4: **** Offset reset: 0 value received **** 700672 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 0004c000} 700672 Button changed: bRef=0, Joy=174, Btn=14, Pressed 700672 [Buttons] 84=P174,14,Cx0100A030,x01 700672 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700687 Monitor IPC:A030 (U8) = 1 700718 LUA.4: **** Offset changed: 1 **** 700734 Monitor IPC:A030 (U8) = 0 700765 LUA.4: **** Offset reset: 0 value received **** 700828 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 700828 Button changed: bRef=0, Joy=174, Btn=14, Released 700843 [Buttons] 89=U174,14,Cx0100A030,x01 700843 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 700843 Monitor IPC:A030 (U8) = 1 700875 LUA.4: **** Offset changed: 1 **** 700890 Monitor IPC:A030 (U8) = 0 700922 LUA.4: **** Offset reset: 0 value received **** However, when turning the dial two fast, the events aren't triggered: Quote 926359 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926359 Button changed: bRef=0, Joy=174, Btn=14, Released 926359 [Buttons] 89=U174,14,Cx0100A030,x01 926359 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 926390 Monitor IPC:A030 (U8) = 1 926390 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926390 Button changed: bRef=0, Joy=174, Btn=15, Released 926390 [Buttons] 90=U174,15,Cx0100A030,x02 926390 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926422 LUA.4: **** Offset changed: 2 **** 926422 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926422 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926422 [Buttons] 87=P174,15,Cx0100A030,x02 926422 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926422 Monitor IPC:A030 (U8) = 2 926453 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926453 Button changed: bRef=0, Joy=174, Btn=15, Released 926453 [Buttons] 90=U174,15,Cx0100A030,x02 926453 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926468 Monitor IPC:A030 (U8) = 0 926468 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926468 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926468 [Buttons] 87=P174,15,Cx0100A030,x02 926468 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926468 LUA.4: **** Offset changed: 2 **** 926468 Monitor IPC:A030 (U8) = 2 926484 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926484 Button changed: bRef=0, Joy=174, Btn=15, Released 926484 [Buttons] 90=U174,15,Cx0100A030,x02 926484 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926500 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926500 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926500 [Buttons] 87=P174,15,Cx0100A030,x02 926500 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926515 LUA.4: **** Offset changed: 2 **** 926515 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926531 Button changed: bRef=0, Joy=174, Btn=15, Released 926531 [Buttons] 90=U174,15,Cx0100A030,x02 926531 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926547 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926547 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926547 [Buttons] 87=P174,15,Cx0100A030,x02 926547 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926562 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926562 Button changed: bRef=0, Joy=174, Btn=15, Released 926578 [Buttons] 90=U174,15,Cx0100A030,x02 926578 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926609 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926609 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926609 [Buttons] 87=P174,15,Cx0100A030,x02 926609 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926656 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926656 Button changed: bRef=0, Joy=174, Btn=15, Released 926656 [Buttons] 90=U174,15,Cx0100A030,x02 926656 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926734 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 926734 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926734 [Buttons] 87=P174,15,Cx0100A030,x02 926734 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926781 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00040000} 926781 Button changed: bRef=0, Joy=174, Btn=15, Released 926781 [Buttons] 90=U174,15,Cx0100A030,x02 926781 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926875 Button changed: bRef=0, Joy=174, Btn=15, Pressed 926875 [Buttons] 87=P174,15,Cx0100A030,x02 926875 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x2 926875 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} What seems to be happening is that although the offset is being reset back to 0, it is getting updated back to the fast value again (2) too fast to trigger the event. This makes the fast rotary buttons almost impossible to use consistantly. But if I switch to using flags to trigger the change, using the following lua: Quote function flagChanged(flag) ipc.log("**** flag changed: " .. flag .. " ****") end event.flag("flagChanged") ipc.log("**** eventSpeedTest lua running on flags ****") and assign my rotary buttons to: - clockwise slow, assigned to LuaToggle <luaFileName> with parameter of 1 - clockwise fast, assigned to LuaToggle <luaFileName> with parameter of 2 - anti-clockwise slow, assigned to LuaToggle <luaFileName> with parameter of 3 - anti-clockwise fast, assigned to LuaToggle <luaFileName> with parameter of 4 then I get a lot better throughput with both the slow and fast buttons - here you can see 23 change events logged in under a second: Quote 1685265 Button changed: bRef=0, Joy=174, Btn=18, Pressed 1685265 [Buttons] 92=P174,18,CL81:T,1 1685265 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685281 LUA.4: **** flag changed: 1 **** 1685281 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685281 Button changed: bRef=0, Joy=174, Btn=19, Released 1685281 [Buttons] 94=U174,19,CL81:T,2 1685297 LUA.4: **** flag changed: 2 **** 1685297 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685297 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685297 [Buttons] 93=P174,19,CL81:T,2 1685312 LUA.4: **** flag changed: 2 **** 1685312 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685312 Button changed: bRef=0, Joy=174, Btn=19, Released 1685312 [Buttons] 94=U174,19,CL81:T,2 1685328 LUA.4: **** flag changed: 2 **** 1685328 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685328 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685328 [Buttons] 93=P174,19,CL81:T,2 1685343 LUA.4: **** flag changed: 2 **** 1685343 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685359 Button changed: bRef=0, Joy=174, Btn=19, Released 1685359 [Buttons] 94=U174,19,CL81:T,2 1685359 LUA.4: **** flag changed: 2 **** 1685375 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685375 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685375 [Buttons] 93=P174,19,CL81:T,2 1685390 LUA.4: **** flag changed: 2 **** 1685390 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685390 Button changed: bRef=0, Joy=174, Btn=19, Released 1685390 [Buttons] 94=U174,19,CL81:T,2 1685406 LUA.4: **** flag changed: 2 **** 1685406 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685406 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685406 [Buttons] 93=P174,19,CL81:T,2 1685422 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685422 Button changed: bRef=0, Joy=174, Btn=19, Released 1685422 [Buttons] 94=U174,19,CL81:T,2 1685422 LUA.4: **** flag changed: 2 **** 1685437 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685437 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685437 [Buttons] 93=P174,19,CL81:T,2 1685437 LUA.4: **** flag changed: 2 **** 1685437 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685437 Button changed: bRef=0, Joy=174, Btn=19, Released 1685437 [Buttons] 94=U174,19,CL81:T,2 1685453 LUA.4: **** flag changed: 2 **** 1685453 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685453 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685453 [Buttons] 93=P174,19,CL81:T,2 1685468 Button changed: bRef=0, Joy=174, Btn=19, Released 1685468 [Buttons] 94=U174,19,CL81:T,2 1685468 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685468 LUA.4: **** flag changed: 2 **** 1685484 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685484 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685484 [Buttons] 93=P174,19,CL81:T,2 1685484 LUA.4: **** flag changed: 2 **** 1685484 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685484 Button changed: bRef=0, Joy=174, Btn=19, Released 1685484 [Buttons] 94=U174,19,CL81:T,2 1685500 LUA.4: **** flag changed: 2 **** 1685500 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685500 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685500 [Buttons] 93=P174,19,CL81:T,2 1685515 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685515 Button changed: bRef=0, Joy=174, Btn=19, Released 1685515 [Buttons] 94=U174,19,CL81:T,2 1685515 LUA.4: **** flag changed: 2 **** 1685531 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685531 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685531 [Buttons] 93=P174,19,CL81:T,2 1685531 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685531 Button changed: bRef=0, Joy=174, Btn=19, Released 1685531 [Buttons] 94=U174,19,CL81:T,2 1685547 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685547 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685547 [Buttons] 93=P174,19,CL81:T,2 1685547 LUA.4: **** flag changed: 2 **** 1685562 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685562 Button changed: bRef=0, Joy=174, Btn=19, Released 1685562 LUA.4: **** flag changed: 2 **** 1685562 [Buttons] 94=U174,19,CL81:T,2 1685578 LUA.4: **** flag changed: 2 **** 1685578 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685578 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685578 [Buttons] 93=P174,19,CL81:T,2 1685593 LUA.4: **** flag changed: 2 **** 1685625 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685625 Button changed: bRef=0, Joy=174, Btn=19, Released 1685625 [Buttons] 94=U174,19,CL81:T,2 1685640 LUA.4: **** flag changed: 2 **** 1685656 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685656 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685672 [Buttons] 93=P174,19,CL81:T,2 1685672 LUA.4: **** flag changed: 2 **** 1685687 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685687 Button changed: bRef=0, Joy=174, Btn=19, Released 1685687 [Buttons] 94=U174,19,CL81:T,2 1685703 LUA.4: **** flag changed: 2 **** 1685718 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 000c8000} 1685718 Button changed: bRef=0, Joy=174, Btn=19, Pressed 1685718 [Buttons] 93=P174,19,CL81:T,2 1685734 LUA.4: **** flag changed: 2 **** 1685781 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00048000} 1685781 Button changed: bRef=0, Joy=174, Btn=19, Released 1685781 [Buttons] 94=U174,19,CL81:T,2 1685797 LUA.4: **** flag changed: 2 **** So maybe try switching to assign your buttons to a lua flag toggle (in SIOC, if this is possible...), and use event.flag in your lua scripts to pick up the button press (there are 255 flags available per script). On 6/5/2025 at 12:16 PM, AlMassimo said: I can't understand why this issue with old control called by a new one seems to appear only with B737 "rotor_brake" command. Normally I send different controls for different encoders, so this problem doesn't appear. In this case I send a different parameter to the SAME control. EG for increasing or decreasing AP HDG normally you have 2 different control codes, not 2 parameters for the same control... Maybe I could send a fictional (unused) control after each real control, so the next will change the unused variable and not the one changed before the new encoder is triggered. Yes, this is a problem when using offset 0x3110, as only changes to the value in the offset trigger the event, so if you are writing the same control (i.e. Rotor Brake control number 66587) then only the first one will be sent and the subsequent ones ignored as there is no change in value in 0x3110. I will look into this in more detail when I have time, but can you try the attached version where I have reset the (internal) contents of 0x3110 once the event has been sent. Hopefully this will work but I don't have time to test this at the moment. Let me know if this works better when sending the same control.. John Edited Monday at 02:28 PM by John Dowson attachment removed as changes not necessary and build not working
John Dowson Posted June 5 Report Posted June 5 5 minutes ago, John Dowson said: 1. my rotary buttons alternate between presses and releases, so I assign the same control to both the press and release I don't get that many fast updates as I was using the same parameter for both the press and release. As these alternate, it makes more sense to use different values, so the offset is actually changing on each click. So if I change: 7 minutes ago, John Dowson said: And I assign my rotary buttons as follows: - clockwise slow, assigned to Offset Byte Set (on 0xA030) with value 1 - clockwise fast, assigned to Offset Byte Set (on 0xA030) with value 2 - anti-clockwise slow, assigned to Offset Byte Set (on 0xA030) with value 3 - anti-clockwise fast, assigned to Offset Byte Set (on 0xA030) with value 4 to - clockwise slow press, assigned to Offset Byte Set (on 0xA030) with value 1 - clockwise slow release, assigned to Offset Byte Set (on 0xA030) with value 2 - clockwise fast press, assigned to Offset Byte Set (on 0xA030) with value 3 - clockwise fast release, assigned to Offset Byte Set (on 0xA030) with value 4 - anti-clockwise slow press, assigned to Offset Byte Set (on 0xA030) with value 5 - anti-clockwise slow release, assigned to Offset Byte Set (on 0xA030) with value 6 - anti-clockwise fast press, assigned to Offset Byte Set (on 0xA030) with value 7 - anti-clockwise fast release, assigned to Offset Byte Set (on 0xA030) with value 8 then I can get around 11 callbacks on the fast button per second: Quote 35312 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35312 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35312 [Buttons] 87=P174,15,Cx0100A030,x03 35312 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35312 LUA.4: **** Offset changed: 4 **** 35328 Monitor IPC:A030 (U8) = 3 35344 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35344 Button changed: bRef=0, Joy=174, Btn=15, Released 35344 [Buttons] 90=U174,15,Cx0100A030,x04 35344 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35359 LUA.4: **** Offset changed: 4 **** 35359 Monitor IPC:A030 (U8) = 0 35375 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35375 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35375 [Buttons] 87=P174,15,Cx0100A030,x03 35375 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35375 Monitor IPC:A030 (U8) = 3 35406 Monitor IPC:A030 (U8) = 0 35406 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35406 Button changed: bRef=0, Joy=174, Btn=15, Released 35406 [Buttons] 90=U174,15,Cx0100A030,x04 35406 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35406 Monitor IPC:A030 (U8) = 4 35406 LUA.4: **** Offset changed: 3 **** 35453 Monitor IPC:A030 (U8) = 0 35453 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35453 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35453 [Buttons] 87=P174,15,Cx0100A030,x03 35453 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35453 LUA.4: **** Offset changed: 4 **** 35484 Monitor IPC:A030 (U8) = 3 35484 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35484 Button changed: bRef=0, Joy=174, Btn=15, Released 35484 [Buttons] 90=U174,15,Cx0100A030,x04 35484 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35484 Monitor IPC:A030 (U8) = 4 35500 LUA.4: **** Offset changed: 4 **** 35515 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35515 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35515 [Buttons] 87=P174,15,Cx0100A030,x03 35515 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35515 Monitor IPC:A030 (U8) = 3 35547 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35547 Button changed: bRef=0, Joy=174, Btn=15, Released 35547 [Buttons] 90=U174,15,Cx0100A030,x04 35547 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35547 Monitor IPC:A030 (U8) = 4 35547 LUA.4: **** Offset changed: 3 **** 35578 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35578 [Buttons] 87=P174,15,Cx0100A030,x03 35594 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35594 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35594 Monitor IPC:A030 (U8) = 3 35594 LUA.4: **** Offset changed: 4 **** 35609 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35609 Button changed: bRef=0, Joy=174, Btn=15, Released 35625 [Buttons] 90=U174,15,Cx0100A030,x04 35625 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35625 Monitor IPC:A030 (U8) = 4 35640 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35640 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35640 [Buttons] 87=P174,15,Cx0100A030,x03 35640 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35640 LUA.4: **** Offset changed: 4 **** 35656 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35656 Button changed: bRef=0, Joy=174, Btn=15, Released 35656 [Buttons] 90=U174,15,Cx0100A030,x04 35656 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35687 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35687 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35687 [Buttons] 87=P174,15,Cx0100A030,x03 35687 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35703 Monitor IPC:A030 (U8) = 3 35719 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35719 Button changed: bRef=0, Joy=174, Btn=15, Released 35719 [Buttons] 90=U174,15,Cx0100A030,x04 35719 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35719 LUA.4: **** Offset changed: 3 **** 35734 Monitor IPC:A030 (U8) = 4 35765 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00008000} 35765 Button changed: bRef=0, Joy=174, Btn=15, Pressed 35765 [Buttons] 87=P174,15,Cx0100A030,x03 35765 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x3 35765 LUA.4: **** Offset changed: 4 **** 35781 Monitor IPC:A030 (U8) = 3 35812 Monitor IPC:A030 (U8) = 0 35812 LUA.4: **** Offset changed: 3 **** 35828 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} 35828 Button changed: bRef=0, Joy=174, Btn=15, Released 35828 [Buttons] 90=U174,15,Cx0100A030,x04 35828 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x4 35859 LUA.4: **** Offset changed: 4 **** 36234 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00004000} 36234 Button changed: bRef=0, Joy=174, Btn=14, Pressed 36234 [Buttons] 84=P174,14,Cx0100A030,x01 36234 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=A030, Param=x1 36250 Monitor IPC:A030 (U8) = 1 36281 LUA.4: **** Offset changed: 1 **** 36297 Monitor IPC:A030 (U8) = 0 36328 LUA.4: **** Offset reset: 0 value received **** Not as fast as using flags, and only applicable if your rotary buttons alternate between a press and release, in which case you should use separate parameters/values for press and release so that the offset change is triggered. John
AlMassimo Posted June 5 Author Report Posted June 5 OMG!!! Thanks John, fantastic research and testing! I'll be able to do some testing on saturday since at the moment I am away from home, and of course I'll report the result. I am pretty optimistic that something of this will work. I have a wide set of SIOC/LUA/Mobiflight code for almost all the B737, and of course the MCP is an essential part of that. With Mobiflight all encoders would work perfectly since I tested them on "test" encoders that I use for cockpit flooding or for other secondary tasks. So the issue is with SIOC and maybe the 0x3110 command offset. I'll also test lua mods, but with encoders I normally never react to 0 value that is used only to reset the offset in order to detect the following -1 or 1. Increasing the reaction speed of lua would also solve the problem, since as accuracy and precision lua is unbeatable. Thanks again
John Dowson Posted June 5 Report Posted June 5 1 minute ago, AlMassimo said: So the issue is with SIOC and maybe the 0x3110 command offset. Yes. Hopefully that modified version I attached above will allow the same control yo be resent via 0x3110 - let me know if that works. And as I said, I can't really help with SIOC. However, I do see that you had similar issues sending presets via SIOC 3+years ago, which you reported in this thread: 3 minutes ago, AlMassimo said: I'll also test lua mods, but with encoders I normally never react to 0 value that is used only to reset the offset in order to detect the following -1 or 1. Understandable - and that is why I was using parameters > 0, and just setting back to 0 in the event handler rather than in the client after sending the proper parameter, as you seem to be doing when using SIOC. 5 minutes ago, AlMassimo said: Increasing the reaction speed of lua would also solve the problem, since as accuracy and precision lua is unbeatable. I have looked at this several times now and just don't understand why lua executes so much slower in FSUIPC7 compared to previous versions of FSUIPC. There has been no real change in the lua engine or how this runs in FSUIPC7 (threads, etc) compared to previous versions, just updates to the additional lua library functions. So I don't understand the performance difference in FSUIPC7. I will look at this again when time permits, but as well as not having the time/resources for this at moment, I am not sure even where to start... John
AlMassimo Posted June 7 Author Report Posted June 7 Hi John, I tested the updated Fsuipc7.exe with the previous SIOC code (that changed the parameter and sent the rotor_brake command via 3110 but the former control was sent as before, so I switched to the SIOC code with myevents.txt removing the events.txt file (renaming). And... VOILA', everything worked perfectly. All 3 encoders, speed, hdg and Alt sent the correct "myevent" with 1 as param and, as I (greatly) hoped the event is triggered properly and very quickly. No need for slow/fast selection. If I rotate the knob slowly the value changes slowly, but if I rotate the encoder as fast as I can still the value follows perfectly the detents per cycle and in a few seconds I can change, eg, speed from 180 to 310 Kts or heading from 30 to 210 without affecting any other parameter. I'm so happy with that! Now the MCP is fully working, fast and reliable as far as I could test it for the moment. Lua is Ok for all other controls, maybe the displays could be updated faster, so I will try to use Lvars in Fsuipc.ini to make the SPD. HDG, ALT and VS values available to SIOC without passing through lua. This should make the MCP controls even more reactive and fast. So probably the issue was only when a different parameter is sent from SIOC to the same control via 0x3110, while changing the control sent there are no issues (the parameter is always 1 but I think that even changing it would have no issues since the control is different) I will also do some testing using strings to call directly the event via event name, that would be fantastic (if SIOC can handle strings but I think it does). Please let me know if you want me to send you the code I used, but I think you already figured it out. Thanks for your support! Massimo
AlMassimo Posted June 8 Author Report Posted June 8 I read all the SIOC manual and apparently it can't handle text variables. So it is not possible for me to activate events via event name, that's a pity but calling by number works perfectly so that's good. By the way I wonder what happens if I delete "events.txt" and use the content of myevents.txt renaming it to events.txt ? Probably if I call events.txt the only issue is that it will be overwritten by newer events.txt whil myevents.txt is more "safe". Is this the only difference? (Just to understand). Now I'm testing a combination of Fsuipc.ini lvars offsets and myevents.txt events. Seems great. Probably I'll be able to replace all lua code and increase reaction speed.
John Dowson Posted June 8 Report Posted June 8 2 hours ago, AlMassimo said: By the way I wonder what happens if I delete "events.txt" and use the content of myevents.txt renaming it to events.txt ? Probably if I call events.txt the only issue is that it will be overwritten by newer events.txt whil myevents.txt is more "safe". Is this the only difference? (Just to understand). You could do that, but that is an issue - you would have to remember to not install that file each time you updated. I don't see any advatantage in doing this. Really I should process the myevents.txt file first, so the control numbers for the presets always start from that file. I could change this in the next release I guess, as anyone who is using the control numbers for presets is most probably not using the events.txt file for this reason. 12 hours ago, AlMassimo said: I tested the updated Fsuipc7.exe with the previous SIOC code (that changed the parameter and sent the rotor_brake command via 3110 but the former control was sent as before, so I switched to the SIOC code with myevents.txt removing the events.txt file (renaming). I think this is because you are writing the parameter AFTER the control number to offset 0x3110. As I said, you should write the parameter first, then write the control number to offst 0x3110 after the parameter has been written. The change in that version was to allow the same control number written to 0x3110 to still trigger the events. I will do some more testing on this next week, 12 hours ago, AlMassimo said: And... VOILA', everything worked perfectly. All 3 encoders, speed, hdg and Alt sent the correct "myevent" with 1 as param and, as I (greatly) hoped the event is triggered properly and very quickly. Well, that is surprising as the preset/calc code should be the same as sending the Rotor Brake control. I will also test this next week. 12 hours ago, AlMassimo said: So probably the issue was only when a different parameter is sent from SIOC to the same control via 0x3110, while changing the control sent there are no issues (the parameter is always 1 but I think that even changing it would have no issues since the control is different) Yes - this is what hat patched version was supposed to address, so I am not sure why it isn't working. I will get back to you sometime next week when I have had time to test a bit more. John
AlMassimo Posted June 8 Author Report Posted June 8 7 hours ago, John Dowson said: Really I should process the myevents.txt file first, so the control numbers for the presets always start from that file. I could change this in the next release I guess, as anyone who is using the control numbers for presets is most probably not using the events.txt file for this reason. Yes I agree completely! Since events.txt is subject to continuous updates, and so you can't rely on static addressing, at least myevents is totally under user control, and it would be great if it was always on the same address/offset. I have a subfolder for each plane containing an Fsuipc.ini, a plane_name.lua, a myevents.txt and myoffsets.txt, a Mobiflight config file and a SIOC file. I replace all the files when I decide to fly with a different plane, and for some time I reconfig the simulator for the current plane. This is pretty satisfactory, since each file is pretty clear and contains no other planes parameters or code. 7 hours ago, John Dowson said: I think this is because you are writing the parameter AFTER the control number to offset 0x3110. As I said, you should write the parameter first, then write the control number to offst 0x3110 after the parameter has been written. No, the code was the following : Var 0175, name E_HDG, Link IOCARD_ENCODER, Input 6, Aceleration 1, Type 2 { IF &E_HDG = 1 { &FS_PAR = 39008 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } ELSE { IF &E_HDG = -1 { &FS_PAR = 39007 &FS_CONTROL = 66587 &FS_CONTROL = DELAY 0 10 } } } so I think I'm setting the parameter BEFORE calling the control, in this case 66587. Looking for a better Autobrake knob handling (apparently PMDG provided controls only for decreasing and increasing, not to set a value from a rotary switch) I found that some events are available and they work very fine, thanks to a post on avsim of Lorby_SI "If you want to set the auto brake selector to specific positions, use the PDMG SDK Events instead. In this case #70092: EVT_MPM_AUTOBRAKE_SELECTOR. Values 0-5 will set the selector to the desired position. You can do that directly on the button assignment, by assigning #70092 as the Key Down event and then dialling in the number that you want to send to it in the value box to the right. Or use a script "n (>K:#70092)" n is the number to send, 0-5" So I configured MF to send an FSUIPC event 70092 with the parameter 0, 1, 2, ... 5 for each AB level, and that worked perfectly. I can't find were these events are located and what means the address 70092. Maybe you can understand what is. Probably there are many other events not available among HubHop presets. They should be located under PMDG 737 sdk somewhere. I found some, but not the address 70092. Anyway as I wrote, I am gradually transferring the lua code into SIOC code using Lvar offsets and myevents, and things are going faster now!
John Dowson Posted June 9 Report Posted June 9 15 hours ago, AlMassimo said: Looking for a better Autobrake knob handling (apparently PMDG provided controls only for decreasing and increasing, not to set a value from a rotary switch) I found that some events are available and they work very fine, thanks to a post on avsim of Lorby_SI "If you want to set the auto brake selector to specific positions, use the PDMG SDK Events instead. In this case #70092: EVT_MPM_AUTOBRAKE_SELECTOR. Values 0-5 will set the selector to the desired position. You can do that directly on the button assignment, by assigning #70092 as the Key Down event and then dialling in the number that you want to send to it in the value box to the right. Or use a script "n (>K:#70092)" n is the number to send, 0-5" So I configured MF to send an FSUIPC event 70092 with the parameter 0, 1, 2, ... 5 for each AB level, and that worked perfectly. I can't find were these events are located and what means the address 70092. Maybe you can understand what is. Probably there are many other events not available among HubHop presets. They should be located under PMDG 737 sdk somewhere. I found some, but not the address 70092. There are two methods to use the PMDG custom controls: one is via the Rotor Brake Control, and the 2nd method is to use the custom control number. EVT_MPM_AUTOBRAKE_SELECTOR is defined in the PMDG SDK header file PMDG_NG3_SDK.h: Quote #define EVT_MPM_AUTOBRAKE_SELECTOR (THIRD_PARTY_EVENT_ID_MIN + 460) So the custom control number would be 69632 + 460 = 70092. For the values the control takes, you need to see what the associated variables holds: Quote unsigned char MAIN_AutobrakeSelector; // 0: RTO 1: OFF ... 5: MAX Generally you would use custom controls via the Rotor Brake method to emulate mouse clicks, and the custom control methos can send actual values (as well as emulate mouse clicks). See the followinf FAQ entries on using both methods, and on how to determine the control number/parameter to use" Note that there also special offsets for PMDG aircraft, so, for example, the current value of MAIN_AutobrakeSelector would be held in offset 0x6607 (if/when PMDG offsets are enabled and data broadcasting has been activated): Quote 6607 1 BYTE MAIN_AutobrakeSelector 0: RTO 1: OFF ... 5: MAX John
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now