John Dowson

Do you mean the strange flicker? I have no idea what could be causing that. Please check that the throttle lever is not assigned or calibrated in MSFS. You can also generate a log file with logging for Axes Controls set, and show me/attach that together with your FSUIPC7.ini file. Just load the aircraft, set logging for Axes Controls, move the throttle through its full range and back again and then close/exit FSUPC7 before attaching the files. John P.S. I have moved your post to the FSUIPC7 support sub-forum - please use this forum for all questions/issues with FSUIPC7.

First lets clarify some terminology. A macro is just a collection of commands, executed in order, contained in a macro file, i.e .a file ending *.mcro. Macros can be called/executed by assigning to a button or key press/release, when entering/leaving an axis range, or by the lua command ipc.macro. A lua script or plugin is a script in the lua programming language, contained in a *.lua file, that can be ran either automatically, on a button or key press/release, or started by another lua script. There are two way sof doing this. The lua script can monitor for the same event that starts the macro, so that when the macro is called the lua script also receives the event. e.g. if the macro is started on a button press, the lua script can wait for an event on the same button press using event.button. Alternatively, the macro could perform an action that can be picked up by the lua script, such as setting a flag or writing to an offset. This doesn't make sense, FSUIPC runs until it exists - it makes no sense to 'execute fsuipc in a loop'. And a macro is just a sequence of commands with no control - it will execute until the end once started (ther is no conditional logic in a macro). If you mean that you want a lua to loop in a lua script until a condition is met, then use a while loop, e.g. while(not B1) do ... end See https://www.tutorialspoint.com/lua/lua_while_loop.htm.

Which flight simulator/version of FSUIPC are you using, and which aircraft? Please always specify this information when asking for assistance, as assignments can be different for different simulators and aircraft. You can try setting logging for Events, open the logging console window and see if anything is logged when you click the buttons in the Virtual Cockpit (using the mouse), and if anything is logged then assign to that.

No there won't be. But I am surprised that is solving your issue, as the documentation states: So you should need a larger value to make it less sensitive, not a smaller value. If the trim wheel is using a macro, you could provide your own to override the default behavior, as for any other buttons/switches that don't work, or need to be made aircraft specific in their assignments. You also need to read up on how macros work in the FSUIPC7 Advanced User guide (page 36). You can log the macro name used for each button/switch by setting LogMacroNames=Yes in the [Debug] section of your PFChid.ini file. You can then create a macro with the logged name in the PFC.mcro file and this will then override the default behavior of the button/switch that uses that macro name. John

As I said, you need to use logging to see what is being sent, and also operate in the VC to see what should be sent, then update the assignment accordingly. Not sure what this means....You won't see the buttons/switches in the assignment panel - I don't think it works like that for your device. The switches trigger a macro. There are default macros for most switches/buttons, but these may not work for many aircraft in MSFS2020/MSFS2024. That is why you can override the default macro and provide your own. This is all described in the PFChid User guide documentation - did you read that? Yes - they will be using the default/inbuilt macros. Please read the documentation provided with the PFChid64 driver dll.

Here's how to add the offset conditions. First I assign a button to each Up and Toggle macro, and get this in my ini: (your index number, joystick number/letter and button numbers will be different) I would then duplicate the Up assignments, and change to use the down entries (the number - the comments will be updated automatically) and re-assign the index numbers, giving: Then add the offset conditions to the Up/Down entries: Note I have also added to extra lines (19 and 20) as the strobe switch needs to be moved two times to change the offset that it is referencing. With those assignments, you can control all the light switches, each on an individual toggle. Please note that when editing the ini, if FSUIPC7 is running then edit when you have the button assignments panel open, and when finished and saved click the Reload all buttons button in the panel to load the changes. And once you click Ok in the assignments panel, always reload the file in the editor. Those assignments seem to work pretty well. However, there is an issue as both the runway and nose lights set/use the taxi lights flag. The runway lights is a toggle, so doesn't use this and it is not affected, but the nose wheel assignments do. What this means is if you set the runway lights first, then you cannot set the nose lights as the taxi lights flag is already set. Not much can be done about this - just always set/clear the nose lights first if using both nose and runway lights and you should be ok. John

