John Dowson

Sorry, there is a mistake in that preset - you need to divide by 327.68 and not 32.768. Try: My PMDG B737 Spoiler Lever Set#@ 16383 + 327.68 / near 0 max 100 min s0 l0 5 < if{ 679101 (>K:ROTOR_BRAKE) quit } l0 10 < if{ 679201 (>K:ROTOR_BRAKE) quit} l0 50 < if{ quit } l0 70 < if{ 679301 (>K:ROTOR_BRAKE) quit } l0 95 < if{ 679401 (>K:ROTOR_BRAKE) quit } 679501 (>K:ROTOR_BRAKE) I have actually looked into this before, and that preset should allow movement between the 4/5 notched positions. For complete smooth axis control, you need to assign with 'Send to FS as normal axis' using the Axis Spoiler Set control, and remove any calibration on the spoilers. See Otherwise, you can keep using the button controls on the axis range if that works ok for you. Did you get any further on the loss of airspeed issue? Did you try the logging I suggested?

What do you mean by 'did a "Restart"'? Your log shows that you are running a lua script that is using the Wnd library. It has been reported that FSUIPC will crash when using the Wnd library if the window is iconised - see this thread: This is something I need to look into, when time permits. Could this be the issue? Otherwise, can you please also check the windows Event viewer - there should be a crash report there when/if FSUIPC CTDs. Please show me the details there, as well as your log file, the next time this happens. John

By 'xbox version', do you mean the xbox-pass version? FSUIPC7 will work with all versions of MSFS2020 running on a PC, it does not work on an xbox. The homecockpitfactory honeycomb bravo start/cut off module looks to be an add-on module for the Bravo. Just try to configure it through FSUIPC7's button/axes assignment panels, as you would any other button or axes. John PS. See this on youtube:

It is present - you just couldn't see it as you are a new user and your first post needs to be approved. You should be able to download it now, John

What FS and version of FSUIPC are you using? PMDG aircraft use lots of custom controls. Looking at the PMDG_777X_SDK.h file, I can see the following custom control: So try using that. See the following FAQ entry on how to use PMDG custom controls: Also, please see the additional offsets available (when enabled) for the PMDG 777, described in the document Offset Mapping for PMDG 777X.pdf. John

Then it looks like that lvar is only controlling the visuals. You have to determine what the aircraft actually dows when you move the switch in the VC, and then implement that in your assignments. This post shows you how to do this: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ However, someone else may already have done this, so it is always a good idea to check the MobiFlight HubHop site for available presets. You don't say which aircraft you are using (which is ALWAYS needed for assignment issues), but searching the HubHop site for the lvar ELECTRICAL_Switch_Battery_Master, I can only see this in the Flysimware Cessna 414a, and there is the preset C414A_Master_Battery_Toggle to control this which uses the following calculator code: (L:ELECTRICAL_Switch_Battery_Master,Bool) ! (>L:ELECTRICAL_Switch_Battery_Master,Bool) (L:ELECTRICAL_Switch_Battery_Master,Bool) 0 == (A:BUS CONNECTION ON:6,Bool) 1 == and if{ 6 1 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) } (L:ELECTRICAL_Switch_Battery_Master,Bool) 1 == (A:BUS CONNECTION ON:6,Bool) 0 == and if{ 6 1 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) } (L:ELECTRICAL_Switch_Battery_Master,Bool) 1 == (L:MASTER_BAR,Bool) 0 == and if{ 1 (>L:MASTER_BAR,Bool) } So, if using the C414A try that. Alternatively, you could try searching for a similar preset for the aircraft you are using and look at the code for that to see what it is doing. You can also try listing the available Input Events - there maybe one available that directly controls the master battery. If you let me know what aircraft you are using, and I have access to this aircraft, I can look into this further for you. If I don't have this aircraft, I can only point you to things to try (as above).

Ok, then it sounds like you need to use this software. If designed to use FSUIPC offsets, then it may be easier to go down this route... Otherwise, maybe ask the panel/software providers if it is possible to detect button presses directly using the lua com library. If the HidDemo script isn't seeing these button presses, it is not behaving as a standard Hid joystick type device. One thing you could try is to change the Report number - try changing this to 1 on line 26 of the HidDemo.lua script. Other than that, I don't think I can helpfurther with this and you should try the support for your panel. The lua script is receiving this data and logging it in the code in lines 93-102. I do not know what this data is, but it doesn't seem to be related to button presses or axes movements. Button presses/state changes would be logged at line 185, starting "Buttons=...." Sorry I can't be of more help with this. John

