John Dowson

Sorry about this - this version was extensively tested by me and other users, and I am not sure why there is an issue with so many users for this relatively minor change. I have rolled back this now, so can you please all try this version: FSUIPC7.exe You can change this to the value that suits your needs - those are just the defaults. Note however that this will affect all button assignments. John

Can you please refrain from adding screenshots, especially from 3rd party apps. These are useless to me. I am only interested in seeing your FSUIPC7.log file for this issue, nothing else. Also please attach this file, not screenshots, and do this AFTER exiting FSUIPC7. Can someone/anyone add the following to the [General] section of your FSUIPC7.ini file: TestOptions=x800 And then show me/attach an FSYUPC7.ini file showing this issue. Can you also indicate if you are using a registered/licensed copy of FSUIPC7 or not (although if you attached your log file, this would tell me). I must admit that I did not test this version with the unregistered version before release, but I have just tested this here and all seems fine. If you get this issue with an unregistered/unlicensed version, can you please download the trial license (available from a post at the top of this sub-forum) and try with that to see if you get the same issue - and let me know the results please. John P.S. Also please select/load and aircraft and get ready-to-fly and wait a minute or so before exiting FSUIPC7 and attaching your log file. And also attach your FSUIPC7.ini file.

What trouble? The image you attached is nothing to do with FSUIPC7 - that just shows that vaMSYS cannot connect - whatever that is.... Is FSUIPC7 running? How was it started - via auto-start or manually? Did you see the FSUIPC7 splash screen? Try manually starting FSUIPC7 and see if it runs - you will see am FSUIPC7 splash screen and then there will be an icon in your system tray. If not, show me/attach your InstallFSUIPC7.log file. If it is running you can attach your FSUIPC7.log file and I can check for errors there., but the issue will be with your FSUIPC7 client and you need support from them.

The offsets were monitored in the FSUIPC7.log file, but not in the FSUIPC7_prev.log file. And although these offsets were monitored in the 2nd log file, the values never changed from 0. This is because you have not activated the additional FSUIPC offsets for PMDG - can you do this please. Instructions are in the Offset Mapping for PMDG 737-700.pdf document. The only suspicious event I can see in both log files is this: This is a "Spoilers down" control. Do you know where this is coming from? Can you repeat again with the PMDG offsets enabled, and also check the spoilers position as well as the state of the stab controls in the VC.

Ok, but I don't know much about SIOC (never used it), and nothing about .ssi files. They are certainly not anything that FSUIPC would recognise - I suspect they are specific to SIOC. And yes, it is my understanding thar SIOC uses FSUIPC offsets. With such cards, you would usually assign in SIOC to FSUIPC offsets. FSUIPC only recognises HID joystick type cintrollers natively, and you can maybe use lua for other non-joystick type HID conytollers. This is not related to the flight model you are using or how that is configured. There have already been several support requests in using usbkey cards with FSUIPC. Check these posts to see if they help - search this forum for usbkeys. John

Clear your browser cache, or download from http://fsuipc.com/ - both places download the same installer file, and it is 7.4.3.... John

What type of script? What do you expect FSUIPC to do with this? Is it a lua script? The only scripts FSUIPC recognises and can do anything with are lua scripts.

You only need to use a parameter if using the Input Events or *_SET controls. Thanks - you as well! John

Thanks. I tested quite a but here and released this update as 7.4.3 (including a few ither updates) a few hours ago. This should/may also fix the other issue you had (a CTD), but please post again in that topic if it occurs again. Cheers, John

I am not sure what the stabilizer is or what controls this, but I think this is not related to the elevator trim. Can you log the following offsets, both as U8, to see if these change: 6600 - MAIN_annunSTAB_OUT_OF_TRIM 6C3C - TRIM_StabTrimMainElecSw_NORMAL 6C3D - TRIM_StabTrimAutoPilotSw_NORMAL 6C68 - TRIM_StabTrimSw_NORMAL These are the PMDG controls relating to the stabilizer: Maybe also check the state of those stab trim switches in the VC. We can also check for those events that control the stab trim switches in your log, once logging for Events has been activated (they will be logged as ROTOR BRAKE controls with the parameter indicating the event).

These seem to work..or at least the event is sent and received, although I don't know if they activate/deactivate the governor... The mageneto control works switching on, but not off. The plasma control seems to work. All these look to be working, with parameters 1/0 for on/off. I would use these. John

Did you get anywhere with this? Logging shows that the governor is using: ROTOR_GOV_SWITCH_OFF ROTOR_GOV_SWITCH_ON and the two ignition switches (magento and plasma) are using: MAGNETO1_SET PLASMA_SET Did you try those? If not working, there are also these Input Events you can try: ENGINE_Governor_Switch_1 ENGINE_Governor_Switch_2 ENGINE_Magneto_1 ENGINE_Plasma_1

