AlMassimo

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.

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...

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

Yes they are for FBW A320 (or "A32NX") that has different controls for left and right seat switches. Most of FBW variables are "A32NX_something" but probably the first added were still "A320_something" and this causes some confusion, since they are difficult to distinguish from default A320 variables. It could be a good thing to have different hvar files for A320 and FBW A32NX.

Ok very interesting. I fixed the Hvar issue following your indications 1) updated with lates beta 3.9 2) added to A320.hvar under "modules" folder these 2 lines : H:A320_Neo_MFD_BTN_ARPT H:A320_Neo_PFD_BTN_LS And now also ipc.activateHvar works perfectly.

Thanks John, I agree, using calculator code in lua is an extremely powerful and useful option, so probably I won't use activateHvars, that initially seemed more straightforward and easy, but in the end calculator code is probably the most effective tool and can do almost everything! Best regards Massimo

Hi John, I use LUA for managing LVARS and all works very well. Since I use OpenCockpits MCP and EFIS, I have to use some offsets ("A001, A002, A003...") to allow LUA to detect OC buttons or knobs, and then it sets the LVARS properly. So this code works perfectly (with default Asobo A320 neo) : function MFD_RANGE_SET() MFD_range = ipc.readUB(0xA001) ipc.writeLvar("L:A320_Neo_MFD_Range", MFD_range) end event.offset("A001","UB", "MFD_RANGE_SET") When offset A001 changes (controlled by my O.C. EFIS range knob, the Lvar is set correctly. I tried to handle also HVARS : function PFD_ILS_MODE() ILS_BTN = ipc.readUB(0xA004) if ILS_BTN == 1 then ipc.activateHvar("H:A320_Neo_PFD_BTN_LS") end end event.offset("A004","UB", "PFD_ILS_MODE") This DOESN'T WORK, but if I replace the activateHvar with calculator code, it works perfectly function PFD_ILS_MODE() ILS_BTN = ipc.readUB(0xA004) if ILS_BTN == 1 then ipc.execCalcCode("(>H:A320_Neo_PFD_BTN_LS)") end end event.offset("A004","UB", "PFD_ILS_MODE") What I am doing wrong with ipc.activateHvar ? No problems for me to use calculator code, but I would like to understand why ipc.activateHvar doesn't work. The same happens with other Hvars, all work in calculator code but not in ipc.activateHvar. Maybe that this happens because I can't find those Hvars under wasm --> list Hvars, but the calculator code finds them. How can I add them to FSUIPC ?

Hello Jose, time ago I considered buying that panel (but then I didn't); it doesn't seem to be compatible with MSFS (you don't specify if you use MSFS but since you are posting on FSUIPC7 forum I suppose so). Anyway have you seen this video ? https://www.youtube.com/watch?v=5M2YrVHU2ew It seems to be quite comprehensive and step by step guide on how to configure your device. (but probably you want to use it as a "joystick" device I think)

WOW this is something I have to try!!! THANKS this IS the best way IMO! I'm sorry I didn't figure it out before...

ANYWAY (and I wont bother you any longer on this subject) since a simple list Lvars solve everything, it appears to me that Fsuip CAN do something to update Lvars created much too later to solve the problem by increasing lvar scan delay... to what, 120 secs ? No way, at least for me, I'll do a list Lvars and all works. Bye John

Ok sorry I thought it was an interesting issue, but of course it's not for all, for me all this was very instructive though. best regards ant thanks for your time

I found this on log : 153141 3692 *** EVENT: Cntrl= 66984 (0x000105a8), Param= 0 (0x00000000) COM3_VOLUME_SET 153454 3692 *** EVENT: Cntrl= 67230 (0x0001069e), Param= 1 (0x00000001) AP_MANAGED_SPEED_IN_MACH_OFF 154047 3692 *** EVENT: Cntrl= 67230 (0x0001069e), Param= 1 (0x00000001) AP_MANAGED_SPEED_IN_MACH_OFF 154141 3984 **** Lvar 'FLIGHTPLAN_APPROACH_COURSE' not found: cannot add to offset 0xA022 154157 3692 *** EVENT: Cntrl= 66964 (0x00010594), Param= 1 (0x00000001) COM1_RECEIVE_SELECT 154157 3692 *** EVENT: Cntrl= 66965 (0x00010595), Param= 0 (0x00000000) COM2_RECEIVE_SELECT 154157 3692 *** EVENT: Cntrl= 66966 (0x00010596), Param= 0 (0x00000000) COM3_RECEIVE_SELECT 154157 3692 *** EVENT: Cntrl= 66978 (0x000105a2), Param= 100 (0x00000064) COM1_VOLUME_SET 154157 3692 *** EVENT: Cntrl= 66981 (0x000105a5), Param= 0 (0x00000000) COM2_VOLUME_SET 154157 3692 *** EVENT: Cntrl= 66984 (0x000105a8), Param= 0 (0x00000000) COM3_VOLUME_SET 154204 3984 Lvars/Hvars received - checking aircraft autos.... 154204 11212 LUA.1: beginning "D:\FSTools\FSUIPC7\ipcReady.lua" 154344 3692 *** EVENT: Cntrl= 67251 (0x000106b3), Param= 10 (0x0000000a) NAV1_RADIO_SET_HZ 154454 3692 *** EVENT: Cntrl= 65708 (0x000100ac), Param= 2048 (0x00000800) NAV1_RADIO_SET 154547 3692 *** EVENT: Cntrl= 67230 (0x0001069e), Param= 1 (0x00000001) AP_MANAGED_SPEED_IN_MACH_OFF The messge appears ONLY for COURSE not for ILS, so it was not loaded at all in fsuipc.ini I tried with wasm reload when Lvar was correctly listed but still it was not loaded on offset A024

Uselessly stubborn I must say... Did not work of course... weird that the frequency is updated, but the course not, only after list Lvars... well, I'll do a list Lvars just after setting the flight plan, not a big deal, but still weird for me.

Done, wasm scan delay increased to 50, this takes a LOT of time before being able to control MDF display (before it was just after 25 secs and always worked, both MDF MODE and MFD RANGE. But this is not a big problem. The problem is that this time ILS frequency was correctly read and set by LUA and displayed on radio panel BUT COURSE DID NOT. I checked in console and lua did not detect any event connected to ILS COURSE. Even this time, hitting list LVARS, immediately it was read and displayed... I think it would be great to do some LVARS rescan, let say once every 10 seconds, or even more, just to be sure to intercept also LVARS created during flight, as ILS frequency and course (they are not even listed before creating a plan with an ILS approach). Just because I'm a little stubborn (or very stubborn) I'll try again to define these 2 lvars in Fsuipc7.ini and see if they worked again as they did yesterday, regardless of was scan delay or list Lvars command...

Ok I've seen your reply, I have currently 25, I can increase to 50 but after 25 many Lvars are read (and work) but when I do the first list Lvars they still apear 0 and change only on second list Lvars

Hi John, apparently there is some issue in updating Lvars, that is solved only with a list Lvars. Until I click on list Lvars (some) Lvars are not updated or not read at all. I mean some because these [LvarOffsets] 1=A320_Neo_MFD_NAV_MODE=UBA000 2=A320_Neo_MFD_Range=UBA001 4=BTN_TERRONND_ACTIVE=UBA005 are read correctly and they control the MFD display just after some seconds of delay from flight start (as set in wasm.ini) other do not

Here is the lua code if you want to have a look at it function ILS_freq_set() ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 + 0.001 ipc.control(67251, ILS_freq * 10000) end function ILS_course_set() ILS_course = ipc.readLvar("FLIGHTPLAN_APPROACH_COURSE") + 0.001 ipc.control(65716, ILS_course) end event.Lvar("FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set") event.Lvar("FLIGHTPLAN_APPROACH_COURSE", 500, "ILS_course_set")

Hi John, I tested the lua code and obtained some apparently incoherent results. At first, having removed the Lvar assignment in Fsuipc7.ini, loaded the flight, configured the airplane for takeoff, then set the CDU for ILS approach and the event was triggered, and the ILS frequency was detected and transferred to NAV1 active frequency 0x0350, and this caused SIOC to immediately update the display on the NAV1 panel. I was encouraged to add other code to my lua program in order to get also the ILS course value. Also this worked fine. I was confused. Then I made another fly, same settings, but this time the frequency was not updated. I went to Fsuipc wasm menu and selected list lvars. ILS frequency was 0 and all other Lvars were still 0. But in the same instant when I selected list Lvars suddendly the NAV1 display showed the ILS frequency! I hit list Lvars again and this time all Lvars showed their values. Very strange they were still 0 the first time, because the plane was loaded many minutes before, so all Lvars should have been loaded by then. I enclose the Fsuipc.log file, so you can analyze and check what was wrong. FSUIPC7.log

Ok sure I'll do that this evening.

Thanks a lot John, your answers are always very instructive and detailed. I think it's all clear for me now. I think I am now able to solve 99% of the things I needed to make my radios working again with MSFS 2020. Most things are now already working, at least for Asobo A320 for the moment, by a mix of Fsuipc, Lua and SIOC, maybe it's a little bit more complicated than what could be, but it's working. Now I'll try to extend the study to FBW A320 and B747 etc. Seems weird but I removed again the custom offset assignment in Fsuipc7.ini and again Lua script seemed to ignore the variation in L:FLIGHTPLAN_APPROACH_ILS, while the same Lvar, read through the custom offset it works... I get no errors in log file, I will try to increase the logging level as you suggested. For sure Lua reads the Lvar, since it transfers it properly to 0xA020 offset as an integer as said before, but apparently the event.Lvar seems not to react to changes in Lvar! event.Lvar("L:FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set") is this correct ? (I followed the manual). 500 should mean 2 times per second. "L:" should be optional, but I don't understand exactly what you mean in the manual about the difference in declaring with or without "L:". The event with offset doesn't require an interval. As soon as I activate the ILS approach on CDU, the offset trigger the event and the Lvar is read and converted to integer, and I see the frequency on the NAV panel. Using event.Lvar (the only modification I do to the code) no action is triggered when I activate the ILS approach, unless I call it after having assigned the Lvar to an offset, even if I don't use that offset at all! It only seems to make the event.Lvar function to work... I'll do more testing with event.Lvar and other Lvars not assigned to any offset and see if they work.

Well, let me try to explain my statement. Let say you have a frequency of 115.30 (VOR of Tessera Venice). Removed the first (static, so unsignificant) 1, you have 15.30 or 1530 as a 4 digits number. The BCD value (binary) would be : 1 5 3 0 = 0001 0101 0011 0000 that is stored in a 2 bytes offset 0x0350. When I read it I get 5424. What is this ? I didn't know how to use it for my display. But after I read the post you enclosed, I discovered that is the decimal conversion of the hex number 1530 (binary 0001010100110000). So from what I can say, if the frequencies displayed on the radio panel (115.30) are regarded to as a HEX number (and not a decimal number as I always considered) removing the first 1 you obtain the hex 1530 that (in my opinion) is stored in 0x0350, and if I read it in SIOC (as a decimal as normally is done with all the offsets) I get 5424, that now has a precise meaning. Anyway I'm not at all an expert of BCD format, so I don't insist on my theory... On the other hand I'm still dealing with the float conversion, that is done automatically in lua when I assign the float value to a SW offset : ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 ipc.writeSW(0XA020, ILS_freq) In 0xA20 I read 10994 that means that FSUIPC got the float values from the LVar, but then stored is as an integer (word) value. If I did not multiply by 100 I would have obtained 109, that is the int part of the float number. This gave me the idea that is possible to use the assignment to a SW offset to obtain a number usable in SIOC, as a sort of conversion from float to integer. I only would like to know how you deal with float variables in FSUIPC, because I remember something like they are multiplied by 65536 x 65536 or something, so they are not stored as a "floating point" value, but can be easily read and converted to the exact value to be used in other applications (like SIOC). Maybe is not the case for this Lvar, or maybe I'm totally wrong about floating points variables in Fsuipc offsets (very very likely so).

This clarify me that the conversion from BCD to decimal value is simply a conversion from hex to decimal... I didn't know that. The vale for a frequency of 108.00 MHz is returned as 2048 from the offset 0x0350. The Hex value corrisponding to 2048 is.... 800! That means, adding 10.000 (because the first 1 is implicit) = 10800. So now I know how to deal with BCD numbers (if I understood correctly), but anyway in SIOC I found the function FROMBCD that solved the problem, I'll do more testing to check if it correspond to hex conversion, seems weird.

Thanks, it's very useful! Regarding my solution, when I removed the offset assignment in Fsuipc7.ini, the lua event stopped working. When I restored the assignment 5=FLIGHTPLAN_APPROACH_ILS=FA014 the lua function event.Lvar("L:FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set") restarted working. It looks strange to me because in lua code I don't use offset A014, but now the Lvar is recognized, otherwise not. Is this the normal behaviour of Lvars in lua ? Or it depends from the fact that the Lvar is created AFTER launching lua ? Anyway, it works! I just would like to know if is there some way to use float variables 32 bit in SIOC, lua seems to have no problems in handling them...

And this is the lua code that worked without need for custom offsets... It took me a smoking brain, but seems to work function ILS_freq_set() ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 + 0.001 ipc.control(67251, ILS_freq * 10000) end event.Lvar("FLIGHTPLAN_APPROACH_ILS", 100, "ILS_freq_set") control 67251 sets NAV1 frequency in hertz !

Yes, I'm a little bit into confusion, if I could read directly the float value in SIOC I could avoid the lua code. I could also use the function event.Lvar("lvarname", interval, "function-name") so it would be event.Lvar("FLIGHTPLAN_APPROACH_ILS", 100, "ILS_freq_set") if I then could assign directly the value to A:NAV ACTIVE FREQUENCY:1 all would be solved. But I find it hard to understand how to do that. Let suppose I have "ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 + 0.001" = 10995, how should I feed this to A:NAV ACTIVE FREQUENCY:1 in lua ? I imagine the only way is this : ipc.writeUW(0X0350, ILS_freq) but on offset 0350 you write : NAV1 frequency, 4 digits in BCD format. A frequency of 113.45 is represented by 0x1345. The leading 1 is assumed. To remove the first 1 I could do this : ILS_freq = ILS_freq / 10000 ILS_freq = (ILS_freq - math.floor(ILS_freq)) * 10000 This gives 995. So I should assign 995 to offset 0350 ? But this is not in BCD format... Do I have to convert it to BCD ? I think there should be an easier way but I cannot see it...