I have update the macro file now with the above, so try this - you will need to remove your current assignments and re-assign: FSLA321.mcro I can possibly look into showing you the offset conditions needed for the 3-position switches if needed.

Sorry, missed this. Alt+F is the default hotkey to open the FSUIPC main window, but you can change this if needed (via the InvokeFSUIPCOptionsKey ini parameter). See the documentation for details. John

To make this clear: - start P3D/FSUIPC and load the aircraft - set logging for both Events (non-axis controls) and Axis controls in the FSUIPC logging panel - list the lvars / Local Panel variables - press the master warning switch in the VC using the mouse - list the lvars/local panel variables again - exit P3D/FSUIPC and then show me / attach both your FSUIPC6.log and FSUIPC6.ini files. John

To use one button for on & off, you would need to overload the assignments (i.e. have both of the assignments on one button) and add an offset condition to check the current state of the lights so that only one control is sent depending on the current state. This depends on the current state of the light being available in an offset. Offset 0x0D0C is the one normally used for this, and holds the state of the following lights: The runway lights seem to be the taxi lights, so bit 3 (and 2^3 = 8 or 08 so you would use that) of offset 0x0D0C will hold this information, so the offset condition for the lights on press would be W0D0C&08=0 and W0D0C&08!0 (or just W0D0C&08) for the lights off press. See page 24 of the Advanced user guide on how to add offset conditions. However, testing this again, it seems that both the switch up and switch down macros actually work as a toggle - did you try them? i.e. try just using the one button and that should switch on and off. As that is the case, you only need one macro entry really, and just use one button. You can rename the macros to make this clear, e.g. just use "Runway Lights" or "Beacon Lights" rather than having both Up and Down versions. This seems to be the case for all the light switches that have two positions, but not the ones that have three positions (Nose, Strobe, Nav & Logo, and landing lights - you cannot really control these with one button for 3 positions, so you will need two buttons for each of these (one to move the switch-up, and one to move it down. However, if you just want to use two positions for these 3-position switches, you can use one button with offset conditions. I can show you how to do this in more detail if needed. John

That is for mouse macros. Macros are also used for sending compound (i.e. multiple) commands, AND for using lvars. Please see the documentation that I referenced: Please translate/read that section to understand how to use macros to set/control lvars. I think that script was for the FSX version. It may work in P3D, but check that the lvars it is using exist, and check the script is actually running. If you have followed the installation instructions, the script will only start when the aircraft name is "F1_Cessna_Mustang1". The name is probably different in P3D, so you will need to change this in the ipc.ready script. Try logging offset 0x3D00 to see what name is reported when the aircraft is loaded, and use that name to update the ipc.reasdy script. Control number 65823 is Throttle4 Set so I do not understand that comment. To test if that control works, you don't need the lua scripts. Just assign to the FS control Throttle4 Set with a parameter of 32. If that doesn't work, then the script will not work either as that is all that does. If there is an lvar called ENGINE4_SET, then you could try setting that lvar to 32 using a macro file (NOT a mouse macro). But again, this seems to be for FSX and I am not sure it will work in the P3D version. Can you show me/attach a log file where you have listed the lvars so I can see what lvars are actually available for this aircraft. That would help. Also please attach your FSUIPC6.ini file. John

The Rotor Brake control is normally only used in helicopters. As it is not used in aircraft, some aircraft developers use this for their custom controls, with the parameter indicating the function. No, sorry. There is a FAQ entry on how this is used in PMDG aircraft here: However, that is NOT applicable to the FSLabs,, and FSLabs don't provide an SDK as PMDG provide, Basically I found these using FSUIPC's logging facilities, which you can use in many (not all!) cases to determine how to control a switch. I showed how I found these in that previous post I referenced, so take a look at that, However, things are a lot more complicated in MSFS2020/2024. Every aircraft seems to use different methods - some custom controls (via Rotor Brake or other means), some Input Events, sometimes Lvars/Hvars/Bvars. These things are very dependent on the aircraft developers. With FSUIPC, I try to provide access to these different methods, and can advise on how to look into the different methods of how to assign a particular button using the features I provide. For most aircraft, presets tend to be the easiest way, and the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/), which is a community-driven effort led by MobiFlight) would be the starting point. However, there seems to be nothing there at the moment for the FSLabs aircraft. As the FSLabs seem to use custom controls via the Rotor Brake control, you can use FSUIPC's logging facilities to determine what is needed to control any particular switch. Set logging for Events (Log->Events), open the logging console (Log->Open Console), and then see what is logged when you flip the switch in the Virtual Cockpit using the mouse. Then either assign to that (if one event is logged), or create a macro entry if multiple events are logged. Thats the basics, but it can get more complicated. John

