AlMassimo

I started testing but I have some questions... I created a file myevents.txt containing only one row PFD_LS# (>H:A320_Neo_PFD_BTN_LS_1) and I can find PFD_LS in the presets list, but I also see the same H_var already included in HVARS, do I need to put it also under myevents.txt ? H:A320_Neo_PFD_BTN_LS_1 is there already a control value for this one and how do I find it ? I tried to assign both to some key or button, but on the console I don't see this HVAR being called when I press that button/key. What am I doing wrong ? What string should I put in the calculator to see it executed ? And what should I obtain ? In the case of events.txt, the presets would get the offset (I think is an offset, or a control value) 0x400001 (or 26215) I suppose it's 0x40001 (HEX ?) but does not corrispond to 26215... I'm really confused. I know how to assign a control under SIOC by using 0x3110, but I need to understand the exact value to use with it, and wich parameter (I suppose 0 and 1). A lot of things to try and understand...! I searched in the supplied manuals but no match was found for LVAR or HVAR, and I could find no other useful indication, maybe I'm missing some doc.

Ok thanks! Probably the CTDs increased after I installed the FBW, I suspect also Mobiflight increases the instability, I have more confidence in FSUIPC because I always have it running and normally very few CTD happen, but when I switch from normal PC/Joystick flight to my cockpit, I activate SIOC and Mobiflight and the OC modules plus 3 arduinos, and the simulator seems not to like this... but having no crash diagnostics is very difficult to understand what is causing the CTD. I've never seen a program so unstable and without any serious error handling, even if it is a super-wonderful flight simulator that I love nonetheless! Of course maybe the external hardware and software to cause the instability but I had a lot more complex cockpit HW/SW with Xplane and almost no CTD at all... In the weekend I hope to develop the new controls for EFIS and then the FCU (AP/CDU managed modes, the rest is all working)

