aua668

Hi, Check the uer guide of FS Realtime, how to enter your registration key, which you received for FS Realtime. Rgds Reinhard realtime_userguide.zip

Hi, I assume, the window on the second monitor is an undocked window. In that case you could try to use this LUA code: local lhandle = ext.gethandle( "PUT YOUR WINDOW TITLE HERE" ) ext.focus() -- select main application window ipc.sleep(100) -- wait some time ext.focus(lhandle) -- set the focus to the window ipc.control( 66860) -- replace the parameter with the number found in the P3D controls list (VIEW CAMERA SELECT x) Rgds Reinhard

Hi, I did now the test for the Aerosoft A320 - and again: No errors anymore and all modules are working as before. Rgds Reinhard FSUIPC6.log

Hi, This looks GREAT !!! No more errors in the log and all modules did work after a short cross check. It seems, that my planes are not grounded anymore. Many, many thanks! Reinhard 😀😀😀 FSUIPC6.log

John, Success - I used now this version and started my modules with the Q400. And in the log #1 I find now errors exactly for those modules, which did only partially work: 216484 LUA.7: LUA\Q400\Q400_GF_NAV2 started 216656 *** LUA Error: ...repar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_NAV2.lua:180: Coudn't enter critical section! Then I did a second run, where also these errors occured. But with different modules. You find the result in log #2. Before closing the simulator I turned on LUA debugging. Then I started run #3. With debugging turned on, the error only occured for a single module: Q400_GF_PanelLt.lua 203906 *** LUA Error: ...ar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_PanelLt.lua:87: Coudn't enter critical section! If you need more logs, please let me know. I attached also the Q400_GF_PanelLt.lua and NAV1 and NAV2 for your reference. Best regards Reinhard FSUIPC6_1.log FSUIPC6_2.log FSUIPC6_3.log Q400_GF_PanelLt.luaQ400_GF_NAV2.luaQ400_GF_NAV1.lua

Hi, You can of course define differnt profiles for individual aircraft variants. That's not against the concept of profiles. The profiles (especially with the ShortAircraftNameOk=Substring) are useful, if you want to have the same settings in sync for a lot of variants of your aircraft, as assigning and calibrating is a lot of work to keep it consistent. But also your use case is valid for profiles. For your original problem I have no idea, why this happens only for that camera definition. I also use a lot of different camera views in the VC. But I have only one camera definition and set the position and view direction in a LUA program. I have two touchscreens below my curved monitor fo the outside view. On these two monitors I set different views of this special ockpit camera (with no outside visualization) according to a table, which I define per aircraft type. That's just some code pieces out of other functions to give you an idea how to solve this by using LUA. AC.CameraUpCoordL = {} AC.CameraUpCoordR = {} AC.CameraUpCoordL[1] = { 14.0 , 0.00 , 0.00 , -0.26 , -0.35 , 0.3 } AC.CameraUpCoordR[1] = { 14.0 , 0.00 , 0.00 , 0.26 , -0.35 , 0.3 } AC.CameraUpCoordL[2] = { -29.70 , 0.00 , 0.00 , -0.2 , 0.00 , 0.00 } AC.CameraUpCoordR[2] = { -29.70 , 0.00 , 0.00 , 0.2 , 0.00 , 0.00 } AC.CameraUpCoordL[3] = { -52.00 , 0.00 , 0.00 , -0.2 , -0.11 , 0.00 } AC.CameraUpCoordR[3] = { -52.00 , 0.00 , 0.00 , 0.2 , -0.11 , 0.00 } : : -- set cockpit camera for VC function setCameraL ( lCameraCoordList ) ipc.writeSTR ( 0x8680 , "Cockpit Camera - View 01" ) -- select cockpit camera ipc.writeStruct( 0x86A0 , "6FLT" , lCameraCoordList[4] -- X , lCameraCoordList[5] -- Y , lCameraCoordList[6] -- Z , lCameraCoordList[1] -- Pitch , lCameraCoordList[2] -- Tilt , lCameraCoordList[3] -- Heading ) ipc.sleep(100) end function setCameraR ( lCameraCoordList ) ipc.writeSTR ( 0x8680 , "Cockpit Camera - View 02" ) -- select cockpit camera ipc.writeStruct( 0x86A0 , "6FLT" , lCameraCoordList[4] -- X , lCameraCoordList[5] -- Y , lCameraCoordList[6] -- Z , lCameraCoordList[1] -- Pitch , lCameraCoordList[2] -- Tilt , lCameraCoordList[3] -- Heading ) ipc.sleep(100) end : : function setCameras (lPanel) setCameraL ( AC.CameraUpCoordL[lPanel] ) setCameraR ( AC.CameraUpCoordR[lPanel] ) end : : -- sample call for first camera setup setCameras (1) Maybe this is a better method instead of using different camera definitions. And by that you are not limited to the number of hotkeys. Rgds Reinhard

