John Dowson

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

I am not sure how you are getting the input to set your LCD display, but It may be easier to use the ipc.ask lua function to get this user input / com frequency in one go (rather than monitoring keyboard input via event.key), and then use the value received to set your LCD display (however that is done!) and send the control to set in the sim. You would need to run such a script on a specific key combination or button press. Cheers, John

First, you posted in the sub-forum for FSUIPC7 / MSFS - please use the main forum for all other versions of FSUIPC, not the specific sub-forum for FSUIPC7. You also attached the trial license/key file for FSUIPC7 for some reason...I have removed that. Yes, that is the correct control/event, but be aware that the parameter for that control is in BCD16 format (Binary-encoded decimal), so to set to 120.80 you would use: ipc.control(66371, 0x2080) (the leading 1 is assumed). That is the difficult bit. You would need to register a function to receive key presses (using the event.key function) for the keys 'C'. 'O', 'M'. '1', ' ', 'S', 'B', ',' , and all the digits, then keep track of everything entered and in the correct order....I really can't recommend doing it this way.... Maybe take a look at this user' contribution, which is a lua script to allow keyboard entry for radios (as well as obs and AP). Its for FSUIPC4, but should work with FSUIPC5, although some small modifications may be needed: John

Well, its not going to be anything to do with the throttle itself - that will just be sending an axis value, as with all other throttles... Doesn't matter - and you don't have to. As the flaps are working for the user in the other post, it would be interesting to find out how this is assigned. If its not using LINDA, you can just copy that. if it is using LINDA, I can maybe take a look at what LINDA is using and replicate that (LINDA is just a fancy wrapper around FSUIPC's Lua functionality). The Rotor Brake control is another method of sending custom controls for PMDG aircraft - see That is strange...be careful though, as I think there were some issues when using the regular flpas assignments that could cause a loss of power when climbing...but that may have been for the 737 or for the MSFS version, not sure without checking... Was that with the standard flaps control? Could it either be due to a failure or maybe they are being controlled by the FMS? I am no expert on airliners and only fly these occasionally for test purposes, so better off asking about this on the PMDG forums, and check the 777 documentation.

You don't create them - they are either provided or not. Just try listing what is available: Log -> List Input Events and Add-ons->WASM->List Lvars. For Input Events, you can also log these in real time (Log->Input Events), so set that and then move the twist throttle and see if anything is logged. The FSUIPC7 main window also indicates how many Input Events and Lvars are available (as well as Presets and Hvars). No problem - sorry I can't help more, but its difficult not having the aircraft. I can only advise on the various techniques to try, and how to use those if you find anything. Regards, John

Note that another user also had issues with flaps in the PMDG 777, in the following thread: I have asked if he can share his settings, although he way be using LINDA for this... John

@Edmundo Could you maybe share your flaps settings as another user is also having issues, in this thread; Thanks, John