jimbooo

ok ill go back there and see what we can figure out. The PFC equipment is sooooo nice and well built AND is perfect with XPLane so I would like to make it work with MSFS. your program does that very nicely - except for the RSG integration. I will stay on the quest thanks for your help along the way Jim

as you suggested I did the exit from FSUIPC during a flight and th AP behaved exactly as you guessed - 500 did not work at all. one question before i goto RSG guys again - in the FSUIPC folder is the interface for my PFC equipment. is this a program you wrote or did that come from PFC??? anything in there that i should explore ??? im thinking the PFC guys may be relevant to my problem. they are not too responsive to any MSFS dilemmas - they mostly just say they only care about XPlane. i get that attitude but the damn graphics are so much better in MSFS than XPlane that i still want to make this work if possible. any hints for my quest ??? thanks again for spending the time here Jim

thanks for the suggestions - i will print them out and try all of them and report results. Jim

the RealSimGear 650/750 and 500AP work in almost any plane even if they have different specific units in the virtual planes. My only experience is in XPlane where these units work fine in all planes. The PFC equipment is designed to work with XPlane and does so perfectly - and with no conflicts with the RealSimGear units. No need for FSUIPC in this configuration. MSFS does not work at all with PFC equipment - thus the need for FSUIPC. Im not sure what you mean when you talk about "assigning" in FSUPC.? i simply installed FSUIPC and without doing anything it controls my all my PFC equipment. My only issue is some sort of conflict with the RealSimGear Autopilot. the RealSimGear 650/750 work fine with no conflicts. i will try logging "buttons and keys" to see if anything shows there as you suggested. i have not tried to exit FSUIPC mid-flight as i would immediately crash without the PFC equipment running. i can try that to see if there is anything i can see - how would i shut it down midflight ?? i will try some more experimenting and let you know what i find and re-contact RSG support again thanks for the time so far, John.

another 172 flight just now - AP on then off on the ground same as yesterday. most button pushes will log but not light or become active. very different flight than yesterday.... once in the air the AP will arm and stay lit but the rest of the buttons worked differently than yesterday. the HDG bug will log increment and decrement but NOT the pressing of the HDG button. Once again the plane would follow the bug after the HDG button was pressed (no light shows). then i pressed the HDG button again and the plane stopped following the bug. the press of the HDG button again did NOT show in the log - only the increment/ decrement logged. for this flight i had the 650 and 750 working to test the NAV function and pushed the "Direct" button and entered a nearby airport. the route showed on the 750 and all events and buttons logged properly. I pressed NAV and the light lit properly and the plane tracked the route properly. tried to go back to HDG just to see how it acted and it did the same as before - no light and no logging of the HDG button but the plane would follow the bug until i pressed HDG again and then it stopped. Apparently the HDG button IS engaging / disengaging the AP but the button presses do NOT log.... the VS speed is entered on the PFC radio panel and logs properly in FSUIPC log but does not operate as it should. i can get the plane to climb or descend but the lights and button pushes are not working as they should. i havent detailed or tested the VS procedure very exactly as Im trying to stay focused on the major malfunctions. i decided to try an ILS landing since the NAV function was working. the plane followed the appropriate nav route and switched the 750 GPS to VNAV at the appropriate time - however once the VNAV was in control nothing now worked to link the flight to the route. HDG, NAV and APP would not arm - therefore no ILS route or glideslope. landed manually and had a rum and coke........ ps when i was first researching these malfunctions i called support at RealSimGear. he logged into my computer remotely and looked around a bit. he magically went to some screen and was able to disable FSUIPC with the idea of starting a flight without it running. we did this and that was the basis of my report earlier that all the AP seemed to work and all lights operated properly. since FSUIPC was not running i could not fly the plane to test in actual flight but all the lights on the AP lit as they should - at least on the ground.

updated to 7.4.8 as instructed. i did one flight as yesterday in the 172 - on the runway before departure the AP did the same as previously reported. no buttons would light and the AP engage would light for about 1 second then turn off. i decided to takeoff manually and levelled off. now the AP button would light but no other buttons would light. with the AP engaged i could keep straight level flight. apparently the ALT was operating but was not lit. just as an experiment i centered the HDG bug and hit the HDG engage button. it would not light but as i rotated the bug the plane followed ? if i hit the HDG button again the plane would stop following the bug - again at no time was the light lit. shut down MSFS and went to bed..... i did not save any .ini or .doc docs. i read your instructions today and set the log to "EVENTS" 172 on runway ready for t/o. AP only lights/arms for 1 second then off. other buttons show in log but do not light. once airborne amazingly most of the lights work and AP arms. HDG lights and seems to work fine. ALT hold lights and is working. My VS and target altitude are set on my PFC module and it works somewhat but will not allow me to set my target altitude. all the button presses and knob adjustments are logging in the FSUPC log for both the PFC and the Real SimGear 500AP. i kept the log open as you suggested. very odd behaviour as i did the same thing yesterday and nothing worked. this erratic behaviour is puzzling ? i have attached the files you requested. i am headed back to the sim to do more experimenting. this hobby is sometimes frustrating.... than you for the help.... FSUIPC7.ini FSUIPC7.log PFChid64.log

in response to another of your questions: yes if i do NOT run FSUIPC the RealSimGear AP works fine in MSFS 2020 - but of course then the entire PFC console and radios do not work. thus my dilemma - the PFC equipment need to be operational - but then the RealSimGear AP doesnt work......

