John Dowson

Glad its now working. Yes, using event.com is much more efficient. That is probably a better long-term solution, as you are already writing your own code to drive the LCD. Via the SDK, you can either write the COM1 standby frequency (in Hz) to offset 0x05CC (as a 4-byte int), or you can use offset 0x3110 which operates a facility to send any control to the FS. Cheers, John

Your log files are very interesting... They show the lvar names correctly in the initial scan, when 134 lvars are detected, but (97 seconds) later 137 lvars are detected and two of the lvar names have been corrupted. This corruption looks to be in the WASM, so I am surprised when you say that 'MSFS Disconnect / MSFS Reconnect from FSUIPC menu often solves the issue'. However, to confirm this, I would need to see an FSUIPC_WASM.log with Trace logging activated. It is strange that the following 3 lvars are created such a long time after aircraft load: 77391 [TRACE]: LVAR Data: name='FSDT_VAR_Frozen' 77391 [TRACE]: LVAR Data: name='B738_EmergencyDoors' 77391 [TRACE]: LVAR Data: name='Prosim738_Steering' There is a known issue with scanning for lvars that can cause the FSUIPC WASM module to crash. See It looks like you are getting a similar issue, but rather than a WASM crash you are getting a memory corruption somewhere. To prevent this, try tuning your WASM ini parameters. You currently have these set: Try with: LvarScanFrequency=-30 LvarScanDelay=10 LvarScanPeriod=-4 If you still get issues, and if not using those 3 additional lvars (mentioned above) directly (you can still use them via presets/calculator code), you could disable continual lvar scanning by setting: LvarScanFrequency=0 There seems to be something un MSFS that is corrupting the lvar name space, which I reported to MSFS a while ago but have yet to receive a response. I have ran the FSUIPC WASM in a debugger for days at a time and have not seen any corruption in the WASM itself, so this seems to be an MSFS issue... John

Also, from the User Manual: So throttle should stay at full, and you need to send a throttle cut to release the idle stop ring to come out of idle. What type/style of axis is your z-axis? Is it a twist-style axis, fixed or spring-loaded, or a lever style axis? How you would assign for this depends on this - if it is a spring-loaded twist axis (which for airplanes you would normally assign to rudder and maybe steering tiller) then you would not want to assign this to an axis control (left-hand side of axis assignment) as this would mean you would have to hold it in maximum position. But re-reading this thread, you did say that assigning to Helicopter Throttle Set didn't work (did you try Helicopter Throttle1 Set ?), and you have now assigned this in MSFS. Is this still the case? If assigned in MSFS, you should remove the axis assignment in FSUIPC. I am confused now as to what you have working, and what you still want to assign. Can you let me know what is assigned in MSFS, what you are trying to achieve, and attach your current FSUIPC7.ini file.

And if you go back to using the renamed ini, do you get the issue again? Also, delete this entry, as it doesn't make much sense: This entry is also strange: (due to the large range specified): And why are you assigning to the Throttle control if this doesn't work: ? Are you sure that this is your axis range? According to your calibration, it is -16197 to 15378. That dies NOT show the value range if the input event - it shows that he throttle is using the standard control Helicopter Throttle1 Set. Why don't you just assign your axis to this control? What do you mean by this? And why would you want to do this? What is the range of that input event? Do you see it change when logging Input Events (Log -> Input Events) and if so what is the range? Also, when you make any changes, please attach your updated FSUIPC7.ini. Sorry, but the more you post the more confused I am on what you are actually trying to achieve. According to the Cowansim documentation, you just need to map the throttle axis (on left-hand side of axis assignment panel) to Helicopter Throttle1 Set (or maybe Helicopter Throttle Set, Axis Helicopter Throttle Set or Axis Helicopter1 Throttle Set ) and the Idle Stop Ring to Throttle Cut. I am not sure what an 'Idle Stop Ring' is, but if you want to send this to cut the throttle on the same axis, map this to be sent when entering a range in the right-hand side of the axis assignment panel.

