Pete Dowson

Oh, good. I evidently misread your post on that. Pete

You need to enable "ipc Read" logging in the Logging tab, as I said. Else it won't show anything relevant to any application connection! Then just compare what the read lines show to what I posted earlier. Pete

It's only an "FSUIPC error" only to the extent that if the application asks for, say, and FSX connection, and FSUIPC is running in P3D, then that error is returned by the code supplied to programmers to show how to interface to FSUIPC. But as far as I can determine (without ADE's code), it doesn't. -- It connects asking for "any FS", in which case this error cannot be returned. And it is fine with me and with srcooke. But you need to check with ScruffyDuck on this. I'm not hacking their code (that's actually here the check is being made --it happens in the ADE process AFTER the FS Version number is returned to it in the way I described above, with the Log. (Did you try logging to compare your results?). Pete

That makes it sure that it is using WX format data, weather on file or downladed. Pete

What is the GF-46? sorry, I've clean forgotten their numbers. GFDev.dll is a 32-bit module, it doesn't work with P3D4. You need GFDev64.dll in the P3D4 modules folder. Both versions of GFDev are provided by GoFlight for programs like FSUIPC to handle their devices. There are reports of inconsistent working of USB devices when connected to USB3 sockets (the ones with blue showing). Make sure you plug into a USB2 socket. If that doesn't work you need GoFlight support. Pete

1.77? My 1.76 says it's up to date when I ask it to check for updates! Pete

It's ADE which has to connect with FSUIPC, not the other way around. And it is ADE reporting the error. I'm using the exact same ADE version and it connects okay (I have !autoconnect" checked in ADE, so it connects straight away). I just ran it again.with IPC read logging enabled. here are the relevant parts of the log: ********* FSUIPC5, Version 5.151 (20th March 2019) by Pete Dowson ********* Running inside Prepar3D v4 Module base=7FEADCE0000 Windows 7 Ultimate 64 Bit with SP 1.0 reported as Build 7601 (OS 6.1) Prepar3D.exe version = 4.5.11.29713 Reading options from "E:\Prepar3D v4\Modules\FSUIPC5.ini" ... 555161 READ0[10228] 3304, 4 bytes: 00 00 51 51 ..QQ 555161 READ0[10228] 3308, 4 bytes: 0C 00 DE FA .... That's reading the FSUIPC version and the P3D version (the "0C" at 3308 would mean P3D4). the "DE FA" is just a validity check on these 8 bytes. ADE isn't reading the specific version details in offset 3124 which would give and then this sequence repeated every 100 mSecs or so: 555255 READ0[10228] 0020, 4 bytes: 48 19 00 00 H... 555255 READ0[10228] 0560, 8 bytes: F8 FF FE 9F B2 47 57 00 .....GW. 555255 READ0[10228] 0568, 8 bytes: 08 00 C7 6B 65 8E A7 FF ...ke... 555255 READ0[10228] 0570, 8 bytes: 00 00 3F 3A 1C 00 00 00 ..?:.... 555255 READ0[10228] 0580, 4 bytes: BB 3B 82 BF .;.. 555255 READ0[10228] 3210, 224 bytes: BE 00 00 00 4F 00 00 00 4D 00 00 00 00 00 00 00 ....O...M....... 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 555255 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ which is reading ground altitude, aircraft location, altitude and heading, plus the Hot Key list, where is seems to have set 3 hot keys -- the .> key, the letter O and M. Not sure if those are options I set long ago and forgot or are defaults. Pete

Sorry, I don't understand. How does that cause anything to "stall". What actually "stalls"? Okay. So what else is needed? Isn't the switch ON already programmed to obey your hardware switch, as you just said? Doesn't the ProSim overhead reflect that switch position? I'm not sure what else you need? I use Prosim but I've never programmed anything other than the overhead switches being recognised by Prosim, as you have. Incidentally, ths question is really better placed in the Prosim support forum. They are sure to know more about their software and their aircraft. You've done all you have to do by getting the switch recognised. Pete

Surely it's main job is managing the Simulation, setting the values you see on its readouts and the state of its buttons and switches in the Sim. Also, of course, its main job -- controlling flight in autopilot and autothrottle modes! It's the PM MCP's job to obey your inputs from your hardware MCP.. The GC displays will/should show the values and settings as read from the sim -- I am pretty sure the PM MCP does not do that. It wouldn't make sense. From all you've said it sems that the hardware MCP is also displaying what it sees in the Sim, BUT the hardware switches and so on aren't seen by the PM MCP. So, bassically, you have two MCPs working independently and fighting each other with respect to certain switches and buttons. I really don't know if the CPFlight MCP is intended to be used with Project Magenta or not. but if it is there should be some sort of driver or instructions to help set that up. Didn't Enrico ask about that? Does he know about the CPFlight MCP? But that could be the CPFlight setting the values directly into the Sim, and those of course being reflected on the GC displays (because that's certainly where they'll get them from), and on the MCP. Where you get the difficulty, the AP and AT button/switch, is likely because the autopilot and autothrottle are controlled by PM -- it overrides the built-in automatic systems. Everything you've said really points to there being no actual communication between the hardware and softare MCPs. Yes, he's often away tied up in his commercial sim ventures. He also has a family and does go on holidays. You need to try the PM Forum and the CPFLight one too. There must surely be other users with both. Yes, and really you need the complete cockpit. It isn't so suitable to a PC with the odd bit of hardware. I think you'd find the whole Project Mgenta suite not far off that price now too. I don't use PMDG aircraft, but here's what I think: The PMDG aircraft are complete. They have the full cockpit and every system is simulated. They are excellent for a good PC with you basic necessary controls -- yoke, rudder with toe brakes, and throttle quadrant. They don't need anything else, but you could use units with switches and buttons, like those from GoFlight, to operate it. I think there's even a "tabletop" overhead which has a driver for it (VRInsight?). But unless there' are drivers or third party software for hardware like MCPs, EFIS, CDU it can be a lot of work, involving some programming, to interface them. The PMDG Boeings all have a published list of controls which are "custom", not FS controls, to operate every switch and dial, and even for using the CDU, but that's a lot of assignments to make. For read-outs of values for display on external hardware there are offsets mapped in FSUIPC to be used, but obviously that needs programming if there's no driver already made for it. The PFD ND and EICAS displays can, I think, be undocked and moved to other screens on the same PC (but i may be wrong there). All the above is only my understanding (except for the FSUIPC offsets and programmable <custom controls>), but you need to go the other Forums to seek real users opinions. I know there ARE users with external hardware and using PMDG aircraft, but I don't know what software they are using. Another 737 which I think can be used in a distributed hardware setup, including networked ones, is the iFly one. That might be worth investigating. Otherwise, sorry, I don't really know. You should be able to sort things out with Project Magenta which might remain your best bet since you have it already. Ask around in the Forums. Pete

Sorry, i don't understand. What serial driver? Do you mean my own PFCcom64.dll? That doesn't need "installing" excpt to place it into the P3D4 modules folder. When it is first loaded by FSUIPC it will make its own AddOns menu entry and in there you can set the correct COM port it needs to use. Pete

Okay, so it is Project Magenta's control of the simulator via the PM MCP. Are you sure the MCP responds to the CP Flight bittons, dials and switches as well, because it should be the PM MCP in charge. Surely you shouldn't need to do that! If PM is reading the CP Flight MCP switches then PM should be handling the interface to the sim, whether via FSUIPC or not. The problem seems specific to PM's MCP program, and i really cannot help there. Enrico knows how to use FSUIPC logging et cetera to see whether his software is connecting a working well -- and from what you say it must be for many things if the GC displays are responding to the CPflight MCP? He shouldn't need to use Teamviewer to contorl your system, just asking for the appropriate logs should help him. I did use PM years ago but long since gave it up in favour of ProSim. Maybe the PM suppot forums will help -- there must be other users. I don't know how many PM users are using PMDG. Very few to none I suspect. The PMDG system is complete, it has all its own subsystems. External systems programs like PM and ProSim are then rather redundant. Pete

Exactly. That's the idea. You are supposed to make all the macros for the aircraft in one session, or at least all for each major part of the cockpit. You can add more later just by specifying the same macro filename. But normally it is far quicker and easier just to click "start macro making", specify the name you want, then make yor macros for every switch you want. Only when you've done go back to the options and click "end macro making" which will save the file and make the macros visible in the assignments. However, in your assignments every macro assigned with have a macro file number (the one in the [MacroFiles] list) and a Macro number (the number of the chosen macro within that file). If you now edit one of the files to add all the others to it then a) you need to be sure to number the macros sequentially as you add them, and b) entries aren't automatically deleted from the [MacroFiles] list. As you deal with each file and delete it you need to delete the entry for that file too. Also c) once you've done you'll need to reassign them all because both the file number and the macro number will change. Pete