i see from your last message that you wanted me to activate EVENTS and BUTTONS andKEYS. i dont think i did this - i can re-do the 172 flight again tonite if my attached files dont show you the pertinint info let me know

scenario 1: started MSFS normally and loaded the 172 and activated the flight. once ready to fly i tried all the buttons on the RealSimGear autopilot. none seemed to work but the AP on button would light for about 1 second and then go off. i went into the virtual cockpit and tried the AP buttons there with the same result - nothing would activate except the AP on button and then turned off after 1 second. stopped flight and went back to main screen. scenario 2: loaded the Beech King Air and activated the flight. On the runway ready for takeoff the AP seemed to work mostly. Took off and tried the HDG, NAV and ALT buttons and they seemed to work OK. The IAS system would not take my preset altitudes but did respond to VS settings. I was flying in the Caribbean and there were no ILS runways nearby so i tried an RNAV approach and it seemed to work OK but some of the indicator lights on the RealSimGear AP were not registering correctly but the plane did seem to be controlled by my settings. exited the MSFS program and copied the attached files. very odd that the 172 would not work at all yet the KingAir mostly worked ? I think I tried the Baron and it would not work at all - much like the 172. Most of the MSFS included planes will not work at all with the RealSimGear AP - nor with the virtual cockpit versions of the AP. FSUIPC7.JoyScan (1).csv FSUIPC7.JoyScan.csv FSUIPC7.log

thoughts: the PFC driver is active in order to get the PFC equipment recognized by XPlane. it is supplied with the PFC equipment and was designed specifically for XPlane. Everything in XPlane works fine as does the RealSimGear autopilot with no conflicts apparent. MSFS 2020 does not work at all with the PFC equipment or their programmed driver - for use with MSFS2020 i use your FSUIPC7 program and it works fine as far as the PFC equipment is concerned. my problem is strictly with the RealSimGear autopilot when in the MSFS2020 program, I will get you the files you requested and I understand you will be gone until Tuesday. Have a nice weekend...

ps the RealSimGear equipment is NOT a PFC device and is not controlled by the PFC driver - at least it is not evident in running XPlane as there are no conflicts.

now that i think about it there is certainly a PFC driver that controls all the PFC equipment. i dont have the PFC autopilot module but likely the programming is still there and may be conflicting at some point. However: 1. the same PFC driver is active in XPlane and the RealSimGear devices all work properly with no conflicts 2. when i removed the FSUIPC7 program and ran MSFS2020 without it running the RealSimGear autopilot ran perfectly 3. i have not "assigned" anything in FSIPC. I simply install it and let 'er rip. Looking in the commands in the FSUIPC program there are all the normal autopilot commands "HDG" NAV" "VS" etc. Im assuming those are present to operate normal autopilots installed in most planes. This may be the conflict ??? given the above I will provide you with the logs you requested. I will likely got to my computer later today thanks for your response Jim

i am using fsuipc7 with MSFS2020 in order to get my Professional Flight Controls C2 console working properly. I also have the PFC professional radio stack. My installed FSUIPC7 works fine with all that equipment. I also have a Garmin 650 and 750 and GTN 500 autopilot from Real Sim Gear. The 650 and 750 work fine but the 500 Autopilot commands conflict with the FSUIPC commands. If i run MSFS2020 without loading FSUIPC7 the autopilot works fine - but then I cant use the entire PFC console or radios !!! so I need to have FSUIPC running but then I get the conflict with the Real Sim Gear GTN500 autopilot. Is it possible that i could simply edit OUT the FSUIPC autopilot commands ? Would that likely eliminate the conflict - or would that create more problems ?? If so could you tell me where I would find the command list - is it in the .ini file or ???? any help would be appreciated thank you Jim

My problem is no longer from any PFC device. I do not have the PFC autopilot. All PFC devices are working properly. I have instead a hardware dedicated AP from RealSimGear.(RSG) I think the problem is some conflict with the RSG control program conflicting with FSUIPC. If i hit the ON button on either the RSG AP hardware or the virtual cockpit ON button the AP flashes to ON for a second and then OFF. 1. If i hit ON on the virtual cockpit AP the FSUIPC command is sent but the RSG does not see that command and since it is in the OFF condition it overrides the FSUIPC command and the AP reverts to OFF. 2. If i hit AP ON on the RSG hardware autopilot then FSUIPC doesnt see or interpret that command and, since it is in the OFF condition the AP again reverts to OFF I will experiment over the weekend and report back on Monday have a nice weekend thanks

at this point, with your help FSUIPC7 has properly connected to my entire console and radio stack in MSFS2020. If you remember it was the Professional Flight Controls (Cirrus Pro 2 console and radio stack). all the various instruments are receiving the correct input from FSUIPC. I have another issue that has shown itself. My autopilot (AP) is a separate freestanding piece from RealsimGear and has an interface that drives that piece. Since that piece of gear is not addressed in FSUIPC it obviously does not respond to your code. The net effect of that is that when i try to do any setting on the hardware RSG AP - the RSG programming conflicts with FSUIPC and the net effect is that the in plane AP does not respond. If I try to do any settings on the virtual AP the 2 programs apparently still conflict and nothing happens. Therefore AP is unusable. If I unplug the RSG AP then the virtual AP works fine with the commands from FSUIPC. I would like to use the RSG AP if possible. sooooooo Im thinking if i remove (edit) all the FSUIPC commands that pertain to the operation of the AP - that should allow the RSG program to work unimpeded. Is that a reasonable hypothesis and, if so, is there any easy way to do that ??? Any direction would be appreciated thanks Jim