But previously you said that MSFS crashed... Does this happen with any axis now? What about buttons? Can you also try with a default aircraft? That won't do anything... Try rebooting your PC, and first check in a default / Asobo aircraft. If you get the same issue, exit/kill FSUIPC, then rename your FSUIPC7.ini file and try again - you will lose all your assignments/settings, but we can add them back later, If that fixes your issue, show me / attach your renamed FSUIPC7.ini file and try with the cowansim. Not sure what is happening - I have never heard of an issue like this before....

120.800 is in MHz, not KHz, so multiply by 1000000 not 1000 here: local frequency = tonumber(datastring:sub(8)) * 1000000 -- Extract frequency and convert to Hz

This is not correct - the documentation states: str, n = com.read(handle,max,min) so your call will always return a null string until at least 100 characters are read, Please see the documentation on com.read (see below) - you need something like (with no minimum): function processInput() local datastring, length = com.read(dev, 256) -- Read up to 256 bytes from the serial port if length then ipc.display("Data received: " .. datastring, 2) -- Display the received data for debugging ipc.log("Data received: '" .. datastring .. "' [" .. length .. "]") -- log to file -- Example of parsing the received string to set COM1 standby frequency if datastring:match("^COM1SB") then local frequency = tonumber(datastring:sub(8)) * 1000 -- Extract frequency and convert to Hz ipc.control(67363, frequency) -- COM1_STBY_RADIO_HZ_SET ipc.display("COM1 standby frequency set to: " .. frequency, 3) ipc.log("COM1 standby frequency set to: " .. frequency) -- log to file end end end John str, n = com.read(handle,max) str, n = com.read(handle,max,min) str, n = com.read(handle,max,min, term) Reads up to 'max' bytes from the port, returning them as a string in 'str' with the number actually read returned in 'n'. If the 'min' parameter is also given, this returns a null string and n=0 until at least that minimum number of bytes are available. It does not block waiting for them. If you specify -1 as the minimum then the terminating character ('term') must be seen before the function returns a non-zero result, unless of course the 'max' size is reached first. The 'term' parameter specifies an ASCII value (0 to 255) which is to be treated as a terminator for each block. This character is included in the returned count and string. Note that you can use the event library function, event.com to perform reads and call your Lua back when there is data to process. This can be more efficient and tidier than a program which uses continuous loops to scan the input.

That is very strange! Did anything change to cause this? It does look like a memory corruption issue, which is very strange, and also seems to occur when FSUIPC is started, Ok, then that would seem to indicate that this is on the client side (WAPI) rather than in the WASM, Not sure at the moment. Could you set Debug level logging in the WAPI (Log->WAPI->Debug) and show me/attach another log file. As it seems to happen straight away, you could even set Trace level logging in the WAPI. Can you also set Debug level logging in the WASM (via the FSUIPC_WASM.ini - see Advanced User manual for details on where this is) and also include/attach your FSUIPC_WASM.log file. John

Ok, thanks for the update. That is a template used in the model, i.e. in the aircraft itself. I have no experience or knowledge in model/gauge programming and wouldn't know where to start with this...so yes, a long learning curve indeed!

I also am not sure that you can specify the units for an lvar like this: (L:var_cabinPressurizationAltitude, FT) That syntax is for simvars, which have units specified (and documented). I have never seen this used before with lvars.... John

That doesn't sound like a small issue! Is this a new issue? You haven't mentioned this before.... Are you sure FSUIPC is crashing? If MSFS CTDs, then FSUIPC detects that MSFS is no longer available and will exit. Check your FSUIPC7.log file - it should show FSUIPC exiting normally.

The same device connected to a different computer will almost certainly be assigned a different GUID. GUIDs are allocated by windows. You cannot change this by editing the registry. You should use letters. Using numbers/JoyIds has further issues as joyIds can easily change and is more cumbersome to compensate for. If you use letters and the GUID of a device changes, the fix is simple: - copy the GUID from the new letter assigned to the old letter - delete the new letter assigned entry Thats it. No, this is not possible (as far as I am aware) as the GUIDs are created dynamically. You could possibly do this (by editing the registry and your FSUIPC ini file)) but I would not recommend this, And, as I said, use joyletters. John