Ah, sorry. When you say "PM 737" do you mean Project Magenta? They have a 737-800? If so, my mistake. The PMDG 737NGX is the most popularly used 737 model around so I thought that was what you meant. Best if you are more specific, saying "Project Magenta". If you do really mean you are using Project Magenta software with their aircraft and their MCP, then everything should work fine if you keep to PM. Your FSUIPC INI file only contains 2 button assignments: 0=P0,30,C65792,0 -{AUTOPILOT_ON}- 1=U0,30,C65791,0 -{AUTOPILOT_OFF}- which will work directly with the PM 737 I think because as far as I can recall the latter is basically the default FS aircraft with all the same controls exactly. However, the A/P on and A/P off controls should only operate the AP button on the MCP. The "AP DISCONNECT" is a larger lever-type switch below. And you have no assignments for the A/T. This is the crucial statement:in your message: This implies that CPFLight's MCP isn't compatible with PM's MCP. I'm not sure how having to MCPs is supposed to work. both have switches and buttons don't they? What does this part mean? What did you "try" and what were you doing before? Assigning to FS controls in FSUIPC is the same as assgning them in FS itself. I'm sorry, but so far I don't really see where FSUIPC comes into it. I know Project Magenta uses FSUIPC to read its data from FS, and to send its own controls to FS, but then where does the CPFlight MCP come into the equation? Pete

