Pete Dowson

.NET is absolutely not related to FSUIPC in any way. Sorry. You do need to look elsewhere. I think you have something seriously corrupted. Pete

I've never seen an error reported in P3D's "Menus.DLL". FSUIPC really has nothing whatoever to do with menus. I think you must have some sort of corruption in P3D which involves addressing memory which may just be in a different place, and not crash, when FSUIPC is not loaded. The error is "String binding invalid" which is associated with Managed code. Are you running any add-ins which use manage code as far as you know? what other add-ins apart from FSUIPC (which uses no high-level or managed stuff itself) are you running. With a crash in Menus is seems possible that it is one which adds or changes menus, almost certainly the Add-Ons one. As well as corrupted modules or an error in one of the add-ins, actual memory hardware could be responsible, so if stopping the other add-ins and, if there's still a problem, uninstalling and re-installing P3D (just the Client should do, so not destroying anything else you installed) doesn't solve it, get some memory test on your RAM. Pete

Okay. Thank you. Shame we couldn't get to the bottom of it. Pete

PMDG normally provide a heap of "custom controls", as listed in the .h file withing the SDK subfolder of the installation. Any of those can be used in FSUIPC assignments by selecting <custom control> and providing the control number. Pete

That just means SimConnect signalled a pause in simulation like when you go into a menu or load a flight. You went to a different location. It's only FSUIPC's way of giving you average performace for the last running period. Possibly it's a corrupted weather entry in either wxstationlist.bin or in the currently loaded wx file. Those are binary files which are read without any checking (by the sim itself, not by FSUIPC) so when corrupted can cause such problems. It only happens with FSUIPC because FSUIPC regularly gets weather data from SimConnect. You provided no crash data. Don't you think that might give a clue? Use the Windows Event viewer to find the crash data. It will show which module crashed and what sort of error it was. In order to prove it is this problem you can stop FSUIPC asking for the weather by having "NoWeatherAtAll=Yes" in the [general] section of the FSUIPC4.INI file. Pete

To Kegs1953 I've been analysing the Registry exports you sent and trying to relate them to the last FSUIPC log I got from you, the only with the Extra logging. They don't quite match. They nearly do, but the Joystick ID for the Stick doesn't match its GUID. Background If you refer to the top (pinned) thread in this Forum, you will see that I now have this sort of information from Paul Henty, one of the many successfully running an X-55 system with FSUIPC 4.966c. Comparing his registry with yours I was hoping to find the problem, assuming it it registry rather than hardware or connections. First off, oddly, for both Throttle and Stick, there are two entries each. On Paul's system the Stick pair both have the same GUIDs -- which should be impossible! However, only one has a Joystick ID, and that, the first, is the one FSUIPC chooses. For the Throttle the two have different GUIDs, and again only the first has a Joystick ID. FSUIPC chooses that. When FSUIPC knows that there are 2 devices it will be looking for the details for the second. but in these cases there's only one, and FSUIPC therefore assumes there's only one entry and chooses the first. I suspect that through some quirk during installation the Stick on your system is actually using the second, with a different GUID. For the Throttle, however, it is using the first GUID and the first ID, so they do associate and that should work fine! Some it doesn't make sense -- unless the registry exports aren't reflecting the state they were in when the log I'm looking at was made. So, without further analysis on your setup I can't progress that further and work out what to do. Action Please Please can you do this: 1. Make sure you still have Debug=Please LogExtras=x200000 in the [General] section of the FSUIPC4.INI 2. Run the Sim till ready to fly, then close it. 3. Repeat the Registry export process to get two .reg files and rename them to .txt. 4. ZIP the 3 files together and send to me again. This will make sure everything tallies. Thanks, Pete

What LOG claims that? Nothing I know will shut the sim down just because frame rates are low. That's ridiculous! Perhaps you mean VAS is low (memory). That's the most likely thing if it is only happening at large airports. Pete