To be clear, if you have a standard axis range of -16383/4 -to +16383, then the preset would be: My PMDG B737 Spoiler Lever Set#@ 16383 + 32.768 / near 0 max 100 min s0 l0 5 < if{ 679101 (>K:ROTOR_BRAKE) quit } l0 10 < if{ 679201 (>K:ROTOR_BRAKE) quit} l0 50 < if{ quit } l0 70 < if{ 679301 (>K:ROTOR_BRAKE) quit } l0 95 < if{ 679401 (>K:ROTOR_BRAKE) quit } 679501 (>K:ROTOR_BRAKE) Adjust as needed.

You need to use logging to see what is happening (i.e. controls being sent)... Best to do this in real-time with the logging console window open. But I suspect that this is becaue you are using the standard spoiler control. I don't think this is 100% reliable for the PMDG 737. Looking on HubHop, there is a potentiometer preset for the spoilers: PMDG B737 Spoiler Lever Set As indicated in the comments, this is for an axis range of 20 to 1023. You should copy this preset definition, change to your axis range, and add the preset to your myevents.txt file and use/assign to this instead of the standard spoilers control. Also please remove/reset any calibration on the spoilers you have in the FSUIPC calibration panel. If the spoilers aren't properly stowed, could this be the cause of the lack of airspeed?

This software may be interfering. Better to not run this, or use any specific drivers. First try without that software running, and also try uninstalling any specific drivers you have installed and and let windows install default drivers. You have activated logging for lua plugins - this is not needed (at the moment) and is adding a lot of noise to the logs so please disable. You have set logging in the lua script itself which is good and sufficient for the time being. This should be enough to determine what the lua script is seeing/doing, if anything, when you press a button on your panel. From what I see, it is not recognising any button presses at the moment, but this may be due to the additional software running. Note that the script also handles axes/potentiometers. If you have no axes on your panel, best to remove these parts to simplify the script. At least you now have the lua script running and it is detecting your device... It is very strange that you only see this when you disable lua logging...not sure what that data logged is, but it doesn't seem to be related to button presses that the script recognises. This may be due to the software/drivers you are using. John

🫰😎

I have not seen this before....! Do you know what these are? I also see '(Unused)' in some of your axes range assignments... I will check this... Ok - Unused is an option in axes assignment when assigning direct to FSUIPC calibration. I guess this is used when there is no assignment to the axes itself, but when you have button control assignments to axes ranges. So this is nothing to worry about.

This is all very interesting.... It may be worth adding logging for various offsets for values that affect the speed - throttle/N1, flaps, spoilers, trim... so that we can see what these values are, If you again exit FSUIPC and the speed increases, if you then restart FSUIPC and the a/c looses speed we can see how/if these values change. A few other points: 1. you have some strange assignments in your PMDG profile: I have not seen this before....! Do you know what these are? I also see '(Unused)' in some of your axes range assignments... I will check this... 2. Maybe also worth adding logging for axes values and repeating the tests with this logging added, but the log files will be pretty large. 3. Many folks have issues with FSUIPC calibration with PMDG aircraft due to priority levels. Maybe try switching your axes assignments to using 'Send to FS as normal axis' and removing/resetting any calibration in FSUIPC to see if this makes a difference. Will do! Ok. I don't have much time today, but I will look into this further when I can. Please keep me updated on anything you find... John

Lua scripts are not started until you have an aircraft loaded and ready to fly. The log you pasted shows that FSUIPC was not even connected to MSFS, and ends after 11 seconds. It will NOT show up there - that is a scan of HID joystick type devices ONLY. When the script is running, it will map the buttons of your device to virtual buttons, which you should see when activated in the button assignments panel.