Thanks - they look good with that version and show the PMDG-specific offsets have been enabled. However, both your log files do contain errors because you are trying to operate the aircraft far too early. With complex add-ons, such as the PMDG, you need to wait a while before everything is loaded and available. You were operating things around 10 seconds too early in MSFS2024, and around 30seconds too early in MSFS2020. Not an issue though - just incase you were wondering why your initial button presses had no effect. Apart from that, it looks good. Thanks for testing this for me. Regards, John

The font you used for that message looked ok... Sorry, but I have no idea why cutting and pasting from your translator program doesn't work. When you paste, you should see a black box below the text entry panel asking to paste in text original format (or rich text) or plain text. Just click plain text after pasting and that usually works.

Presumably you use the lvar BKSQ_IgnitionPosition_1 to move the position of the switch, no? Does this have any actual affect on the starter, besides moving the magneto rotary? I am not that familiar with such complex gauge calc code, but it looks like you also need to set the starterKnobReturnTime_L lvar when you do this. You can set both lvars using a calculator code preset. The rest of the code is setting O-type (component) variables which I am not familiar with. Are any other (standard) events or input events logged (in FSUIPC log / console) when you move the starter in the VC? If its just a matter of holding the magneto rotary in one position for a certain amount of time before changing the position back, you could do this by writing a macro or lua script. But its probably more complicated than that. You could try asking the community if its possible to create a preset to replicate that code. The best place for this type of question would be on the MF Discord server, in the MSFS2024 channel. Sorry but I don't have this aircraft so cannot really look into this in more detail. John

The FSLabs uses custom controls via the Rotor Brake control for the lights - you can see this if you set logging for Events, open the logging console and flip the switches in the VC. I provided information on how to set-up the lights in this thread: You can use the attached macro file which has macros for the Nose, Strobe and Beacon lights: FSLA321.mcro For any other lights/switches, try logging the event(s) used and either assign directly (if only one event) or add another macro to that file to send multiple events. John

Nothing was working before you installed that (was it?), so you mustbe using the old USB-type model and so that is needed. That is not really an issue, as the menu entry would only display the PFC driver version number anyway. Not sure why that is no longer added though. This menu entry used to go on the P3D/FSX add-ons menu, and it may not have been updated to go to the FSUIPC7 add-ons menu. That is not really an error - you add this file to override the default assignments. You need to read the documentation that comes with the driver - the PFChidDLL User Guide and take a look at the PFCmacroIndex csv file If things are not working correctly with the default assignments, you can create macros (in the PFC.mcro file) to override the default assignments. You can use logging in FSUIPC7 as well as in the PFC driver (as well as the PFCmacroIndex file) to determine what macro can be used for each switch (and maybe axis, but I am not sure). Many aircraft in MSFS2020/MSFS2024 do not respond to the standard FS controls which will be the ones used by the default assignments. They can use things like lvars, hvars, input events or custom controls instead of the default FS controls, and can be specific to the aircraft being used. For these, you will need to determine how they work and override them by providing a macro entry. For the trim, you can use FSUIPC/PFC logging to see what is being sent, and can also override the default assignments with your own macro. You can also maybe see if there are any other PFC users with the same console in the FSUIPC7 sub-forum and maybe ask them (either via a message or tag them in an existing post). Your log file does show a few issues: 1. There were a few reconnection attempts (and one looks forced for some reason). You should tune the start-up parameters (or let FSUIPC auto-tune these). See the Advanced User guide and/or the FAQ entry (in the FAQ section of these forums) on this 2. The WebSocketServer is being started - disable this unless you are using it. 3. You have not installed the FSUIPC WASM module. This is not a problem, but you need this if you want to use lvars, hvars, or presets (which are useful for pretty much all aircraft), Install this unless you really have no need/intention of using these. Sorry, but other than that I can't really help any further with PFC products. I don't have any and have never used them myself. The driver is pretty old now (way before my time!) and is provided as-is and is not really supported any more (by me!). You can also try PFC support. Good luck! John