Hi Roger, Ok now your intention is clear. I wonder, how you assign different panel variants, as you reference in both variants in the aircraft.cfg the standandar panel entry: panel= If you have different panel variants, why don't you have here distinct panel references? Are you just not showing the GTN750 in the first variant? Rgds Reinhard

Hi, Some observations - but not related to the specific problem: Your INI file shows some error in the joystick configuration. You should correct this to avoid other problems: [JoyNames] AutoAssignLetters=Yes A=Saitek Pro Flight Quadrant A.GUID={3C53B7E0-BA58-11EB-8001-444553540000} C=Alpha Flight Controls C.GUID={98AE71F0-B7F2-11EB-8002-444553540000} D=Alpha Flight Controls D.GUID={3C53B7E0-BA58-11EB-8001-444553540000} E=Saitek Pro Flight Rudder Pedals E.GUID={502347D0-D007-11EB-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={502347D0-D007-11EB-8001-444553540000} 0=Saitek Pro Flight Quadrant 0.GUID={3C53B7E0-BA58-11EB-8001-444553540000} 2=Alpha Flight Controls 2.GUID={98AE71F0-B7F2-11EB-8002-444553540000} B=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> F=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> You said, that you have setup seperate profiles by intention. What is the reason for that. It's always the same aircraft model and panel behind the scenes. So why not use the same setting for all variants? You have set the parameter ShortAircraftNameOk=Substring for profiles. This would allow you to use one single profile for all of your PA23 variants. In your case this could look like this: [Profile.Alabeo PA23 Aztec F 250] 1=Alabeo PA23 Aztec F 250 [Axes.Alabeo PA23 Aztec F 250] RangeRepeatRate=10 0=AX,256,D,4,0,0,0 -{ DIRECT: Throttle }- 1=AY,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 2=AZ,256,D,6,0,0,0 -{ DIRECT: Mixture }- 3=AU,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 4=AV,256,D,6,0,0,0 -{ DIRECT: Mixture }- 5=EX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 6=EY,256,D,0,8,0,0 -{ DIRECT: RightBrake }- 7=ER,256,D,3,0,0,0 -{ DIRECT: Rudder }- 8=CX,256,D,1,0,0,0 -{ DIRECT: Aileron }- 9=CY,256,D,2,0,0,0 -{ DIRECT: Elevator }- 10=CP,0,F,66416,0,0,0 -{ TO SIM: PAN_VIEW }- [JoystickCalibration.Alabeo PA23 Aztec F 250] AllowSuppressForPFCquad=Yes ExcludeThrottleSet=Yes ExcludeMixtureSet=Yes ExcludePropPitchSet=Yes SepRevsJetsOnly=No ApplyHeloTrim=No UseAxisControlsForNRZ=No FlapsSetControl=0 FlapDetents=No ReverserControl=66292 Reverser1Control=66422 Reverser2Control=66425 Reverser3Control=66428 Reverser4Control=66431 MaxThrottleForReverser=256 AileronTrimControl=66731 RudderTrimControl=66732 CowlFlaps1Control=66162 CowlFlaps2Control=66163 CowlFlaps3Control=66164 CowlFlaps4Control=66165 SteeringTillerControl=0 MaxSteerSpeed=60 Elevator=-16287,-512,512,16319 Throttle=-16384,16255 PropPitch=-16254,16255 Mixture=-16384,16383 Aileron=-16159,-578,512,16383/8 ElevatorTrim=-16380,-512,512,16380 SlopeElevatorTrim=-12 SlopeAileron=-3 LeftBrake=-16384,16383/16 RightBrake=-16384,16383/16 Rudder=-15610,-512,512,15807 SlopeLeftBrake=-8 SlopeRightBrake=-8 SlopeRudder=9 [Buttons.Alabeo PA23 Aztec F 250] 12=RA,1,C66243,0 -{INC_COWL_FLAPS}- 38=RA,0,C66244,0 -{DEC_COWL_FLAPS}- 48=PC,0,C66856,0 -{VIEW_CAMERA_SELECT_6}- 49=UC,0,C66851,0 -{VIEW_CAMERA_SELECT_1}- 52=PC,3,C65561,0 -{PAUSE_TOGGLE}- 53=PC,10,C66858,0 -{VIEW_CAMERA_SELECT_8}- 54=UC,10,C66851,0 -{VIEW_CAMERA_SELECT_1}- 58=PA,3,C65758,0 -{FLAPS_INCR}- 60=PA,4,C66079,0 -{GEAR_UP}- 61=PA,5,C66080,0 -{GEAR_DOWN}- 62=PA,2,C65759,0 -{FLAPS_DECR}- 63=RC,7,C66855,0 -{VIEW_CAMERA_SELECT_5}- 65=PC,6,C66857,0 -{VIEW_CAMERA_SELECT_7}- 66=PC,11,C66859,0 -{VIEW_CAMERA_SELECT_9}- 67=UC,11,C66851,0 -{VIEW_CAMERA_SELECT_1}- 72=PC,28,C66052,0 -{STROBES_ON}- 73=PC,29,C66053,0 -{STROBES_OFF}- 83=PC,1,C66579,0 -{TOGGLE_CABIN_LIGHTS}- 84=RC,5,Cx42000BC0,xC0010100 -{offset sword decrement, offset 0BC0 (Decr=256, Limit=-16383)}- 85=RC,4,Cx32000BC0,x3FFF0100 -{offset sword increment, offset 0BC0 (Incr=256, Limit=16383)}- 86=PC,22,C66237,0 -{FUEL_PUMP}- 87=PC,23,C66237,1 -{FUEL_PUMP}- In that profile the WHITE and the F-BALY would be covered by the same profile. And by that you only have to configure your axis, buttons, etc. only once. And if it works in one variant, it works for all variants. Btw.: Your configurations differ quite a lot between the WHITE and the F-BALY profile. So you are using axis assignments for missing joysticks in parallel with axis assignments for the same axis for existing joysticks. No idea, what your intention you had here. This doesn't solve your problem, but any error in a configuration could lead to other errors. So I would first try to eliminate those errors. Rgds Reinhard

Hi, I am sorry - but this version does not start at all on my machine. It's simply not loaded, when I replace the original DLL by your version. There is no error generated. But FSUIPC menu is not appearing and no log is generated. Replacing this file again with the original DLL it's working again and FSUIPC is started. Rgds Reinhard

As in other modules: I have several events registered - the event.button triggers are firing (i see, that the switches are operated in the cockpit) but the event.offset, which should tun on the LED on the GF module, when the battery switch is on, did not fire, although the offset did change, which I verified by FSInterrogate. So it's always the same scenarion: The module is running - most of the events are handled as expected - and one or two out of them are not working, although the trigger should fire them. That's exactly what I am observing: debugging and logging makes it impossible to reproduce. And also it's occuring randomly and in different modules. My observation is, that it occurs more often in modules, which are sterted later, when other modules are already running and a lot of events are alredy actively monitoring the trigger condition. I observerd the phenomen most likely with event.offset and event.offsetmask triggers. I will try with the new DLL this evening. I am happy, that you also had a chance to see it. I was alredy seriously thinking of a complet new setup of my machine, what would be an enourmous effort with all the sceneries and planes. As I am typically very carefully with my installations, I never had to do this step in the past. Of course for new major versions of the sim I did it anyhow. Best regards Reinhard

Hi, I am away at the moment of my simulator, so I can't cross check. But I use it with the A320. And as far as I remember, it worked as planned. Rgds Reinhard

Hi, I did two test runs with the attached DLL. The first run was done without extra debugging. And COM1 and NAV1 did not execute the event.offset triggers. But the log looks normal. Then I started with full logging enabled. COM1 was working here normally. But some other modules (like GF_BAT.lua) did not completely work as expected, although they show normal behaviour in the log file. I did disable the module with the event.timer function, as otherwise the log would have exploded. I am the next two days on a conference. So I will continue testing on the weekend. Rgds Reinhard FSUIPC6_COM1_NAV_error.log FSUIPC6_Full.log

Hi, You are correct in all of your assumptions. I define one range to arm the spoilers when I move the lever into that range and to disarm, when I leave this area. Then there is a detent at my lever. In the range of this detent I want to be sure, that the spoiler is off. That's why I trigger an spoiler off command in that area. And then there is the range, where the spoiler axis is sent to the simulator. On page 38 of the FSUIPC6 User Guide you will find the screenshots, how to define commands for ranges of an axis. Rgds Reinhard

I will try with this version - Thanks! Rgds Reinhard

Hi, I also thought, that I hit a hard coded limit, but this must have been introduced with P3D 5.2. Until this version this never happened. I use this method to start my necessary modules per aircraft since FSX times already. And yes - if more modules are loaded, the probability, that it occurs, raises. If I enable logging from the beginning, I was not yet able to reproduce it until so far. Maybe the monitoring/logging influence the startup. But I will continue to try to reproduce it. I also did some experiments by delaying the start. I extended the ipc.sleep call between each ipc.runlua call in my starting loop. But even if I waited 5 seconds between each single ipc.run call, it happened sometimes. The Q400_GF_COM1.lua is one of the modules which are loaded quite late in sequence. And with that module it happens quite often compared to others. So a lot of other modules and events monitored are already active during start. The other modules COM2, NAV1 and NAV2 are also candidates. For these modules it's easy to detect, because in most cases the event.offset triggers are effected and in that case my displays on the GoFlight hardware stay dark. Yesterday I had similar problems in the Q400_GF_EFIS.lua, where all events have been working but the one for increasing the QNH did not trigger the function. I manually restarted the module and in the 3rd attempt I got it working normally. So it's randomly occuring in different modules. I plan also to reinstall all Microsoft Visual C++ runtimes completely new, as at the time of my upgrade to 5.2 there was also a major Windows update (2021-06 Windows 10 21H1) to be sure, that this isn't the reason. This cleaning helped in the past with several problems. My system is stable and I have frames limited to have enough CPU capacity available. I assigned cores with enough headroom of capacity to LUA and FSUIPC via an affinity mask. My sim is running completely stutter free. So load should not be a problem. At the moment I am only able to fly the MD 530 helicopter or similar simple aircrafts. Q400 or A320 are always a challenge, if you detect that one button is not working as expected 😉 Rgds Reinhard

Hi, I have no knowledge about the PMDG, but did you calibrate the spoiler axis: Spoilers=-16380,16380/16 My entry, where I have specified the range, which should control the spoiler, looks different to yours. And the range for arming the spoiler and for turning it off is also missing. Pete gave you already the hint to define this region for arming/disarming. Rgds Reinhard

Hi, I have configured my GoFlight spoiler in the Aerosoft A3xx profile like this: [Axes] : : 5=GX,256,D,22,0,0,0 -{ DIRECT: Spoilers }- 6=GX,B,12518,16383,66066,0,66067,0 -{ DIRECT: SpoilersEntering=SPOILERS_ARM_ON, Leaving=SPOILERS_ARM_OFF }- 7=GX,B,8836,11413,66065,0 -{ Entering=SPOILERS_OFF }- : : [JoystickCalibration] : : Spoilers=-4608,15018/16 Rgds Reinhard

Yes - the issue in the trace above occured with only one module running. Although th probality, that it happens, increases with the number of modules running. I run a similar module setup for the AS Twin Otter (with less modules) and there it was not happening so far. With the AS320 it also happens. I did some more tests and add the logfiles here. FSUIPC6_your_module.log I started only your module (I changed the name to GF_Test, as I have already a button assignment to start this specific module for test purposes). I also changed the button to trace to the GoFlight rotary for COM1 (143/8..15 instead of 175/0..7). With logging enabled it always worked and I could not reproduce. FSUIPC6_all_modules_started.log I started all my modules (but omitted the one with the event.timer function) with the full logging turned on. And I was not able to reproduce the error in that mode. FSUIPC6_normal.log I started all my modules including the one with the event.timer trigger but with only logging the COM1 offsets. I was not able to reproduce the error. FSUIPC6_COM1_error.log I started the test with all my modules a second time and in that run COM1 event functions, which should display the frequencies have not been triggered. In the log you see in that line, that I started the module out of my loop across all modules: 202375 LUA.8: LUA\Q400\Q400_GF_COM1 started After detecting, that COM1 was not working as expected, I enabled full logging again (see line 265609). By enabling the logging for the LUA modules, it showed, that COM1 did not show up in the list of modules waiting for an event (like all other modules), although the module was started and there are definitely event triggers defined. Shutting down the simulator closes all modules. But COM1 also never showed up in the logfile during shutdown. So it must have been in a type of inactive state. Very strange. Reinhard FSUIPC6_your_module.log FSUIPC6_all_modules_started.log FSUIPC6_normal.log FSUIPC6_COM1_error.log

One of my plugins use the event.timer function and runs some code every second. By that the logfile get's quite big and cluttered and it's hard to read. But I will do as advised. I added for one single module to each of the button event functions a simple ipc.log line and I started only this single module (Q400_GF_COM1 from above). So there was only one module running. The logfile extract simply shows, that one of the functions (IncCOM10) fired during the event registrations, although buttons never should fire the function during event registration. At several runs I even got two or three functions firing without touching any button. I will test your script, when I return to home. Many thanks for taking care. Best regards Reinhard

These errors are only raised, if I use the Majestic Q400. These errors are shown since all versions of the Q400 for P3D (and as far as I remember even with FSX). I did a fresh installation for all major versions of P3D and always install the updates according to the proposed procedure. Other planes don't show these errors. Also other users have these errors in the logfile, if they use the Q400: https://forum.simflight.com/topic/91564-have-to-hit-reload-all-buttons-every-time/ Rgds Reinhard

Hi, Another strange finding: I added debugging info to the module above, as I found, that starting of the module increased my standby frequency. So I added simple logging code to the modules: function IncCOM10 (joynum, button, downup) ipc.log("IncCOM10") IncDecCOM1 (25) end function IncCOM11 (joynum, button, downup) ipc.log("IncCOM11") IncDecCOM1 (100) end function IncCOM12 (joynum, button, downup) ipc.log("IncCOM12") IncDecCOM1 (1000) end function IncCOM13 (joynum, button, downup) ipc.log("IncCOM13") IncDecCOM1 (1000) end function DecCOM10 (joynum, button, downup) ipc.log("DecCOM10") IncDecCOM1 (-25) end function DecCOM11 (joynum, button, downup) ipc.log("DecCOM11") IncDecCOM1 (-100) end function DecCOM12 (joynum, button, downup) ipc.log("DecCOM12") IncDecCOM1 (-1000) end function DecCOM13 (joynum, button, downup) ipc.log("DecCOM13") IncDecCOM1 (-1000) end When I registered the buttons: -- register button events up/down event.button(GF_JoyLetter, GF_Button, 3, "DecCOM13") event.button(GF_JoyLetter, GF_Button+1, 3, "DecCOM12") event.button(GF_JoyLetter, GF_Button+2, 3, "IncCOM12") event.button(GF_JoyLetter, GF_Button+3, 3, "IncCOM13") event.button(GF_JoyLetter, GF_Button+4, 3, "DecCOM11") event.button(GF_JoyLetter, GF_Button+5, 3, "DecCOM10") event.button(GF_JoyLetter, GF_Button+6, 3, "IncCOM10") event.button(GF_JoyLetter, GF_Button+7, 3, "IncCOM11") One of the routines fired during registering the event. But only one. No other modules have been running. So this is the only module active at that time: 5608297 LUA: "GF_Test.lua": killed 5626125 LUA.69: IncCOM10 It's getting even more strange. Rgds Reinhard

Hi, After writing this post, I started my modules again with logging enabled as suggested. I incremented the standby frequency, the button event was trapped and the offset for the standby frequency of COM1 changed - but the event.offset trigger never fired: 3338203 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338437 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00000000} 3338437 LUA.58: Button event: calling "IncCOM10" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338453 Monitor IPC:311A (U16) = 6512 3338500 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338734 LUA.58: Button event: calling "IncCOM10" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3338734 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00004000} 3338734 Monitor IPC:311A (U16) = 6514 3338797 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3339078 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00000000} 3339078 LUA.58: Button event: calling "IncCOM10" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 3339109 Monitor IPC:311A (U16) = 6517 3339172 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" All the other offset triggers worked as expected. Here the swap of frequencies, which changes the offset of COM1: 4199766 JoystickValues PCnum=0, dwCount=1, data[2]={0000008f 00004001} 4199781 LUA.58: Button event: calling "SetCOM1Swap" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 4199797 FS Control Sent: Ctrl=66372, Param=0 COM_STBY_RADIO_SWAP 4199828 Monitor IPC:034E (U16) = 6519 4199828 SimRead: 034E="COM ACTIVE FREQUENCY:1" INT32: 6519 (0x00001977) 4199828 Monitor IPC:311A (U16) = 8544 4199828 SimRead: 311A="COM STANDBY FREQUENCY:1" INT32: 8544 (0x00002160) 4200016 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 4200016 LUA.58: Offset Change event: calling "DispCOM1" in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" 4200016 LUA.58: Waiting for an event in "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\LUA\Q400\Q400_GF_COM1.lua" Both offsets changed, but only DispCOM1 was executed while DispCOM1Stby never was triggered. Rgds Reinhard