Not really - but the title says 'anymore' - does this mean that it was previously recognised? If so, what has changed? Can you also please attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. So you previously had working assignments in FSUIPC7? Are your axes/buttons on the throttle seen by FSUIPC7? i.e. can you see them in the assignments windows when moved/pressed? If so, I would suspect that there has been change in the registry which means that the name or GUIDs of your device have changed and the device has been recognised as a new device. Your files would help determine if this is the issue or not and if so it is easily corrected. Otherwise, please download the HidScanner tool, available from the Download Links -> Useful Additional Programs section of this forum. Run this and send me the output (together with your .ini and .log files). Also worth checking the power management settings both on the device and on your USB Hubs - make sure power management is disabled. P.S. I moved your post to the correct support forum for FSUIPC7

See my last post - I suggested that you try this, and I don't think this will make any difference. FSUIPC allows you to control the aircraft, it does not affect the aircraft model. You need to determine what could be the cause of this loss of power. Please do, but I don't think this will make a difference.... John

But the initial report from the OP looks to have been caused by flaps being accidentally deployed, slowing the aircraft. If the flaps are up and the speed brake stowed, then I have no idea what could be causing a power reduction. However, I cannot see how this cannot be anything that FSUIPC is doing, as it only controls the aircraft model through the assignments you have made. You can test/check this by pausing the sim when you are configured and climbing, exit FSUIPC7, then un-pause the sim. The aircraft should continue climbing at the same rate. I can only assume that this must somehow be due to the aircraft set-up/configuration. I am no expert in the 737, so maybe better to ask about this on the PMDG forums. Your log file shows nothing unusual. John

You also need to start the lua. You do this by adding it to the [Auto] section (which you can add if not already there), i.e. John

Better to explain your issue - is it that you have reduced speed while climbing? The OPs problem is that he had flaps deployed - have you checked the position of your flaps and spoilers when you perceive this lack of power? Your throttle calibration in your B737PMDG profile also looks strange: This looks like you have calibrated with a reverse zone but are not using a reverse zone. Better to calibrate with no reverse zone. I also need to see your FSUIPC7.log file showing your issue. Set logging for Buttons & Switches and Events for the first test, Also, please update to 7.4.2, the latest and only supported version of FSUIPC7. John

FSUIPC will only recognise buttons on HID joystick type devices. If this is a non-joystick type HID device, then you have to use the lua com library instead. There are various methods of doing this, but the easiest to start with would be to use the provided HidDemo.lua script, available in the Example Lua plugins.zip file which will be installed in your FSUIPC documents folder. This script converts HID button presses to virtual button presses, to which you can then assign in the Buttons & Switches assignment panel. You will need to edit the script to give the correct vendor and product ids for your device, and have the script auto-started from your FSUIPC ini file. John

It doesn't - it is reporting dev/com threads still running, and this is before the terminate message for that script, so probably not closed yet. I wouldn't worry about this until it fails, i.e. does not stop the script. Then send me the logs.

i have looked into this further and have found some strange interactions between FSUIPC7 and Spad.Next w.r.t sending key presses, but not exactly as you describe. How have you assigned in Spad.Next? Are you sending to the active window or to the FS? The latter is preferable. Not 100% sure what the issue is yet (it looks like Spad.Next is sending the key presses/releases to FSUIPC7 instead of MSFS), but I will look into this further and contact Spad.Next to see if anything can be done about this.

Not necessarily...best to just look at the scripts and see if they are opening any com ports, and if so close them in a terminate function. However, that log extract shows everything closing/being killed ok. Why would i need this? Just check the script and add some lines to close the coms in a terminate event. Looks like it may already have such a function, as 'LUA.11: HidSwitch ends.......' is reported....

Then it looks like that aircraft is not using (or respecting) that simvar. Instead of using the aileron simvar offset, you could try sending the AXIS_AILERONS_SET control/event instead. To use this, you need to write the value/parameter to offset 0x3114 as a 4-byte int, then write the control number, which is 65763 for AXIS_AILERONS_SET, to 0x3110 as a 4-byte int. You can also write all 8 bytes in one go if you prefer.

Those errors are reported soon after 'Requesting Input Events...' is logged. This is just a timing issue as the input events that are activated/initialised are received from the aircraft before the actual input event list is beinf received. You can safely ignore these. I will look into removing the logging of this messafe if the input event list has not been received. This should not prevent anything working though... Please do not 'log luas separately' - remove this logging option, and send me a full FSUIPC7.log file showing this issue.