John Dowson

Your files are a bit strange,,, First, you have disabled the WAPI: Why have you done this? Your log indicates that you had assignments to presets: but I can't see any assignments to these in your ini, but you do have (now invalid) assignments to custom control 0: Maybe these were assigned to presets, and as they are no longer available they have been removed - although this shouldn't really happen... I will check this. Also, please use substrings for your aircraft profile names, i.e. change to This will prevent issues with your profile not loading when you use a different variant. As for your actual issue, I cannot help with this as this is done by the CPFlight driver/software, so you need support from them really, and I do not own or have access to any CPFlight equipment. There are other CPFlight / FSUIPC users who may be able to help - maybe @fischkarl, @ppatys or @Ron Vogel can help?

Ok - when you get strange connection issues, ir is normally down to windows and a reboot us needed, The upload limit is rather restrictive for new forum members - it will increase as you post more. You can also zip/compress the files as they reduce very well, but no need to see your files if its working. FSUIPC provides access to all FS controls (and more) - there just aren't any for the PMDG 737 runway lights, You can use the available presets though, by checking 'Select for Preset', then click the Find Preset... button and navigate to the PMDG 737 presets. You can also use the MF HubHop site to search for presets - the following are available for the runway lights: For PMDG aircraft, you can also use the custom controls provided by the PMDG SDK - see the following article on how to use these (although many are available via presets, but not all): John

Your file shows that FSUIPC could not connect to MSFS: Nothing is going to work if it can't connect. I don't understand why it can't connect, or why it didn't log another 'SimConnect open event not received ...' message at 164250 and try again. Did MSFS reach the main menu stage, and if so how long does this take? Can you reboot your PC and try again. If FSUIPC again fails to connect by the time MSFS is in the main menu, exit FSUIPC and show me the log file again (please always exit FSUIPC7 before attaching files). Then restart FSUIPC7 manually - does it then connect or not?

First, please check the build date with this version - the first version I initially uploaded was incorrectly built against the MSFS2024 SDK. I later re-released, with the same version number, but with the build date updated. Check your FSUIPC7.log file - if you see this on the 1st line: then download and re-install. It should be: Otherwise please clarify: was this working in earlier versions, and if so which version were you using? This can be very aircraft dependent,, and is nothing to do with FSUIPC...FSUIPC only sends the controls what you have assigned... Is this controlled by FSUIPC? Please show me / attach your FSUIPC7.log and FSUIPC7.ini files. John

Strange question...I try and help everyone who posts... Please check the build date with this version - the first version I uploaded was incorrectly built against the MSFS2024 SDK. I later re-released, with the same version number, but with the build date updated. Check your FSUIPC7.log file - if you see this on the 1st line: Then download and re-install. It should be: Otherwise: But they follow the dial or not? Is this a speed issue (i.e. the numbers update slowly)? What aircraft are toy using? Can you please give me a more accurate description of your issue, and please show me / attach your FSUIPC7.log and FSUIPC7.ini files. John

Why didn't you read this thread before posting? You need to reinstall. See my previous comment. John

Can you not change this yourself if building from source? Looks like it needs the following added: FSX, P3Dv3-6, MSFS2020 (and soon MSFS20204!). I guess I can/should also change this and also maybe rebuild the lib with VS2022. I have been reluctant to do this up until now - I will take a look at some point, but for now you can just update for your needs, or just leave it as unknown - I don't think this matters that much, just for logging purposes I think... John

Can you download 7.4.18 again and re-install please. When O released 7.4.18 on the 1st, this version was (accidentally) compiled with the SDK for MSFS2024, as I was investigating this SDK and forgot to switch back. I corrected this and recompiled on the 3rd and re-uploaded, so can you please download and use that version. Your shows: whereas it should show: Be careful when you download again - your browser may have cached the original download, so clear your browser cache first. I should maybe update the version number for this build... Note that this was also previously reported here: If you get the same issue with that version, let me know and I will look further. Btw, why have you not installed the FSUIPC WASM module? Don't you use presets or lvars/hvars? John

That is the install location for FSUIPC5 and earlier versions. From FSUIPC6 and onwards, you must select/choose the installation location - if you don't, a default location will be used - maybe now C:\FSUIPC6 but in earlier versions it was under the P3D add-ons folder, under Documents. John

It is installed in the folder you chose when you installed - this may be under your Documents folder... To uninstall FSUIPC6, run the uninstaller, either via the windows app management panel or by running the uninstaller directly from the installation folder.

I am not familiar with the G1000 and am not sure what that key/symbol is...these are the control pad presets available for the G1000: There are also many presets available for the MFD, PFD and MID: Could one of those be what you are looking for?

This really shouldn't happen... I have realized that I made a mistake with the 7.4.18 release...I have been testing the SDK for MSFS2024 and accidentally built the final release of 7.4.18 with the SDK from this version, instead of the version for MSFS2020. Sorry about that - I have corrected this now and have updated the installers with this correct build. Could you therefore please re-download and try again. if you get the same issue, please show me / attach your FSUIPC7.log file. Note that I have kept the version number the same, at 7.4.18, but the build date has been updated to 3rd November, so please check thar you are using this version (you may need to clear your browser cache to download this version. I have also attached this version below, but you should really re-install as the WASM has also been rebuilt. You can prevent this by setting the following ini parameter under the [General] section of your FSUIPC7.ini file: OpenOnStart=Never John FSUIPC7.exe

The new fuel system simvars have not been added to any FSUIPC offsets as if these are added, they flood the MSFS console with error messages when using an aircraft that does not use the new fuel system. I did add the new fuelsystem pump simvars to FSUIPC a while ago which produced this error, which can cause stuttering due to the number of messages logged, I therefore removed these by default. and added a new ini parameter NumberOfPumps which can be set to re-enable these offsets. For the new fuelsystem tank variables, you can add these to spare/free FSUIPC offsets yourself via the myOffsets.txt file (see Advanced User guide for details). If you do this, make sure this file is only loaded/used when you use an aircraft that uses the new fuelsystem. John

Thanks for your kind words. Pete has retired now and doesn't check the forums often, but I will pass on your message. Regards, John

Your upload limit will increase the more you post. The files also zip/compress pretty well, as they are just text, so you can also try that next time. Your log files don't show any issues, other than your device not being detected on COM1. You need to determine what COM port your device is using, and I can't really help with this. Your device is or has previously been detected as a HID joystick type device though: Although there are no entries for that device with a joyId number, which makes me suspect it was added earlier when you were using a different COM port number. Maybe try removing that entry, and go through the COM port numbers again and see for which COM port number that entry gets added Other than that, I am not sure what I can advise... maybe some other PFC Cirrus !I users can help - both @Logan Greenlee and @Jeff Enlow are PFC Cirrus II users I have helped in the past, maybe they could help with this?

Did you install the driver that comes with the cable? Then I guess the drivers are installed... Does the test app tell you which COM port is being used? Did you try COM1? Most modern PC's don't have COM ports, so the cable may be on COM1, so at least try that. If that doesn't work, show me / attach your FSUIPC7.log, FSUIPC7.ini and PFCcom64.log files and I can take a look, although I'm not sure I can help much if its not detected...

No - that ini parameter just specifies the just delay between aircraft load and the first scan for lvars. It seems to be repeated scanning for lvars that is causing this issue, and that will still occur. That is very interesting...that does indicate to me that there maybe is a memory issue somewhere un the WASM - I will look into this (again).... Thanks for your files/input on this. I will update if/when I find amything. Regards, John

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