zfehr

JetBrains DotPeek said neither the TestGUI nor the rxpgnsdriver were supported so that answers that question!

I know. I wonder if I am up to getting a decompiler and seeing if opening up that rxpgnsdriver.dll would reveal anything to me?

It worked! Quite excited to see something being read with button pushes on the PFC430 hardware in FSUIPC. Now I need to figure out what to do with it and see if it correlates with the log I have from the PFC test GUI because that lists button function. HidDemo.lua FSUIPC7.log

PFC told me that the PFCCom and PFCHid files are supposed to work in conjunction with FSUIPC but the stickler is they were designed to work with RealityXP's Garmin GNS430/530 programs and they do when accompanied by the RXPGNSdriver.dll to run the RXP Garmins in FS9 and FS10. RXP Garmin is not available for MSFS2020 so PFC does not have a responsibility to make the hardware work outside of its original design criteria. I will make the edit so the Auto section also has Lua preceding in it (I wondered if I needed to add that when reading the instructions, I wasn't sure if the file in the instructions had Lua in the name or that was needed preceding the file name). Thanks, Zane

OK, I put the HidDemo.lua script with edits for the product and vendor. Removed PFChid64.dll from FSUIPC folder, the PFC Test GUI is not running. Log Buttons and Keys, logging console open and forced on top. I see no interaction with any button press on the hardware. Attached logs and .ini file. HidDemo.lua FSUIPC7.log FSUIPC7.ini

Thank you, I will not use that selection in the future.

Hey, I'm trying here. I'm not an IT specialist or software engineer. I'll see if I can figure out how to get this full log.

Here is the log file and as you can see no button presses are acknowledged. I did further testing using Windows 10 "setting up USB game controllers" and the PFC430 is recognized as a USB device and 32 buttons are assigned to it but when I press them using that test they do not activate. I think there is a "tickle" sent by the GUItest program that powers up the buttons as well as the RealityXP dll's also sending a signal that then gets a return from the hardware. I left the GUItest program running and tried the "setting up USB game controllers" to see if that would make a difference and it didn't. My assumption at this point is the USBhidPlugin.xpl (for xPlane v9) and rxpGNSdriver.dll (for FSX with RealityXP GNS software) both are sending something to the USB hardware that is then read coming back to the computer and without that signal the unit is a brick in MSFS. FSUIPC7.log

Thank you, I will perform that and post the log. I will have to see if there are any specific drivers PFC had me install, possibly RealityXP had one so that it only communicated with Jean-Luc's programming.

The post in January was because I thought the buttons and knobs were recognized in an earlier version. The earlier hardware failed and I had to purchase a replacement. I am perplexed that the USB controller card is recognized and reports the unit as a joystick in FSUIPC but none of the keystrokes are recognized. I thought the data provided from the PFC430 diagnostic software may have information that could lead to me making a manual edit entering all those alpha numeric sequences that would make them be recognized in FSUIPC.

Thank you John. If I could just get FSUIPC to recognize the button presses and knob turns on the USB PFC430 I could have something to assign to. Wishing Pete a wonderful vacation.

My present work around has been to program the lower right two buttons on the radio stack (labeled CON and INSTR) to swap the ADF frequencies from standby to active in FSUIPC. I just have to keep my head in the game since then on the radio stack turning the tuning knobs changes the standby on the radio stack itself, then pressing the FRQ button on the radio stack swaps them on the radio stack to active and loads that frequency to the standby frequency in the sim... than I press the corresponding lower right button to swap the ADF frequency in the sim (1 or 2) that will now be active in the sim. Those buttons do have functions in the FAA certified xPlane v9 which I also use with the sim for IFR currency but I find MSFS 2020 so much more enjoyable when I don't need to log the time.

fresh logs with updated PFChid64. I pressed all buttons on PFC430 hardware Log for PFCCom64 pressing ADF swap button then BFO button which is set to switch unit to ADF2 and again pressing ADF swap button. PFChid64.log PFCcom64.log FSUIPC7.log

PFCcom64.ini

I created the file since there was no PFC.mcro file in the FSUIPC folder and I noticed that FSUIPC seemed to be looking for it. Thought it might populate but seems that it is a file I need to enter something in to. I am starting the sim up now to get the files with the sim running as requested.

The PFC.mcro is empty. PFC.mcro