I've been analysing the Registry exports you sent and trying to relate them to the last FSUIPC log I got from you, the only with the Extra logging. They don't match. There is no way that log is from the same machine, or in the same situation (i.e. no removals or reinstalls of the X-55 between) as the registry exports. Background If you refer to the top (pinned) thread in this Forum, you will see that I now have this sort of information from Paul Henty, one of the many successfully running an X-55 system with FSUIPC 4.966c. Comparing his registry with yours I was hoping to find the problem, assuming it it registry rather than hardware or connections. First off, oddly, for both Throttle and Stick, there are two entries each. On Paul's system the Stick pair both have the same GUIDs -- which should be impossible! However, only one has a Joystick ID, and that, the first, is the one FSUIPC chooses. For the Throttle the two have different GUIDs, and again onl the first has a Joystick ID. FSUIPC chooses that. When FSUIPC knows that there are 2 devices it will be looking for the details for the second. but in these cases there's only one, and FSUIPC therefore assumes there's only one entry and chooses the first. I suspect that through some error during installation the Throttle using on your system is actually using the second. However, without further analysis on your setup I can't progress that further and work out what to do. Action Please So, please can you do this: 1. Make sure you still have Debug=Please LogExtras=x200000 in the [General] section of the FSUIPC4.INI 2. Run the Sim till ready to fly, then close it. 3. Repeat the Registry export process to get two .reg files and rename them to .txt. 4. ZIP the 3 files together and send to me again. This will make sure everything tallies. Thanks, Pete

Sorry, that is well out of date. The supported version is 4.966c. Please update. Use the right-hand side of the Axis assignments tab as explained in the user manual. Don't assigned to keypresses though unless they are unique to the add-on. Use the FS controls to which those key presses are assigned -- Elev Trim Up and Elev Trim Dn. Pete

Thanks. Unfortunately the Lua did nothing because it couldn't even open the devices: 128968 LUA.2: Could not open HID Vendor 0738 Product 2215 I'll make another small modification to it to try again. If it still doesn't work, I'm stumped. Please replace it and try again. Same method. HidX55.lua

I have a Lua plug-in to try. this is just to give me some information. I'm considering offering an alternative more for reading such devices, but if the alternative gives the same then I'm likely to point to faulty harware, or firmware unsuited to use with Win10. I read some of the reviews of the X56, the new one replacing the X-55, and that was apparently released with old firmware. Maybe X-55 users need to see if they are up to date? Anyway, here's the Lua plug-in. I have no idea if it will do exactly what I want it to do, but I'll be able to tell from the FSUIPC log. Please remove those extra logging lines in the INI and turn off Axis and Button logging because that will cloud the issue. Then place this Lua in the Modules folder, run the sim, then in the Keypress tab, assign an otherwise un-needed keypress (or combo) to "Lua Hidx55". Back in flight mode, press the assigned key or combo, and just move the sticks, press the buttons, operate the hats, on both devices. close the sim and sohw me the log. Thanks. Pete HidX55.lua

The log shows some axis activity, though by the look of it from "zero2 being received from the units. Was that with the X55 units, and they are returning just zeroes, as in the case of Kegs1953? 22360 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 0 (0x00000000) AXIS_AILERONS_SET 22360 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 0 (0x00000000) AXIS_ELEVATOR_SET 22360 *** AXIS: Cntrl= 66387 (0x00010353), Param= -8736 (0xffffdde0) AXIS_LEFT_BRAKE_SET 22360 *** AXIS: Cntrl= 66388 (0x00010354), Param= -8840 (0xffffdd78) AXIS_RIGHT_BRAKE_SET 22360 *** AXIS: Cntrl= 65764 (0x000100e4), Param= 0 (0x00000000) AXIS_RUDDER_SET 22547 C:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\VRS_FA-18E\FA-18E-6.8_SE.air 22547 Weather Mode now = Global 22547 c:\users\kurt\documents\flight simulator x files\FA-18E at Miramar.FLT 24485 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 0 (0x00000000) AXIS_AILERONS_SET 24485 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 0 (0x00000000) AXIS_ELEVATOR_SET 24485 *** AXIS: Cntrl= 65764 (0x000100e4), Param= 0 (0x00000000) AXIS_RUDDER_SET 26125 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 26203 User Aircraft ID 1 supplied, now being used 26266 Aircraft loaded: running normally now ... 26344 *** AXIS: Cntrl= 66420 (0x00010374), Param= -16384 (0xffffc000) AXIS_THROTTLE1_SET 26344 *** AXIS: Cntrl= 66423 (0x00010377), Param= -16384 (0xffffc000) AXIS_THROTTLE2_SET