Your logs show the elevator trim decreasing in your prev log file, down to -4208, and when you restart it gradually increase slightly to -2788. I would guess its the AP controlling this, and there is not much difference between the values after the restart so I don't think this can be causing the issue. The spoiler offsets remain at 0, so this looks ok, although maybe PMDG aircraft don't use these offsets - I will check the PMDG SDK/offsets to see if there is anything there to log which could be useful. For now, drop those (0BD4 and 0BD8) and add 0BB4. Looks like you didn't set logging for Events and Axis Controls. Can you set logging for these please Were those logs attached when the problem persists or went away? Seems it was restarted quite soon - after 10 seconds or so....

Yes. Yes - remove all entries for scripts not installed. Yes. Or maybe just: I don't know...try listing the lvars to see what is available.

For which aircraft? Try looking for an appropriate preset - check Select for Preset and use the Find Preset... button. Alternatively, use the HubHop search (https://hubhop.mobiflight.com/presets/) to find the relevant preset and then select that from the preset drop down menu. Also, try searching this forum as this question has been asked several times before...

Yes, it looked like a software driver was missing! Thanks for the update. Cheers, John

@Coast_Flyer I have now received feedback from Spad,neXt and they have confirmed that this issue is on their side - when FSUIPC7 is running, it is sending the keystrokes to FSUIPC7 instead of MSFS2020. They will (maybe) correct this in a future update. I will update again once this has been done. John

No idea! Try the usual things: use logging for Events, open the logging console and see if anything is logged when you activate those in the VC. If anything is logged, try using those events. Otherwise, list the lvars to see if anything looks applicable and try them. Also try listing any Input Events and see if any of those look applicable. Otherwise, as a final resort, use the devmode debugging window to see how these work in the behaviors window, as shown in this post: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/. I see this is a freeware helicopter. I can install it and take a quick look, although I am not that familiar with helicopter controls. It may take a day or two before I have time to install this and take a look though. John

First, can you check the power management settings on your USB devices and hubs. Make sue Allow the computer to turn off the device to save power is disabled/unchecked. That is usually the reason for such issues. You also have your axes assigned to multiple devices and multiple axes: i,e you have your ailerons assigned to 2 axes on one Logitech Attack 3 (0), on one axis on another Logitech Attack 3 (2), and another on a device called New (4), which you also have two of. This seems very strange and can cause issues, as each axis can send values on the slightest movement. Better to only assign axes to one controller. Pease check and correct these issues and try again. If you get the same issues, please activate logging for Axes controls and fly with the logging console window open. When the joystick freezes, take a note of the timestamp of the latest log entry before unfreezing. Once you have recovered and finished the flight, zip up the log file and attach it here, with a description of what you saw in the logging console when this occurred, together with the timestamp. John

It does not get added automatically - you must have added this, and it is also in your ini file for P3Dv4. This won't cause any issues, just log a message. Probably due to a windows or driver update. Nothing to worry about. Well, any errors are logged with the line number in your FSUIPC5.log file. You can also set logging for lua plugins, which will log each line executed, and you can send these logging statements to a separate log file if you wish. See the options in FSUIPC's logging tab. It must either be a different script, or you would have had the same issues on your old PC. You said they were in 3 places (always a bad idea!) - maybe you copied the wrong one? No, this would make no difference to this issue, as the issue is missing lua functions. Maybe you copied the wrong ini file as well? That depends....generally not, but, if, for example, you were using GoFlight or PFC devices, then you would also need to install the drivers for these. Your ini also references the following lua files: So they should be present. However, if you are not using any of these (note that ipcReady.lua will always be started automatically) then you can remove the entries. However, do NOT change the index number of the scripts you are using (My320functions.lua) otherwise the assignments to this script will no longer work. Are you also using LINDA? If so, make sure that is installed and up-to-date.

Just show me/attach your FSUIPC ini and log files initially, preferably from a session where you experience this issue. We can add more logging later if necessary. Also check any assignments in the FS, if controllers are not disabled. John

You can't do that...it seems that your device is not recognised, and no manual editing can fix this. Ok. Please update if/when you find a solution. Maybe try a different cable though. There have been previous support issues with serial-to-hid devices due to poor quality cables.

Can you try the attached please: FSUIPC7.exe Hopefully this fixes some issues when starting FSUIPC7 (in various sim states), when restarting a flight (note that luas will be left running, not killed), and when exiting a flight and going back to the main menu (luas killed when plane in parking state, regardless of camera state). John

Dont worry about it - I am working on this at the moment. There are various issues as the data/events being received from MSFS are not consistent. I will post an updated version for you to test, hopefully later today. John

One last thing you could try is running the HidScanner program (available from the Download Links -> Useful additional programs section of this forum) and send me the output. If that recognises your device, then you could use a lua script (HidDemo.lua, available in the Example Lua scripts package) to convert your buttons/axes to virtual ones. But I still think you would be better off getting a solution for your issue from the vendor. Please update if you solve your issue. John