AlMassimo

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