Have you got any further? Have you made any axis and button assignments yet to your X-55 devices (stick and throttle?). If you have things working in FSUIPC, could you do me a favour, please? Provide some logs. Add these lines to the FSUIPC4.INI file's [General] section: Debug=Please LogExtras=x200000 then just run the sim for a short time, using the X55 a bit 9axes, buttons). Close down and show me the log -- or send it, ZIPped to petedowson@btconnect.com. Thanks. Pete

Sorry, what are they? Are you referring to some action documented in case of problem, relating to Joystick IDs, which actually isn't needed now and involved a program called JoyIDs? Or do you mean the resistry fixes to the bad install Saitek does? Have they not even fixed that yet? That is extremely strange, because both axis values and buttons are read at the same time, in the same actual operation. They are indivisible. You are now the third person here with outstanding X-55 problems, and all three of you have different problems but ALL with the X-55 (and all on Win10 which may also be relevant). One has neither stick nor throttle seen, another has stick but no throttle inputs, and now you with axes okay but no buttons. The X-55 is a nightmare. Can you please refer to the other two threads and supply the same data, so I can compare it? They are by "OldPop" and 2Kegs1953". Best go to the last few exchanges or you'll get very confused. it even confuses me. I'm going to try to get someone with a working X-55 set to supply similar data for a comparison with what it should look like. Pete

MakeRunways cannot possibly change the files it creates to different types. They are still csv files. You are being befuddled by Windows' habit of defaulting the Windows Explorer option for showing the full filename to off. It then classifies them according to what Application it thinks might read them. Excel can read csv files. This stupid and annoying setting also classifies .log, files as text files and .ini as configuration files. The FSUIPC user guide advises you to change that option. Left to default, it doesn't do any harm except mislead you and confuse you. Why are you worried about it in any case? Programs which use the MakeRunways files won't be bothered. Pete

Did you plug in to the same USB port? Here I can unplug and replug devices at any time, whether FS/P3D is running or not. The assignments stay. They are dictated by the Registry, not by FSUIPC. But then though I've got, for instance, two apparently identical Bodnar boards, Windows and therefore FSUIPC distinguishes them by their Serial numbers, which, unfortunately, many devices don't supply on the USB interface. Are you sure when you say "FSUIPC did not recognize any of the controllers" that the two Pokeys were not simply swapped? Apart from two Pokeys, what others are there? How did you decide FSUIPC didn't recognize them? Deleting JoyNames won't magically make FSUIPC "recognize" joystick devices! the entries there only tell it how to assign them when it has recognised them. so I think you are not describing this properly. What probably happened was that, since the Pokeys devices are probably indistinguishable to FSUIPC, it saw them in a different order and so cross-assigned them. the fix is simply to change the numbers or letters or both over in the JoyNames section. Pete