In that case it is a sure thing that something about the weather in the area in which you get the problem is corrupting things in SimConnect or elsewhere. So is there then no weather? Or is P3D getting some weather from somewhere? Maybe it's more related to the weather settings in P3D, though if that were the case it would be affecting a lot of folks. There is one other file you can try deleting before running P3D (after re-enabling weather in FSUIPC as a test): "wxstationlist.bin", which is in your AppData\Roaming P3D folder. This shouldn't make any difference because FSUIPC should be deleting it at the end of each session in case it got corrupted. P3D restores it from its default when it finds it not there, -- that's in the P3D Weather folder. Maybe that one is corrupted. I don't know what P3D does if you remove that one (if you try, make a backup somewhere). However, usually a corrupted wxstationlist.bin file will cause the crash straightaway, and is not depndent on where you fly. So this avenue seems unlikely to bear fruit in any case. Pete

It looks like that is because, inexplicably, you've made a separate file for each individual macro control. The idea is to make all the macros for one aircraft, or rrather one cockpit type, in sequence so they all go nto one file. That's why there's a separate "Start" and "End" macro making action in the Options. I really don't know what you mean by this. You can't. You need to take all the macros you made for each single aircraft and put them all in one MCRO file for that aircraft or aircraft type -- eg FA18.. You'll have to renumber them all to do this, which means you'll need to reassign them all. Pete

I don't know IVap at all I'm afraid, but there's no change whatsoever in what FSUIPC does for anything involving offset 7B91. Is that way of operating the Transponder mode supported by iVap, for P3D4? It was a Squawkbo thing. Is iVap interfacing to FSUIPC? Ifso , is it an EXE or a DLL? Does it say it is connecting? Or is it using the SimConnect Client data named "Squawkbox Data"? Is iVap using that? Use FSUIPC's logging to show changes in 7B91 -- Logging tab, right-hand side. enter it there as yype U8 and check "normal log" before. Then the log will show what it does. Does it changes correctly? Then you will probably need iVap's help. Pete

Okay, so CPFlight's MCP comes with a PMDG driver? Because the PMDG controls are not standard P3D controls. The PMDG autopilot is most certainly not using P3D controls. You need to assign to the custom controls published by PMDG. Sorry, I don't know what's going on there. But you need to use the 737NGX's own controls. There's a list in PMDG's own documents -- see the 737NGX SDK folder. The .h file there lists them at the end. you assign by number in FSUIPC as <custom control>s. Pete

PMDG implements its own autopilot and obeys very few of the built-in FS controls. You'll need to either use a mouse macro, or, better, assign directly to the Custom Control aavailable for this for (at least) the Boeing B7x7 series of PMDG aircraft. There's lots of help here already posted for PMDG controls. See the User Contributions subforum for instance. Pete

You need to click "end" macro making in order to get it added. FSUIPC is probably waiting for any other macros you might make for the same file and then to close the macro making session. Also, like LuaFiles, the Macro list is limited to 127 entries. Check that in the FSUIPC INI. It applies to Macro (or Lua) files, though. not macros -- so, providing you keep all macros for a particular aircraft in one file, the you should never actually exceed this limit. Pete