Hi, I did deeper analysis with one module, where this phenomenon did happen more often than at others. For handling COM1 (or COM2) via my GoFlight module I use the following module: -- Q400_GF_COM1.lua -- V1.3 -- Q400 implementation of the GF COM1 -- include GF variables require "GF_Variables" local GF_Model = GF166 -- name of device local GF_Unit = GFHW.GF_166_1 -- Id (default=0) local GF_JoyLetter = GFHW.GF_166_Joy_1 -- Joy-Letter of switch/button local GF_Button = GFHW.GF_166_Sel_1 local GF_JoyButtonSwap = GFHW.GF_166_But_1 -- Joy-Button of toggle switch/button local GF_JoyButtonID1 = GF_JoyButtonSwap + 1 -- Joy-Button of switch/button local GF_JoyButtonID2 = GF_JoyButtonSwap + 2 -- Joy-Button of switch/button local GF_Id_COM11 = 0 -- Id of COM11 local GF_Id_COM12 = 1 -- Id of COM12 local GF_Id_ID1 = 1 -- Id of LED 1 local GF_Id_ID2 = 2 -- Id of LED 2 -- define P3D controls require "P3D_Controls" -- define XML interface require "Q400_Write_XML_IF" function IncDecCOM1 (pStep) local lValue2 = string.format( "%04X", ipc.readUW(0x311A) ) local lCOM1 = lValue2 * 10 + 100000 local lFract = 0 local lCorr = 0 lCOM1 = lCOM1 + pStep if lCOM1 < 118000 then lCOM1 = 118000 end if lCOM1 > 136975 then lCOM1 = 136975 end lFract = lCOM1 % 100 if lFract == 25 or lFract == 75 then lCorr = -5 end if lFract == 45 or lFract == 95 then lCorr = 5 end lValue2="0x"..math.floor( (lCOM1+lCorr-100000) / 10 ) ipc.writeUW(0x311A, lValue2+0) writeXMLIF ( Q400_XML.ARCDUCOM1StbyFreq , lCOM1+lCorr - 100000 ) end function IncCOM10 (joynum, button, downup) IncDecCOM1 (25) end function IncCOM11 (joynum, button, downup) IncDecCOM1 (100) end function IncCOM12 (joynum, button, downup) IncDecCOM1 (1000) end function IncCOM13 (joynum, button, downup) IncDecCOM1 (1000) end function DecCOM10 (joynum, button, downup) IncDecCOM1 (-25) end function DecCOM11 (joynum, button, downup) IncDecCOM1 (-100) end function DecCOM12 (joynum, button, downup) IncDecCOM1 (-1000) end function DecCOM13 (joynum, button, downup) IncDecCOM1 (-1000) end function readCOM1 () local lValue2 = string.format( "%04X", ipc.readUW(0x034E) ) local lCOM1 = lValue2 * 10 local lFract = 0 local lCorr = 0 lFract = lCOM1 % 100 if lFract == 20 or lFract == 70 then lCorr = 5 end lValue2 = lCOM1 + lCorr return lValue2 end function readCOM1Stby () local lValue2 = string.format( "%04X", ipc.readUW(0x311A) ) local lCOM1 = lValue2 * 10 local lFract = 0 local lCorr = 0 lFract = lCOM1 % 100 if lFract == 20 or lFract == 70 then lCorr = 5 end lValue2 = lCOM1 + lCorr return lValue2 end function DispCOM1(offset, value) -- react on P3D Input gfd.SetDisplay( GF_Model, GF_Unit, GF_Id_COM11, string.format( "1%02X.%02X", math.floor( ipc.readUW(0x034E)/256 ) , ipc.readUW(0x034E) % 256 ) ) end function DispCOM1Stby(offset, value) -- react on P3D Input gfd.SetDisplay( GF_Model, GF_Unit, GF_Id_COM12, string.format( "1%02X.%02X", math.floor( ipc.readUW(0x311A)/256 ) , ipc.readUW(0x311A) % 256 ) ) end function DispCOM1Id(offset, value) -- react on P3D Input if logic.And(value, 0x80) == 0x80 then gfd.SetLight( GF_Model, GF_Unit, GF_Id_ID1 ) else gfd.ClearLight( GF_Model, GF_Unit, GF_Id_ID1 ) end if logic.And(value, 0xA0) ~= 0x00 then gfd.SetLight( GF_Model, GF_Unit, GF_Id_ID2 ) else gfd.ClearLight( GF_Model, GF_Unit, GF_Id_ID2 ) end end function SetCOM1Swap(joynum, button, downup) -- react on GF Input P3D_Ctrl.P3D_COM_STBY_RADIO_SWAP ( 0 ) ipc.sleep(100) writeXMLIF ( Q400_XML.ARCDUCOM1Freq , readCOM1 () ) writeXMLIF ( Q400_XML.ARCDUCOM1StbyFreq , readCOM1Stby () ) end function SetCOM1ID1(joynum, button, downup) -- react on GF Input writeXMLIF ( Q400_XML.ARCDUMicSelector , 1 ) ipc.clearbitsUB(0x3122, 0x60) ipc.setbitsUB(0x3122, 0x80) end function SetCOM1ID2(joynum, button, downup) -- react on GF Input ipc.togglebitsUB(0x3122, 0x20) end -- initialize COM1 writeXMLIF ( Q400_XML.ARCDUCOM1Freq , readCOM1 () ) writeXMLIF ( Q400_XML.ARCDUCOM1StbyFreq , readCOM1Stby () ) -- track every change of the P3D offsets event.offset( 0x034E, "UW", "DispCOM1" ) event.offset( 0x311A, "UW", "DispCOM1Stby" ) event.offset( 0x3122, "UB", "DispCOM1Id" ) -- Swap COM1 frequencies event.button( GF_JoyLetter , GF_JoyButtonSwap , 1 , "SetCOM1Swap" ) event.button( GF_JoyLetter , GF_JoyButtonID1 , 1 , "SetCOM1ID1" ) event.button( GF_JoyLetter , GF_JoyButtonID2 , 1 , "SetCOM1ID2" ) -- register button events up/down event.button(GF_JoyLetter, GF_Button, 3, "DecCOM13") event.button(GF_JoyLetter, GF_Button+1, 3, "DecCOM12") event.button(GF_JoyLetter, GF_Button+2, 3, "IncCOM12") event.button(GF_JoyLetter, GF_Button+3, 3, "IncCOM13") event.button(GF_JoyLetter, GF_Button+4, 3, "DecCOM11") event.button(GF_JoyLetter, GF_Button+5, 3, "DecCOM10") event.button(GF_JoyLetter, GF_Button+6, 3, "IncCOM10") event.button(GF_JoyLetter, GF_Button+7, 3, "IncCOM11") COM2, NAV1 and NAV2 are implemented in a similar way. When I start my modules, quite often one of the event.offset triggers will not work. Sometimes it's the one for COM1 , sometimes it's the event for the COM1 standby frequency. And sometimes they work normally. And sometimes it's happening at COM2, NAV1 and NAV2. What I have found is the fact, that's always one of the event.offset triggers, which are not firing. I checked with FSInterrogate, that the offse IS changing so the event normally must fire. And the code wasn't changed since all versions of P3D. This strange behaviour started with P3D 5.2. For me there is no reason, why one of these events should not work, while all the others in the module are working. Of course there is no error in the logfile and the offset is changing, which I checked by logging and by FSinterrogate. I start about 40 modules for my hardware components all of similar complexity like this one. Other modules show the same random behaviour - but not so often as the radio modules. I really have no idea, what I should change, that all events are trapped. And I have no idea, how I could support you to reproduce this issue. Rgds Reinhard

Hi, I did the same test as above with event.button. It's not firing ast stated by you. event.Lvar is triggering the function when registering the event (same as with event.offset). Rgds Reinhard

Hi, Thanks for looking at this issue. I am fine, if it is always the case., that it fires during registration. In that case I could take care for it in my code. In fact I didn't care in the past 😉 For events, delivering some values (like COM frequency etc.) it's fine and useful to get the initial value, as you wrote. Therefore also for most of my plugins this was not a problem. For button events, this is more problematic, as this could produce unwanted effects (e.g. increasing the COM frequency), although the button was not pressed, just because I started my LUA plugin. Therefore I wanted to know, if this is always th case, as I then have to ignore the first button press. If you register increase and decrease frequency in the same plugin, they compensate even if they are fired. For the event not registering I did also some investigation as John proposed. I will give an example and explanation in the other thread. During writing this reply, I saw, that John answered, that it's by intention and that it's documented. Shame on me - I overlooked this obviously. I will go back to documentation and check, if this is also the case for the other types of events. Best regards Reinhard