Pete Dowson

FSUIPC simply chucks the data out to the serial port. If the FTDI diver is providing a COM port number (COMn) and you have set it correctly then nothing more can be done at the FSUIPC end. Your best bet is to use a COM port monitor program to loag what is actually going to that port. Something like the Aggsoft one (http://www.aggsoft.com/) for example. I think that's a payware one, but it might have a trial period which would be sufficient. Else Im sure you can find one which does. Pete

There appears to be a problem with P3D4's SimConnect. Two separate programs should not be able to affect each other's ability to enter its "dialog mode", which is what must be happening. I cannot reproduce the menu problems here, but will keep trying. If I can find a work-around i'll post an update in the Download Links subforum. But it may not be today ... Pete

Unfortunately I do not know Delphi at all, let alone what the difference could be between Delphis 7 and 10. I would think that examining what those differences are should lead you to the answer. All of the Examples provided in the SDK except the C one were provided by other users and tested by them beforehand. Pete

Yes, correct. Ah, okay. Thank you. You made me think you weren't looking there when you talked about the sim assignments being seen. This is strange, as from the logs and CSV you supplied, it has clearly been detected and should read the values okay. And I assume the other detected devices are showing values okay? What about buttons on the device -- are they detected? Pete

It has got to be eiither bad weather data (but that usually crashes the simulator), or bad AI Aircraft textures seen in that area (but again you'd expect the same). Of course, it the end it could be down to any sort of corruption withing the simulator caused by bad data in that area. FSUIPC itself is certainly not aware or nor cares about where in the world you are. It's also unlikely to be only affecting FSUIPC, though that might be the more noticeable effect. If SimConnect is doing strange things that could affect almost any add-in or add-on. FSUIPC is 99.9% dependent on SiConnect behaving correctly. Pete

Yes, there are just a few usually more advanced, add-on aircraft which need this. They handle everything themselves from a level hgher that that at which FSUIPC works. Pete

WideFs doesn't have anything to do with folders. it doesn't use shared folders. It just links FSUIPC's WideServer to WideClient on your other PC, using TCP or UDP protocols. SimConnect does the same over a network. Pete

Ah, you are looking at the Calibration pages. If you assign in P3D, you can calibrate in FSUIPC. But if you want FSUIPC to handle the device you MUST assign the axes in FSUIPC! Please do refer to the user guide. P3D does some automatic assignment, but often gets it wrong. FSUIPC does NOT automatic assignment. It lets you use your devices as you see fit. It really is importnat to read the relevant sectionso of the User Guide. Pictures are provided too! Pete

There's no "ACE" device seen by FSUIPC because there appear to be not entries for it, either in the Registery, or in the list known to the Windows Joystick interface. That is unless it is this one: Product= Plasma-MM2 78 Manufacturer= Beta Innovations Wouldn't an ACE device feature "ACE" somewhere its identity? If it is that device, it appears to have these connection: Details: Btns=64, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R65535,U65535,V65535,X65535,Y65535,Z65535 i.e 64 buttons and 6 16-bit high resolution axes. I note from the Joyscan file that there are two devices with that identity, but one doesn't respond to Joystick interface reads, nor does the interface give valid informastion, like that above, for it. If that isn't the ACE, but another one which you have working (I can't tell if you have any assignments since you didn't provide your INI file), then I'm afraid the ACE is simply not a device known to any interface FSUIPC understands. Pete

What SimConnect applications have you tried? Does it not work for both local and remote Simconnect clients? DLLs are loaded via DLL.XML and EXE's are loaded by EXE.XML. There might be such filles in both the Appdata\Roaming P3D folder, or in the ProgramData P3D folder, or in both. To stop them loading you just neen to rename or delete those files (but if you delete them you may need to reinstall applications). ---------------------------------------------------------------- That SimConnect isn't standard. Belowis a more 'normal' one, though it is possible for some applications to use different ports. Not that the port isn't required for the 'local' support. My P3D system has IP Address 192.168.0.170, and that is only needed for the 'global' entry, as you can see. Pete <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="SimConnect" version="1,0"> <Descr>SimConnect</Descr> <Filename>SimConnect.xml</Filename> <Disabled>False</Disabled> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>Auto</Protocol> <Scope>local</Scope> <Address></Address> <MaxClients>64</MaxClients> <Port></Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> <SimConnect.Comm> <Disabled>True</Disabled> <Protocol>IPv4</Protocol> <Scope>global</Scope> <Address>192.168.0.170</Address> <MaxClients>64</MaxClients> <Port>500</Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> </SimBase.Document>

What drivers come for the PLCs? If they emulate normal Windows Joysticks, with up to 32-buttons per device and 8 axes, then they would be easily supported by flight sims and FSUIPC. Alternatively they might be able to use some other standard USB connections in which case some programming, possibly via a Lua plug-in for fSUIPC would be needed. If they are just plain bits of hardware then you would have to start by programming proper drivers, designing the PC interface, and finally writing a program to drive FSUIPC or a flight sim directly. That might not be good if the devices come with nothing. I'm not aware of any here, apart from a similar question some time ago which basically got the same sort of answer. You'd be better off in a cockpit builders forum such as those on http://www.mycockpit.org Pete

No, you are not reading properly. Here are the relevant sections. I've highlit in RED the part relevant to your misunderstanding: INSTRUCTIONS For: FS2000, FS2002, FS2004 Place the EXE into your main FS folder where the SCENERY.CFG file is located. ... For: FSX, FSX-SE, Prepar3D v1 to Prepar3D v4 inclusive Place the EXE into the relevant main FS folder. ...

Good. I was getting a bit worried as after tomorrow I'm off on holiday for two weeks, and needed to get this release out and working well beforehand because, knowing L-M, they'll release the next P3D4 update whilst i'm away. ;-) Pete

There seems to be quite a few types of P3D crash which don't provoke any error message, it just disappears as you'd expect it to do. Note for instance that the P3D windows disappear quite a few seconds before it is all actually closed, so if you, say, shutdown the PC too quickly afterwards that might force it to close, which is the same as a crash. The installation process hasn't changed. but do try 5.123b which is a fixed version of 5.123 and replaced it recently. Pete

Yes. The MakeRunways instructions also tell you this! Pete

Hmm. That shows that a previous session of P3D4 crashed on exit, and that Windows blamed FSUIPC, so prevents it loading by a Registry entry. FSUIPC often gets the blame for the crash just because it usually has threads still running at the end (for Lua, WideFS, and other activities which take longer to close down). Are you using LINDA by any chance? That also uses some drivers which can exhibit the same problem on an exit crash. The FSUIPC5 Installer should be clearing that indication in the Registry. are you sure you are running the Installer "as administrator" (a right-click option)? Because it seems that it isn't able to fx the entry itself. The next P3D4 update is also supposed to fix this problem. Pete

The fixed one is 5.123b, now the only one you can download in the normal places -- above in Download Links, or from the Schiratti website. both point to the same program. Pete

Version 5.123b is now available for downloading, and it has been thoroughly tested with P3D 4.1.7 (the current user release of P3D4). Pete

Setting NRZ mode should give you -16384 to +16384, but you probably need to assign to the Axis throttleN set FS controls, not assign direct to FSUIPC calibration. Some aircraft don't like the alternative controls FSUIPC then uses. But just try with the update first. Pete

Wow! I've never seen so many Add-In DLLs. I'm wondering if this is breaking some P3D4 limit (a bug with too many scenery add-on XMLs which is being investigated now). As well as FSUIPC and two P3D SDK DLLs, there are 13 DLLs, mostly for add-on aircraft by the look of it. Just to check it isn't specifically FSUIPC, could you try renaming your current DLL.XML, say to DLL.XMLx, then re-run the FSUIPC Installer see if that works okay. If it doesn't, see below. If it does, delete the new DLL.XML and rename your normal one back. Then, in either case, enable SimConnect logging (see the FAQ thread for details) and re-run P3D. Then find the Simconnect log file and show me that, please. It should show why it isn't being loaded. Pete

It'll be the same problem. 5.123b will be up this morning. I'm just doing final checks with P3d 4.1.7. Pete

Looks like there is some bug in SimConnect, in its GPS data handling. Or, more likely I think (or this would be happening to many more folks) some sort of corruption in your P3D 4 installation. Please try uninstalling the P3D4 Client (using the Windows control panel), and reinstalling it. This won’t affect any add-on Pete

Working on it now. Please stand by. Pete

Working on it now. Please stand by. Pete

The XML.DLL you posted is almost impossible for me to check, as it is missing all of its natural formatting. Could you please instead ZIP it and attach it? Pete