Hi John, thanks a lot! Good stuff to study and experiment. I have a question, what is the meaning of the value I read after the lvar name in lvars list ? I can't figure out, but maybe it's useful to know. So, after defining the hvars presets in myevents.txt, using the proper control number I could assign to an hvar in SIOC the value needed to perform a function (es. switch LS on and off) by triggering the offset 0x3110 (I'll study how this works on advanced manual). BTW... even when things work perfectly I have a huge lot of CTD of MSFS... what a pity, I spend more time restarting the simulator and reprogramming the flight, etc, than flying and testing the new things I'm studying. Then, without an apparent reason, the sim works smoothly for hours!

First step worked fine. First of all, I enabled WASM addon from fsuipc menu (ALT-F if one wants to know) and then restarted flight. WASM was enabled and I could see a list of LVARS. Great, but only some lvars were displayed. To see the effect of any change it is necessary to hit again list lvars. The correct vars were [LvarOffsets] 1=A320_Neo_MFD_NAV_MODE=UB66C0 2=A320_Neo_MFD_Range=UB66C1 I corrected the second row in fsuipc.ini, then hit reload under wasm menu in fsuip and then both controls worked perfectly. The code in SIOC was Var 0282, name FS_MODO, Link FSUIPC_OUT, Offset $66C0, Length 1 // EFIS_MODE Var 0283, name PM_RANG, Link FSUIPC_OUT, Offset $66C1, Length 1 // PM_EFIS_RANG Then other lines assigned to FS_MODO and PM_RANG the values 0,1,2,3... according to knobs position. All wonderful! (FSUIPC IS a MASTERPIECE, no doubt about this). Now I would like to assign to EFIS buttons the PFD_LS and MFD TERRAIN function, and ARPT and WAYPOINTS. This seems to be more complicated for me because these controls are under HVARS, not LVARS. How I set them ? For the moment, I just don't know.

Hello, after a wide and pretty frustrating search on the net, forums, google searches and reading all supplied manuals and docs, I surrended and now I would like to start a topic (if already exists please someone tell me where to find it) about existing documentation, examples, tutorials or simple posts illustrating step by step procedure to add lvars for a specific plane and assign them to offsets so to control them via hardware (I am trying to convert my B737 MCP and EFIS into A320 functional FCU and EFIS. For the moment I would like to deal with Asobo A320 Neo, and only after that, trying to switch to the more complex FBW 320. At the moment I only understood that I have to insert something like this : [LvarOffsets] 1=A320_Neo_MFD_NAV_MODE=UB66C0 2=A320_Neo_MFD_NAV_Range=UB66C1 in fsuipc.ini, and then from SIOC I should be able to set the values of 66C0 and 66C1 with the usual code. Is that correct ? I think there is a whole world of things to know more than this... where can I find a basic guide ? Thanks a lot for any help!

Thanks, I saw that post, but I don't know how to create the pokeysdevice object without luacom. I could try to compile it in 64 bit environment, but I think I'd rather work on Arduino if it is less complicated that this solution. It was a really powerful and easy to use combination, it's a pity it was abandoned (at least seems abandoned).

No, I installed the most recent luacom.dll I could find, compiled in 2020 and compatible with lua 5.1, in the lua dir under FSUIPC7 dir. Then i set my lua code for the pokeys inside the ipcready lua. These are the first rows of my mip.lua code (that worked fine with fsx when I last used it) require "luacom" poKeys = luacom.CreateObject("poKeysDevice_DLL.poKeysDevice") if poKeys == nil then ipc.log("Error: poKeysDevice_DLL object creation failed.") ipc.display("NO POKEYS - QUIT PROGRAM") ipc.exit() end When I launch MSFS nothing happens, but when I look in the log file I find this : 149422 LUA.1: beginning "C:\FSTools\FSUIPC7\ipcReady.lua" 149422 LUA.1: C:\FSTools\FSUIPC7\ipcReady.lua:1 149438 LUA.1: Global: ipcPARAM = 0 149578 LUA.2: beginning "C:\FSTools\FSUIPC7\mip.lua" 149578 LUA.2: C:\FSTools\FSUIPC7\mip.lua:1 149594 LUA.2: Global: ipcPARAM = 0 149656 *** LUA Error: error loading module 'luacom' from file 'C:\FSTools\FSUIPC7\lua\luacom.dll': %1 non è un'applicazione di Win32 valida. I tested both the luacom supplied with the lua for windows precompiled package (and luacom.dll is dated may 2008...) and the most recent luacom.dll that I found on the net, but none of the two worked (if the error is caused by the specific version of luacom). Currently I am exploring many other territories, form MobiFlight to Python libraries that seem to work directly with simconnect and could be interfaced with arduino, but of course if I could make my Pokeys to work with LUA and FSUIPC I would feel much more "comfortably at home" let me say...!

Looking on the console, the parameter 1 is not received apparently; when I press the button, on the console the row with control 68065 shows a parameter = 0, nevertheless the autopilot knob works, but the Var 0442 should issue a value 1 to the control parameter... This function in SIOC/FSUIPC could be used for improving the old fsx drivers for MCP and even EFIS. My next test will be on the EFIS side, to see if sending controls work on the NAV display or the GPS. I'm also working on interaction between FSUIPC, MobiFlight and Arduino, but I miss my LUA interface with my Pokeys (currently still connected to all my overhead...) Is there any hope that LUACOM will be working again ?

Hello, I found a good solution with this option available in SIOC through a powerful function in FSUIPC : Var 0441 name FS_CONTROL Link FSUIPC_OUT Offset $3110 Length 4 Var 0442 name FS_PAR Link FSUIPC_OUT Offset $3114 Length 4 Var 0426, name I_HDGSEL, Link IOCARD_SW, Input 28 { IF &I_HDGSEL = 1 { &FS_PAR = 1 &FS_CONTROL = 68065 &FS_CONTROL = DELAY 0 10 So pressing the heading lock button I also send the command to commute HDG SLOT to 1, and that work. The first idea (sending an fsuipc virtual joystick button) is very interesting, but worked randomly, sometimes the button press was detected, many other times no. Probably something has to be fixed... Anyway FSUIPC is really a great tool, and the more you know it the more you discover how poweful it is!

Hi John and Pete, I found in sioc manual that sioc can simulate a button action on one of FSUIPC virtual joystick. This way I could use the button of the MCP AP MASTER to do also a simulated button press for the VJ : Var 1 Link IOCARD_SW Input 116 Type I { &FO_JoyStick64 = CHANGEBIT 0 v1 // toggle bit 0 of joystick 64 } Var 2 name FO_JoyStick64 Link FSUIPC_OUT Offset $3340 Length 4 SO I could assign this button the action of setting the hdg slot to 1. That should work in theory... and this opens a lot of possibilities also! I'll try and report the result.

Thanks a lot John!!!! THAT WORKS! The control was set to FMC, capturing the current heading value. Setting the slot to 1 the control is passed to MCP heading value as set with the HDG knob. This is very good, and the same thing can be applied to altitude and speed. Now the ideal thing would be to send this control automatically when I push the AP button, is there some way I could send this command from sioc, when I press the AP button ? or maybe I could write some LUA code ? What do you suggest John ? I understand that this could be a problem when using the FMC. I wonder why they do this passage to the FMC if no flight plan whatsoever was set... To answer to Spokes2112 (thank you first of all) I agree with you that somewhere in cfg somewhat should be this setting, but the aircraft.cfg seems to be locked (".fsarchive) if you can find some other path to reach the autopilot configuration, I can't find it... As I said I checked many files under instruments, I also found the 787 FCU.js and other, but all attempts to modify those files didn't work.

I have found this possibly interesting post on MSFS forums : "There are no commands that are visible in control settings GUI. But you can control the FCU authority with these Sim Connect sim events; HEADING_SLOT_INDEX_SET SPEED_SLOT_INDEX_SET ALTITUDE_SLOT_INDEX_SET VS_SLOT_INDEX_SET Sending these with parameter 2 gives the authority to FCU, and sending with parameter 1 activates selected mode for each knob. You’ll need to use a 3rd party controller interface software that use sim connect; ....." Maybe that these "SLOT_INDEX" variables or controls set to 1 allow normal operations for the knobs of MCP ? I cannot send them directly to simconnect... never even tried to do this directly, only used FSUIPC.

Disaster.... (for me at least) 747 is completely different from B787, it uses other variables (and maybe other commands) for the autopilot, autothrottles, etc, so, given that 787 was almost partly controlled by old fsx AP variables and commands (left apart heading hold mode and vertical speed mode, level change mode, etc...), that means that the 747 has mostly custom new variables... I hoped that at least 2 Boeing airplanes could share the same Autopilot controls... but seems not to be the case. I just wonder, if no SDK updates will be released before october 2020, how will you be able to release the commercial version of FSUIPC if essential offsets won't work... For sure I will buy the license as soon as it will be available, but will it work for the autopilot variables used in default planes ? I am a MSFS 2020 enthusiast from day 1, no doubt about that, graphics level is awesome, but after some weeks I must have to agree with those who said that too many things were not ready for an offical release... hope that your creativity and strong technical skills will overcome somehow these problems, at least for essential part of the avionics as the FCU or MCP, EFIS and so on.

No way, nothing works. I tested probably all the available commands related to autopilot heading, but no one worked for the "Hold" function of the 787 panel. I was wrong when I said that the console recognizes the command sent when I press the center of the HDG knob in VC. When I press the HOLD button under the knob the console report the event "AP_HDG_HOLD_ON" and when I press the button on the OC MCP it displays "AP PANEL HEADING HOLD ON" or OFF, but nothing appears when I press the VC knob button, that is currently the only way to remove this sturdy and stubborn "HDG HOLD" function. I have explored the HTML code of the gauges under aircraft dir, there are many of them related to 787 or airliners or generic panels, but is difficult for me to understand where the heading hold control is activated in conjunction with AP master activation. I don't know if in the real 787 the AP master does this, but MS/Asobo could at least have provided a command configurable to switch this off from the keyboard. Probably is a new variable, maybe only on 787, and nothing can turn it off from outside the simulator itself. It's quite annoying for me. I've installed the last update patch today, but even so the problem still remain exactly as before. At least on XPlane 737 specific datarefs were listed on documents and I could interact with them just using the right syntax, here for the moment I can found nothing in the SDK.

Hi Pete, thanks, I'll try as soon as I get back home this evening. I was thinking only in terms of offsets since I can't remember if SIOC allows sending commands, I always see only offsets in the code. Years ago I wrote a lot of code with lua and fsuipc offsets, for all my cockpit, but I am no longer able to have luacom working so I have to leave my Pokeys and use Arduino instead. For the heading issue, do you mean that I can assign an action to the OC MCP button ? This is what I am trying to do, because otherwise I will have a fictional operation to do pressing a key on the keyboard or on the yoke just to be able to disengage this heading lock that wasn't present in fsx 737. Or can I associate an action in fsuipc triggered by a button in my MCP ? I don't think is possible... I will alse check if the same problem is present on the 747 autopilot.

Hi Thomas, thanks! I am a bit rusty about FSUIPC menus and controls (for the last 3-4 years I only used XPlane), so I apologize for not having checked this option before. This seems to be the solution, I can assign a key to this action and (if it works) deselect the AP HDG hold just after pressing the AP master button. The ideal thing would be to send this command automatically when I press the AP button, maybe through sioc or even a lua script or else... I'll try if the key assignment works, and at least I can avoid to go on VC mode and click a spot on the screen!

Ok essentially the question is: is there any way to send an AP_HDG_HOLD_OFF through FSUIPC ? I cant' find that, and apparently no configurable control is present in MSFS menu to assign a key combination in order to send this command, so at the moment no way to get rid of this unwanted AP_HDG_HOLD function that locks the operations of my MCP otherwise working well.

Sorry Pete, I repeated things you said in your answer. I will do some more testing tomorrow and I will report if I have any success...

Regarding the heading values, let's suppose that I set the heading to 230 degrees with my MCP knob, both the MCP and VC displays show "230". Good. The plane current heading is, let say, 200 degrees. I push the AP master button. On the VC, the "led" on the HDG button becomes green, and the plane starts follwing the 200 heading, but on the displays (on VC and on my MCP) I read 230, while the plane is holding 200. Only when I switch off the heading hold function pressing the VC knob, the plane starts aligning with 230° and then I can control the heading setting it with the HDG knob on AP.

Thanks a lot Pete, it's not easy for me to explain accurately the problem. I opened the console in order to see what happened when I pushed the HDG HOLD on the virtual cockpit. To set this on I push the button under the knob, and the "led" comes green (this happens automatically if I activate the AP master from my OC MCP master button). In this situation the plane hold the current heading, and I can do nothing from my MCP to change it, only for a split of a second when I turn the knob the plane turns but after that it goes back to previous heading. To turn it off the only thing I can do is to press the button on top of the VC heading knob, and then everyting on my MCP work fine. So, having the console opened, I selected "events" and I can see the rows showing the operations carried out, eg. "AP HDG HOLD" and - on the left - other numbers that I can't identify for what they are (sorry - I surely missed some part of the instructions for the console). The only thing that I find significant is that pressing the button on the VC the events are different from those coming out when I press the button on the MCP; the offsets in the sioc code are those well documented for the autopilot, and they work perfectly, but ONLY if the VC heading hold is turned off (and this can be done only from the VC, and I need something to avoid this). I remember from FSX that there were 2 set of controls KEY_AP_HDG_HOLD_ON AP_HDG_HOLD_ON Turns heading hold mode on Shared Cockpit and KEY_AP_PANEL_HEADING_ON AP_PANEL_HEADING_ON Turns heading mode on (without capturing current heading) Shared Cockpit KEY_AP_PANEL_HEADING_OFF AP_PANEL_HEADING_OFF Turns heading mode off Shared Cockpit KEY_AP_PANEL_HEADING_SET AP_PANEL_HEADING_SET Set heading mode on/off (1,0) Shared Cockpit To what I understand is that the VC button sends the first command (locking the current heading until I turn it off whatever else I did) and the OC MCP via sioc and the offsets you reported (07C8, 07CC) send the second kind of commands (with "_PANEL_") that work only if the hold mode is previously disengaged. Tomorrow (now is very late) I will try to capture some screenshots with the row displayed on the console. Thanks again for your help.

I have Opencockpits modules and thanks to FSUIPC 7 and good old sioc code for FSX the autopilot and the radio are wokring almost at 90%. EFIS works but not with the 787 VC glass gauges. Unfortunately I can't solve this issue with B787 autopilot: when I press the AP master button, the 787 autopilot engages the Heading hold mode and I can't find any offset corresponding to this command. Checking the log file I see that while the OC autopilot is changing a variable named "AP panel heading hold", while the command that is sent clicking on the virtual cockpit MCP is "AP HDG hold" (sorry probably the real var names could be slightly different, but the one sent by the phisical MCP is the 07C8, while pressing the heading knob in VC panel this offset is not changed. I can't find no other offsets for HDG hold or heading lock or else. I don't know how to detect the offset required bu this control, the number appairing on the console when I push that button seems not to be offsets. I would really appreciate if someone could tell me how to change this value without having to click on a VC knob, given that the console detect this action as a recognized variable and not a custom 787 value, so I hope it would be possible to change the value of some offset to obtain this command. With heading hold active even if I press my MCP HDG button nothing happens and also rotating the HDG knob has only a momentary effect but then the plane returns on the previous heading (and this value is different from the value displayed in my MPC and also in the VC MPC display - both these values are related to the offset 07CC that changes according to the knob movements but the AP holds the initial heading ignoring this value). Once I turn off the heading hold function by pressing the center of the knob in VC, the OC MCP controls (HDG lock button and led and HDG value knob and display) work perfectly. Thanks for your help!

I must apologize for the title I chose for my topic... yes you were right, it is not the lua code that stops working, but the connection with the pokeys, in fact the ipc.display("AP ON") came out when I pressed the Z key after I lost the control of the panel. So the lua was running but it could not read or write the pokeys pin status. I considered that pressing the "O" key the code (now I know was a new instance of the code) started and the connection was still alive but probably that happened because the command poKeys:ConnectToNetworkDevice("192.168.0.12") was sent once again and that restarted the device connection. I will study a way to check periodically the connection, and send an ipc.display warning when it is lost, or try to reconnect it. I don't think is a network issue, probably could be a sort of stack overflow, maybe a queue that is filled with data, perhaps because I send more status change commands than needed (I should send only one when the status change, but I don't do this at moment, I simply read the fsx var with event.timer(50,"update_switches") and if the fsx variable o switch is 1 I send a 1 state to the corresponding pin, and this could not be the right thing to do. At least now I have a new target for my debugging.... Thanks Pete for your support.

Hi Pete, I'm so happy to read your replay! Thank you very much. Yes I considered the possibility that the net could have lost the connection to the pokeys for some time, and so the code was no longer communicating with the device. In order to find out if the code is still working I can write some ipc.display commands reporting fsx status changes (maybe gear down or flaps out etc). If I see the message it is clear that the code is running but it lost the connection. I will test this immediately, if you agree that it is a valid test. I already set a key (the "O" key for overhead) and pressing it it run the overhead.lua and everything start working again. This solves the problem, but is not very good to lower the landing gear and discover that nothing happens, then press the "O" key and so on... Here is the initial part of the code (please let me know if you want me to encolose all the code) require "luacom" poKeys = luacom.CreateObject("poKeysDevice_DLL.poKeysDevice") if poKeys == nil then ipc.log("Error: poKeysDevice_DLL object creation failed.") ipc.display("NO POKEYS - QUIT PROGRAM") ipc.exit() end -- LEDS (digital outputs) fuel_p1_FWD_lowpress = false -- pin 1 fuel_p2_AFT_lowpress = false -- pin 2 ......... -- SWITCHES (digital inputs) yaw_damper_ON = false -- pin 33 starter1 = 0 starter2 = 0 master_battery = false -- pin 42 power_ON = false ........ function connect_to_poKeys() result = poKeys:ConnectToNetworkDevice("192.168.0.12") if (result == false) then ipc.log("Error: Connection to poKeys56E at 192.168.0.12 failed.") ipc.exit() end end ....... This is how it is documented for pokeys device and it works, until it stops! I will test the ipc.display trick, I should be able to see if the code is still reading the fsx vars but not the pokeys status. This probably would move the problem onto the pokeys.dll plugin. I will report the test results as soon as I complete the test! Thanks again Massimo

Hi all I'm a long-term Pete Dowson admirer and user of his wonderful program, I know is needless to say after all this time, but FSUIPC and the integration with LUA is simply extraordinary. I am building a home cockpit and I chose the Pokeys board for my MIP (ethernet), throttles (USB) and recently also overhead (ethernet version). With LUA and IPC controls and pokeys.dll I managed to have a great deal of systems working with default B737/800 so I'm very happy with that, and this site helped me a lot to find examples and solutions for almos every problem. Also Pete's documentation was so good and clear, even though I had to overload my poor brain to get started at the beginning. Now I decided to post a message because I cannot really solve this issue by myself. My code, launched by ipcready as documented, works perfectly, no errors, all running smoothly. Randomly though, I realize that the code has stopped working because there is no reaction to variables change or switches changes etc. I see the log file and there is no message of any kind regarding errors or other issues. Is there a way to understand what problem is causing the code to stop, or to trace the errors in a deeper log? It happens both with the MIP code and with the OVERHEAD code (based on ethernet pokeys) but never with the throttles (USB pokeys) but the net is stable, I changed switches, cables, etc, but all other net devices seem to work. Can someone (hopefully Pete!) help me ? Best regards Massimo