Hi John, Yes, the default action from the PFC radio stack ADF swap is bypassed and the standby frequency will now appear active. But the PFC radio stack now doesn't function correctly and you lose the ability to swap frequencies when using the radio stack to control ADF2. I was just thinking that something in the PFCCom64.ini was sending this particular frequency to the standby instead of the active and that could be altered in that file. In the .ini file the ADF has these entries: ADFmode=0 ADFsb=816 ADFxsb=0 DME=2048 ADF2sb=0 ADF2xsb=649

I am revisiting getting the Precision Flight Controls PFC430 to control Garmin 430/530 functions in MSFS. FSUIPC recognizes this unit but does not recognize any of the button presses or turning of the knobs. I have a program from PFC which tests the unit for function and also makes a list of the commands. Would that data allow me to make a manual edit to FSUIPC and get this unit to work for programming it to control the Garmin 430/530 GPS units? I have attached my FSUIPC log and PFChid64 log files and a screenshot of the PFC protocol test and text file of that data. PFChid64.log PFC430_data.txt FSUIPC7.log

*** Moved to FSUIPC7 support sub-forum **** I am using an older serial port Precision Flight Controls Cirrus II console with radio stack. The COM and NAV coding work perfectly for all button functions, the ADF swap frequency button sends the frequency tuned in the hardware to the swap frequency location in the sim. I tried assigning that button to the ADF swap in FSUIPC, but since the PFC hardware uses that button in the hardware to switch between the flight timer and standby frequency (as it does in the real aircraft unit) it causes problems with the hardware. The PFC radio stack is also programmed so the ADF can control ADF1 and ADF2 and when in ADF2 mode the frequency swap sends to the ADF2 standby frequency. Can the PFDCom64.dll be programmed so it sends to the active frequency? I have attached my FSUIPC and PFCCom64 logs. PFCcom64.log FSUIPC7.log

Total success with selecting the box for "Select for Preset". Now to find a working lvar for their prop heat and fuel pump, the standard assignments don't animate the switch for prop heat but the amps move indicating it's working.

Do I need to set a value(s) in the range selection boxes?

I have 7.3.17 and will watch for update. I appreciate your work.

Where is the "Select for Preset" checkbox? I only have checkboxes for "Send Direct to FSUIPC Calibration", "Send to FS as Normal Axis", or "Send to FSIUPC Offset"

Thank you John. I finally did get it working and am happy to share. My hardware is a serial port PFC Cirrus II BATD using the PFCcom64 driver to deliver the inputs to FSUIPC7. What ended up working are the following entries in the FSUIPC7.ini file: [Profile.HA420] 1=HJET HA420 Red [LvarOffsets.HA420] 1=L:THROTTLE1_SET=F0xA000 2=L:THROTTLE2_SET=F0xA004 [Axes.HA420] RangeRepeatRate=10 0=17X,1,F,x7000A000,0,0,0,*0.06103888 -{ FSUIPC: offset float32 set/1000, offset A000 (0.000000) }- 1=17Y,516,F,x7000A004,0,0,0,*0.06103888 -{ FSUIPC: offset float32 set/1000, offset A004 (0.000000) }- I did have to manually edit the .ini file with the LvarOffsets (lines 3-5), and add the ",*0.06103888" after the "0,0,0" on lines 8-9 I also edited the WASM file you instructed and set to "VisualFrame" instead of the default 6Hz. Have made two flights so far and it is nice to have the throttle levers working. I will note that the visual representation of movement does not work in the VC so the cockpit looks like the throttle levers remain in their idle position, but the EICAS area on the MFD register the throttle lever position and percentage readouts as well as the "TO, MCT, and Idle" indicators. The VC throttles not moving is a MSFS bug which is also present in the TBM930.

Hi John. I have input this text in the FSUIPC.ini file and then set the throttle1 and throttle2 to the offset and then edited the ini file again with the scaling factor referenced. Not sure if I am doing it right or wrong but I do get the throttle to work somewhat now. Full throttle is TO power, pull back the levers and there is a lot of "noise" making them jump around and if I pull back far enough I do get idle power and then shutoff. Not a usable implementation unless I want a toggle between TO power, Idle and shutoff. When I re open the ini file the scaling factor has reverted to 0.0000000. I have included the * and also tried without. I also tried inputting the two scaling factors referenced in a later answer from Northman changing the positive and negative signing but that didn't seem to work any different.