Ah, sorry. I misread. So you have two sets of identical controls, like me, and simply want to assign both sides to the same controls? And are both sets identical devices? Are they connected differently -- different USB hub perhaps? Or one via a hub the other not? As well as the INI and LOG files as requested by Thomas: Could you run my HidScanner utility please and send me the log file it makes? It’d in the “useful additional programs” thread of “Download Links” subforum. Also export the relevant registry parts: HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties Do this by running RegEdit from the Windows start menu, going down the Explorer style layers to those and with that layer selected do File-Export give them each a name (it’ll save as a .reg file). Then rename them from .reg to .txt so the mail system or my anti-virus doesn’t reject them (.reg files, when run, change the registry), and send those to me at petedowson@btconnect.com. Just going back to your first post (added rather misleadingly to a thread mainly about X-55's, which seem to be the main source of problem), you said Any reason you are not assigning directly in ProSim? I think that's the more usual way for ProSim users. Does that not see both sets? (I'm a ProSim user, but cannot assign that way because my controls are PFC serial port devices, handled by my own drivers). Also, can you say what might have changed 'recently' when they stopped responding in FSUIPC? Thanks Pete

That means the full left deflection is giving a HIGHER value than the others. You have to have the LOWEST in the "minumum" column. You are mixing up "minimum" with left. It is the NUMERIC minimum, not necesarily the way the stick moves matching the screen orientation. If you want to start with the left deflection giving a maximum value, click thethe Maximum" side instead first, or just start with full right deflection. FSUIPC calibrates the NUMBERS used in the sim. In the calibration phase it is NOT reading the joystick but the values in the simulator! I see Thomas answered you as well. But I'm afraid reacted to your accusation. It s NOT "aberrant" behaviour. You are mixing up the meanings of the words minimum and maximum as meaning left and right deflection, which they can be but might not be. And such a mix up wouldn't make sense anyway for an elevator control, or throttles which don't have a left and right action. Please note also that negative values (those preceded by a '-' sign) are lower (less than) positive numbers. Pete

I don't see any axis assignments at all. Are they only assigned in the sim? You also have no axes calibrated. I don't think ANY mappings work without any calibrations. As far as I can see, this is a completely default settings except for the mapping lines. I didn't think you could set those (at least not in the calibration tab) without at least calibrating. The mapping maps the post calibration values! Pete

The "ping" only happens when numbers don't increase from left boxe to right. Just keep them in order -- left box (minimum) not higher than either centres (order of top and bottom centres don't matter) and all those not higher than the right value (maximum). If you need the order reversed, select REV first, before calibrating. The it is still low to high but applied the other way around. Press "RESET" to start again. The numbers will reset to defaults to start with which can then be set, maintaining the correct order. I'm sure it says this sort of stuff in the User Guide. Pete

Only those enabled. Pete

Sorry, what do you mean by the "Left" and "Right" sides? I don't understand. The axis assignments tab only has one place where it shows the values received from the axis,and that's top centre. Pete

I'll have a look, before the next release. Not sure when, but they are more or less monthly at least. No promises till I've checked the code. It's pretty old now. Pete

Sorry, I need to see your FSUIPC4.INI file too, for the assignments, calibrations and options. Just post its contents in a message here -- use the <> button above the edit area to enclose it. Did you try Throttle 3 lever on its own? Does that work? There's no Throttle3 or Throttle4 controls in the log. Do they both work independently? Did you try a 1,2,3,4 mapping, or a 1,2 + 3,4 one, in this session? Did you try Throttle Sync as I suggested? Pete

Using the FSUIPC TCAS tables (which are designed really purely for TCAS display use, the range limit applying to airborne traffic is 40nm by default, but can be set in the options or via the INI file parameter. The ground traffic range when the user aircraft is airborne is 6nm, but only 3nm when the user aircraft is also on the ground. Normally ground traffic is not a feature of TCAS. FSUIPC does in fact get ALL the traffic from SimConnect (it doesn't really have an option), and uses this for its own Traffic Limiter options, but the TCAS tables are purpose designed and very limited in size, using offsets as they do. Most programs doing the sort of things you are doing get the traffic data from SimConnect directly, even if they have to use FSUIPC to delete them (SimConnect only lets the object creating program to delete said objects. FSUIPC's method is actually a hack into the code). I suppose I could make the Ground traffic range for an Airborne user configurable to more than 6 nm, perhaps following the Airborne setting. Pete