AlMassimo

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

WOW it works! As soon as ILS approach is activated, on A014 I read an uncomprehensible (for me) number, but on A020 I read 10994 (should be 109.95...) I see on MF that the frequency is 109.949999, I must round up the number in LUA. Now I want to transfer this on 0X0350 offset, and I can do that in SIOC.

I am trying to test this code function ILS_freq_set() ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 ipc.writeSW(0XA020, ILS_freq) end event.offset(0xA014, "FLT", "ILS_freq_set")

Hi John, after a lot of trial and errors I was finally able to get my OpenCockpits NAV radios to work using offsets 0350 and 311E for active and standby frequencies in BCD format. Now my NAV1 radio is working pretty well for VOR navigation. Using Asobo A320 I discovered that it doesn't use NAV1 active frequency for the ILS approach. It uses the L var (L:FLIGHTPLAN_APPROACH_ILS) that is unset until the ILS approach is activated on the CDU. But this frequency is not set on the 0350 offset (that should be the active NAV1 frequency). I could use it (I assigned it a custom offset in FSUIPC7.ini and in SIOC I can read it) but it's a 32 bit FLOAT number, and I don't know how to deal with it. I would like to see this frequency on my radio display, by setting NAV1 active frequency = FLIGHTPLAN_APPROACH_ILS, but I have to convert it from FLOAT to integer (and then to BCD to store it in 0x0350 offset, but this is easy in SIOC with TOBCD function). Have you any suggestion on how could I use and convert the FLOAT value ? Maybe that I can read it in LUA and then convert it in integer and store in a custom offset, or directly into A:NAV1_ACTIVE_FREQUENCY. I'll try this way, don't know if LUA gives an error trying to read an Lvar that is not yet created by the simulator (unless I set an ILS approach this LVAR is not listed in LVARs window...)