Profile matching can either be done on Title (simvar) or the folder name of the aircraft directory (aircraft.cfg location), the latter by using/setting the UseAirLocForProfiles ini parameter, but not both. It doesn't make sense using both for profile matching, as the name (aircraft title or folder name) is automatically saved and will only match one. However, yes, I can check both to determine if the loaded aircraft is a PMDG aircraft to start the PMDG-specific threads to load/update the PMDG offset area - thats a good idea. Yes, sorry - I should have known that from what you have already said! Could you please try the attached version with MSFS2024 and show me the log file afterwards so I can check to see if the PMDG threads have been started? This version also checks for the string 'pmdg' in the aircraft folder name to determine if the PMDG threads should be started. John FSUIPC7.exe

I have moved your post to the FSUIPC7 support sub-forum, Please use this forum for all questions/issues with FSUIPC7 and MSFS2020/MSFS2024. For newer PFC HID devices, you do not need any additional software. You should be able to assign directly using FSUIPC's assignment panels. However, I think the PFC Cirrus II Pro is a non-Joystick type of HID device. If so you'd need to install the PFChid64.dll. You will not see the PFC menu in the Add-ons menu until FSUIPC7 is connected to MSFS and you may even need an aircraft loaded and ready-to-fly. The log file you attached shows that MSFS wasn't even running. See this thread/comment and later:

Ok, that makes sense. However, this still presents a problem... As the title of the aircraft doesn't contain 'PMDG', the additional offsets available for PMDG aircraft (provided by the PMDG SDK) will not be populated/available. I will need to update FSUIPC to handle this. Do you also use MSFS2020? If so, is the title in MSFS2020 the same?

I currently only have the 777-300er, which is only compatible with MSFS2020 at the moment. I will see if I can get hold of the 777-200er. John

Ah, its the 777-200er...I do have this for MSFS2020. Saw this was now missing for OC2 and so have installed OC3, but I can't see how to install the 777 in MSFS2024.., I will try and get this installed and take a look...

Why is this an issue? Surly the PMDG B772er has a title - and will contain 772 and not 777. Did you add the title of the aircraft to your profile? i.e. when the aircraft is loaded, go into one of the assignment panels and click the 'profile specific' checkbox and then select your PMDG profile. You should then look at the name/title added and shorten that to a substring. However, as the livery name is separate from the title, this may not now be necessary. FSUIPC does not read the aircraft.cfg file for the title, or livery name - it uses the simvars, which were populated from the aircraft.cfg file. If this information is no longer available in the aircraft.cfg file, it must be available somewhere and it will be MSFS that gets this information to make available in the simvars. Are you saying that there is no title now for this aircraft? Could you please show me / attach your FSUIPC7.log and FSUIPC7.ini files, generated after a flight using the PMDG in MSFS2024 and I will take a look. John P.S. Is the SDK (header file) for the PMDG B772er for MSFS2024 the same as the one for the PMDG 737 for MSFS2020? Do you use the specific PMDG offsets? Maybe you could attach the header file for me and I will take a look, Not needed

You have NO aircraft name strings in your profile: How do you expect that to work? I suggested to use this: I also explained how this works: And explained what to check if a profile isn't loaded: Why is this not clear? Sorry but I don't know how else to explain this.... John

No problem.