But that can't possibly work, for two reasons: 1. You are instructing to write 8 bytes to offset address 0x2748. This will therefore use addresses 0x2748 - 0x274F inclusive. The second entry is using 0x2749, which then overwrites the area specified for the first lvar. 2. You cannot write an 8-byte value to 0x2749 as this is not on an 8-byte boundary. As I mentioned earlier (and as documented), values MUST be boundary aligned. What this means is that the offset address used for 8-byte values must end with a 0 or 8, offset addresses for 4-byte values must end in 0, 4, 8, or C, and offset addresses for 2-byte values must end in 0,2,4,6,8,A,C or E. Your ini file shows this: which is incorrect for the reasons given above. You are also adding many lvars as unsigned bytes (UB), and many of those are not unsigned bytes. An unsigned byte can only hold a value in the range 0-255. No point looking at your log as - you have WAPI TRACE logging activated., Turn this off. - you are NOT monitoring/logging the offsets you are using, as advised Why do you noy just follow the advise I previously gave: . Please use something like: and also log offsets (Log -> Offsets...) 0x2750 and 0x2578 both as FLT64. This will then log the values in those offsets to the FSUIPC7.log file. You can show me / attach your FSUIPC7.log and FSUIPC7.ini files ? John

If you list the lvars (Add-ons -> WASM -> List Lvars) do you see the lvars with the correct values? I don't know why you would try that... Please use something like: and also log offsets (Log -> Offsets...) 0x2750 and 0x2578 both as FLT64. This will then log the values in those offsets to the FSUIPC7.log file. You can show me / attach your FSUIPC7.log and FSUIPC7.ini files I have added new functionality to log specified lvars (to the log or a separate window) which I will release in a day or two - this may help you see the lvar values, but will basically show the same as adding the lvars to offsets and logging the offsets. I will let you know when available.

What is your issue? Can you please show me / attach your FSUIPC7.log. FSUIPC7.ini and FSUIPC7.JoyScan.csv files and I will take a look. John

Yes. You are using Linda so that log is very difficult to interpret...set Log Lua plugins separately and show me the log file for the script only, and also attach the script. John

Is the script receiving any data? Try debugging the script, by either starting it with LuaDebug or by setting Debug / Trace Lua plugins in the FSUIPC logging tab. But it would be better to update your C code and use the FSUIPC SDK to update the offset with the COM! stndby frequency. Take a look in the SDK subfolder, at the UIPC64_SDK_C_version2 toolkit. You can use this to update FSUIPC offsets, which will trigger the controls to set the values in the FS, John