Hi John, Fsuipc7 3.4 is working fine after I reinstalled it having deleted the .ini file (as I said I haven't saved a copy of the .ini file modified by the first installation of 3.4 Deleting .ini and reinstalling 3.4 solved the problem. WOW this is something I really think will be useful, didn't know about that, I'll try ASAP. To create an Lvar I define it in the ini file ? eg [LvarOffsets] 1=AM_testLvar01=UBA000 and then I can use it in calculator code ? That would be great.

The different versions of fsuipc7.ini I created differ almost only for the "[LvarOffsets]" section, since I'm using myevents.txt also for hvars, instead of using .evt files. With myevents.txt I can use all kind of variables and controls, so it is more powerful, the only limitation seems to be that I cannot assign values to offsets as calculator code (AFAIK), so when I have to do that I use SIOC code instead and LVARS declaration in fsuipc7.ini

Yes John, I rename events.txt to events.tx0 in order to have myevents.txt with all and only the required events. and easy numbering, this works fine for me. I use events.txt only for finding the useful code, then I transfer it to myevents.txt (specific for each different plane). I created a folder for every plane, with : FSUIPC.ini, SIOC_ACTIVE.txt, MF_active.mcc, myevents.txt, planexx.lua, ipcready.lua. When I decide to use that plane I just copy the specific files in their normal folders and all the cockpit is reconfigured for that plane. I enclose the FSUIPC7.ini I had before installing the new release. I could copy it again and repeat the test with the new release. The strange is that FSUIPC7 just stopped after loading the events files (at least according to .log file) but maybe some of the files were not present in the folder at the moment, without giving any message. Unfortunately I didn't save the complete .ini file that did not work, but the first part seemed totally normal to me. FSUIPC7.ini

Hi mtjoeng your hint worked, now FSUIPC7 3.4 woks fine, tank you, I owe you a beer 😉 Now finally also the triple-Alt-F issue is solved, the interface opens up just hitting Alt-F once, as it was before. Apparently Fsuipc7.ini seems identical to the previous one, but surely there is some difference somewhere, I'll check the 2 files more deeply. THANKS

Ok thanks I'll try without ini

Hi John, I saw that was available a new release of Fsuipc 7 so I hurried up installing it, but the program icon shows up a bit in the program bar in W10, then after some seconds (maybe 20-30 secs) it disappears and the program is no longer running. I tried to launch it from the installation folder (without MSFS running) and it does exactly the same. The log file is very short and ends just after 141 Preset file 'D:\FSTools\FSUIPC7\events.txt' not found [info only] 141 2 Calculator Code presets loaded No warning or error messages, all seems Ok (same rows as in the previous log working). I installed the 18 april version and it runs perfectly as before, no issue at all. I am going on with the previous release, just want to report this strange behaviour of new release on my PC...!

Thanks John, I tested 1070 control and it worked perfectly, this simplifies the code, I don't need a custom offset and lua code, it is very straightforward. var 0248, name I_SPEED, Link IOCARD_SW, Input 31 { IF &I_SPEED = 1 { &FS_PAR = 4178 // Alt+R = (alt)16*256 + 82(R) &FS_CONTROL = 1070 // send keypress &FS_CONTROL = DELAY 0 10 } } And this should work for every custom plane I think. I also found the B747-8.hvar file in Fsuipc7 folder and copied it to Fsuipc\Wasm folder.

Wow I couldn't remember about 1070-1072 or 3200, they look very interesting! Thanks for the advices, I'll study and test them. In the meanwhile I solved the issue with a very simple lua code : In SIOC I set the offset 0xA006 to 1 when the SPEED HOLD button is pressed on MPC, then lua detects the change and send Alt-R to MSFS function AP_speed() if ipc.readUB(0xA006) == 1 then ipc.keypress(82, 16) end end event.offset(0xA006, "UB", "AP_speed") This works pretty well, and at last I succeeded in managing AP SPEED HOLD. Looking on the console the MSFS command sends 3 controls, I tried to replicate them in an event under myevent.txt AM_B747_SPD_HOLD#0 (>K:AP_AIRSPSPEED_HOLD) 1 (>K:AP_MANAGED_SPEED_IN_MACH_OFF) 1 (>K:SPEED_SLOT_INDEX_SET) but for some reason this seems not to work. I can't see the command being sent in the console, and I don't get the expected effect in the simulator. I can't find an error in my custom event, but maybe is uncorrect. I would prefer to control the events with this "calculator code" instead of sending keypresses, it makes me feel more "in control" of what I am doing. But on the other hand, sending keypresses leave the "dirty work" to MSFS, and should work with different planes, so I probably will go on with this solution, either in lua or with 1070 or 3200 offsets (or controls ?). 1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk) To what I understand I should use 3110 and 3114 offsets to send the control and parameter Var 0001 name FS_CONTROL Link FSUIPC_OUT Offset $3110 Length 4 Var 0002 name FS_PAR Link FSUIPC_OUT Offset $3114 Length 4 and then use 1070 as control number and (e.g. for Alt-R 82 + 256 * 16 = 4178) as parameter, is this correct ? I'll try this in SIOC.

Probably I could do that in lua, using ipc.keypress(keycode) - that means, when a custom offset is changed by SIOC, then lua sends an ipc.keypress. If the keypress works in MSFS I should obtain the same effect, bypassing the unaccessible variables or events. I'll do some test and report the results, I think this could be interesting (maybe even obvious for some expert builders !)

Just to eliminate a doubt, I tested Alt-F without SpaceDesk and the secondary monitor, and nothing changed. It is strange but I'm pretty sure that with the previous release of Fsuipc the window came up at first Alt-F on the keyboard. Difficult to understand why the first window doesn't stay on top and the third one does, but after all it is not a big issue, just a little bit annoying 😉 Much more interesting would be to have the window always in front as the console. I also confirm that there is no B747-8.hvar file under wasm dir, even if B-747 does use hvars, but I cannot find a list of those hvars anywhere. Besides, unfortunately, exploring behaviours under SDK window, I found that B737 is using some B and O vars that cannot be read or modified, and Asobo seems to ignore all requests to even consider making them accessible, what a pity for home-cockpit builders. Today I will do some testing with MSFS keyboard controls, in order to see if they activate correctly the MCP functions on B747. If so, I could assign a keyboard shortcut to Fsuipc actions and that should work (pressing a button I should obtain the MSFS action corresponding to that shortcut). My problem though is that I have to send the shortcut via SIOC, because I can only use SIOC for my MCP. I don't know how to associate a custom offset or a control to make Fsuipc send a keypress...

Absolutely great! Thanks Got it. As I said I am currently working with hvars, no problem, just couldn't understand why suddendly I could not see the havars list any more. Now is clear, thanks.

Hi thanks John, I now understand a little better what could happen and why the 2nd Alt-F seems to do nothing (it hides the window) and then the 3rd makes the window to open and stay. The first Alt-F maybe is not working because I'm currently using SpaceDesk for displaying the gauges on a secondary PC. I'll try Alt-F without spacedesk and see if it works as before. Hvars : I'll check the files. No problems for the functionality, I'm fully using myevents.txt and all works fine, I just can't see the hvars available on the panel, but they are correctly used by the program (I use SIOC and call the events as explained in advanced users guide, and some events use hvars and work perfectly). Most likely I don't have the proper .hvar file for B747-8, I'll check that. Yes indeed, I was thinking the same thing! Console window stays on top and allow to see the effects when I click some control on the VC. A big big goal could be to update lvars values automatically (without selecting list lvars again) to monitor value changes performing some action, as happens under developer mode in MSFS. This can also be done in MobiFlight assigning a variable to an output and in the interface I can see the value changing (eg. an analog value changes continuously). I know this can be done using the console log, but many times the rows scroll up so quickly that is difficult to see what happens.