FSUIPC doesn't care where you are and does nothing differently in any place. But it does always read the weather -- using standard SimConnect facilities. The trouble usually is that bad weather fies (.WX types, in your Documents folder) will cause crashes either in the SimConnect parts of P3D or elsewhere, even possibly in FSUIPC. Unfortunately, though these files are in a precise binary format designed to fit directly into tables in P3D, SimConnect appears to do no checks on them at all. Since you are using an external weather program you don't really need the .WX files, so as a test first try deleting them before starting P3D. If you do this no more will be created until you save a flight. You can also stop FSUIPC doing any weather actions whatsoever -- a rather extreme measure, but good as a test. This is by adding NoWeatherAtAll=Yes to the [General] section of FSUIPC5.INI. In case it is really a scenery problem, note that uninstalling some scenery files does not clean out al the files they mayhave installed or modified. The uninstallers vary quite a bot. And uninstalling P3D won't remove files which it didn't install in the first place. You need to manually delete all the left-overs -- from the Documents, AppData and ProgramData folders as well as its installation folder. Pete

Delete the line stating the aircraft name in the FSUIPC INI file, in the Modules folder. Aircraft assigned to a Profile are listed in the section entitled [Prifile.<profile name>]. BTW you posted your support question in one of the reference sub-forums, where it won't be answered. I've move it for you to the proper Support Forum. Pete

Unfortunately the crash location doesn't appear to correspond to any particular part of FSUIPC5. But there is one other thing to try, as well as those suggested above. Let FSUIPC5 act with the weather data as normal (i.e. remove the "NoWeatherAtAll" line if you added it, but change your AppData copy of DLL.XML as shown in red below: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>FSUIPC 5</Name> <Disabled>False</Disabled> <Path>D:\P3D V4\Modules\FSUIPC5.dll</Path> </Launch.Addon> <Launch.Addon> <Name>as_connect</Name> <Disabled>True</Disabled> <Path>as_srv\as_connect_64.dll</Path> </Launch.Addon> </SimBase.Document> This will stop the Active Sky module loading altogether, so at least show one way or the other whether it is the FSUIPC calls into it which crash/ Pete

Hmm. The changes since then a pretty minor. Have you tested after removing all your .wx files as suggested? That's nothing to do with FSUIPC, but if Active Sky's module is being loaded then FSUIPC will connect to it and if the module is corrupted or the wrong version for this build of P3D4, then it could cause FSUIPC to crash. The message from Active Sky does mean that its module can't interface to that version of P3d4, so in turn it implies either a bad ASP4 DLL or the wrong version. Could you make sure your Active Sky is up to date? If not update it, if so, perhaps try re-installing. The DLL module it uses is changed for each build of P3D4 because it hooks into the P3D4 code. The fact that FSUIPC 5.15 didn't crash doesn't mean it was okay with this. Even small changes in code and the subsequent re-compile can move data areas around and so change the events which occur on corruption. You can check that it is to do with weather by stopping FSUIPC doing any weather activity. Temporarily, to check this, add NoWeatherAtAll=Yes to the [General] section of FSUIPC5.INI. YOUR FILES The FSUIPC5.zip just includes FSUIPC5.DLL -- i.e.the module supplied by use and installed for you. why you sent us back our own module i don't know FSUIPC5.LOG -- as requested, and the most important but not the FSUIPC5.INI file requested. I assume this is the log after the crash? so the place it got to is as far as it logged anything before the crash? There's nothing obvious showing up. I'll check the crash location. Pete

What was your previous version of FSUIPC5? Is is registered? The error is ERROR_SERVICE_REQUEST_TIMEOUT "The service did not respond to the start or control request in a timely fashion." but of course FSUIPC is not the "service", so something in Windows is timing out. We need much more information in any case. The location withing FSUIPC would be known, but not without the Log, for instance. This could be due to a corrupt WX file. Try moving all of them out of your Prepar3D Documents folder. Or it could actually be a scenery problem. Is it always in the same area of the world, over the same scenery? And what add-ons are you using? A list of those would be useful, especially any that use FSUIPC. Also please show us these files: Your DLL.XML and EXE.XML files, both froom your ProgrmData folder and from your User AppData\Roaming folder for P3D4. Also we always need your FSUIPC5.INI and FSUIPC5.LOG files, from the P3D4 Modules folder. You can attach to a message here, but please ZIP them first. Pete

Sounds like you are running FS "as administrator" then. Programs need to be at the same privilege level in order to share memory, part of the data exchange protocol. Pete