You are writing the values as an unsigned byte (UB). Those lvars contain double values, so use ipc.writeDBL or ipc.writeFLT. And as they are 8 or 4bytes, you need to write them to an offset on an 8-byte or 4-byte boundary, so use, for example, 0x2750 and 0x2758 (last digit must be a 0 or an 8 when. writing as doubles. That won't do anything.... That will write those lvar values to new lvars (and create them)...why would you want to do this? Again, because you are writing them as bytes when they should be doubles (or floats)... Try: or John

Your files show several things... First, please be more selective with your logging. You seem yo have activated logging for most things for some reason - only activate logging that you need and remove the rest. So, for button assignments, you usually only need logging for Buttons & Switches and Events. Remove the rest. It is also far easier if you look at the log in real-time, so you can actually see what is happening when you press a button, To do this, open the logging console (Log->Open Console). Looking at your files, it also seems that you have changed things while running, so it is difficult to understand some things in your log. Initially, you had your button assignment to the ELECT_FUEL_PUMP_SET control on repeat: but you later corrected for this: but what I don't understand is the following controls being sent: It is these that are causing the VC switch to flicker so much. Do you have assignments in MSFS or elsewhere? If so, please remove these. Also maybe check any assistance options in MSFS - these could also be interfering if set. Your ini file also shows a strange entry - remove this: For your assignment to button/switch 13: you are assigning to the set on press but the toggle on release - you should use the set with both, but with a different parameter, i.e. Also, are all your button assignments using switches or sticky buttons? I ask as you are assigning all of them on press and release. This is ok for switches/sticky buttons, but not for standard/momentary buttons (which send a press quickly followed by a release). For such buttons, you would normally only assign on the press only. For the throttle control, you can try this Input Event: To use this, you first need to determine the range of that Input Event. To do this, activate logging for Input Events (Log->Input Events), then move the throttle in the VC through its full range, and look at the parameter range for that Input Event. Then assign your throttle to write its value to an FSUIPC offset, and you need a lua script that monitors the offset (using event.offset) and in the handling function you calibrate the axis value to the input event value range, then send the input event to the FS using ipc.execInputEvent. I can help with such a script if needed, and if you let me know the input event parameter value range as well as your axis value range.. These assignments also look strange: You have a repeat assignment set on press for button 1, and the same assignment on release on button 0, both sending a 0 parameter.... Also, please wait for 5-10 seconds after aircraft load before trying to do anything - FSUIPC is only fully ready once the following is logged: John

If something doesn't work as expected and you want me to help, then please attach your ini and log files (with appropriate logging activated) so that I can check your assignments. Did you also give the parameter as 1? And did you remove the assignment in MSFS if assigning in FSUIPC? How does your toggle switch work? Usually they send a button press in one direction, and a release in the other. If this is the case, then you should assign to the toggle on both press and release. However, when assigning to a toggle control for both directions, it is possible for your toggle switch to be out-of-sync with the aircraft, so it is usually better to assign to the to the set control (ELECT_FUEL_PUMP1_SET_ with a parameter of 1 in one direction and 0 in the other. But if that isn't working, use the toggle control. Note that some toggles switches may send a different button press/release in each direction, in which case toy need to assign to both of the registered buttons. Not sure why its doing this...it could be due to having dual assignments which are conflicting (i.e. assigned in both MSFS and FSUIPC) or maybe you assigned on FSUIPC with Repeat... Maybe try posting on the MobiFlight discord server, in the MSFS2020 channel. That is the place for asking for help in defining presets for assignments where standard controls don't work. I can see there are already some presets defined for the Cowan Sim. H125, but nothing yet for the MD500e. As I said, I cannot help much with aircraft that I do not have access to - I can only check that FSUIPC is working correctly and that you have assigned correctly - and I need to see you ini and log files for this. John

Ok - that makes sense.

Ah...that is even more difficult! I don't know how you would detect a light touch on a physical button using windows. FSUIPC uses the HID Joystick API, and can only detect button presses and releases. And, as you say, there is no SimConnect interface to control the highlighting. The latter part may be possible in a WASM module using one of the other available SDKs, but I don't know if its even possible for a light-touch (on a physical button) to be detected in windows! Regards, John

No - only a subset of simulator variables are held in offsets. I have never used or looked into using VR with MSFS (or any other sim). FSUIPC doesn't really support VR use - it supports physical controllers, and provides data for other 3rd-party apps (FSUIPC clients). There is no way that FSUIPC can detect a 'light touch' in VR, and also no way for it to highlight anything or show any further information (tooltips?). Basically, FSUIPC doesn't do anything with "visuals'. Look into MSFS's tooltip options, and I believe there are also some 3rd-party mods in this area. Otherwise, try posting in the MSFS/Asobo forums for advice, in the VR forums. Sorry I can't be of more assistance. John

...and if you have written your own program to drive the LED connected to the arduino, you could use the FSUIPC SDK to just write the com1 standby frequency to offset 0x05CC (or 0x311A). Note that you can also use the following control to set the frequency using Hz rather than in BCD format: 67363 COM1_STBY_RADIO_HZ_SET

Ok - glad you got it working, and thanks for the update. Strange it works with the standard controls though, and the custom controls they provide don't work.... John