Pete Dowson

Yes please, and leave PollInterval to default for now. Thanks! Well it might be the FSUIPC logging which has the major effect -- it is slowing the feed-in end. And presently, if it sees that Exception 2 from SimConnect, it turns on more of its logging whether you like it or not. Let's look to the future, with 4.291. I've sent another report to my contacts in Microsoft and will chase the underlying problem separately. Regards Pete

You do NOT use FSUIPC4 for FS2004 or before, only for FSX. The current version for FS2004 and before is 3.81. no other version is supported from versions of FS before FSX. If you are using FSX you must use FSUIPC4 as there is no way FSUIPC3 (or 1) will work on FSX. They mean exactly what they say, of course. They are in English. And you showed the code where they are set. Look: // create the file-mapping object m_hMap = CreateFileMapping( (HANDLE)0xFFFFFFFF, // use system paging file NULL, // security PAGE_READWRITE, // protection 0, MAX_SIZE+256, // size szName); // name if ((m_hMap == 0) || (GetLastError() == ERROR_ALREADY_EXISTS)) { m_dwResult = FSUIPC_ERR_MAP; this->Close(); return FALSE; } The "Failed to create a file mapping object" message is error FSUIPC_ERR_MAP, so the CreateFileMapping call to Windows failed, and the "IPC request contains bad data" message is the error FSUIPC_ERR_DATA from this code: if (dwError != FS6IPC_MESSAGE_SUCCESS) { m_dwResult = FSUIPC_ERR_DATA; // FSUIPC didn't like something in the data! return FALSE; } You should have easily worked all that out yourself. If you got the second error the most likely problem on the first is that you've tried to Create the same file mapping twice, so got "ALREADY EXISTS" returned. Pete

Maybe I can offer an explanation of sorts: So far, all the evidence, the logs I've seen, and all the investigation over the weeks, are all leading to one conclusion: that it is possible to overload SimConnect to the point where it corrupts data. I suspect that there is a cyclic buffer somewhere which is overfilling and trampling over data. In all the cases for which I've seen SimConnect logs for so far, the one common happening, a number of seconds before the hang/crash, is a failure like this: > 200.92873 [ 0, 8175]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=-10402, GroupID=1, Flags=16 < 200.92882 [0] Event: Group=2 EventID=65764 Data=-10402 > 200.92885 [ 0, 8175] < 200.92886 [0] >>>>> EXCEPTION=2, SendID=8175, Index=0 <<<<< Unrecognized Data Received. [ 0, 8175] Here you see a command from FSUIPC sending SimConnect a valid Axis event (65764 happens to be "AXIS RUDDER SET", but it could be any axis). The line following is the confirmation from SimConnect that this was okay and accepted. But the next two lines show rubbish in the buffer that SimConnect is reading from -- the "8175" is supposed to be a unique sequence number, assigned by the SimConnect DLL when it sends the request to FSX (via Named Pipe or TCP/IP), but here it is the SAME ID as the previous good one! And it has no valid data, no actual request, associated with it. SimConnect (the part in FSX itself) rejects it with error 2, unrecognised data. Okay .... but thereafter things go from bad to worse ultimately hanging FSX. I have reported all this to Microsoft when I first analysed it, but so far no reply. Anyway, in one of the increments since FSUIPC 4.28 I added detection of the Error 2 and then automatically turned on lots of extra error logging. This was to try to see if it could possibly be anything i was doing. I'm guessing now that in your test with 4.287 this extra logging did get turned on, but it was self-defeating in that it slowed the SimConnect traffic up enough to either avoid, or seriously delay, the crash. This is one of the troubles with logging -- Heisenberg's Uncertainty Principle, you can't observe something without changing the outcome! :-( Anyway, in 4.291, with direct assignments to FSUIPC calibration, I'm avoiding using SimConnect events altogether EXCEPT for mapped axes (that is, for example, Throttles 2 3 and 4 when you pa 1 to 4). If I do what i'm doing for those I get FSX into a very tight loop, as I have to intercept the originals for axes which I'm supposed to be replacing. Hope this is clear? Regards Pete

FS provides separate fuel selectors for each engine, so it makes sense. "Fuel selector all" simply means setting the fuel selector, for the specific engine, to use fuel from all tanks. The fuel selector in FS switches tanks, not engines. Sorry, I don't understand what you are talking about here Fine, but I think in FS you have to switch each fuel selector to off with separate controls. There doesn't appear to be one which operates them all simultaneously. It doesn't matter so much -- if you always want to operate them together on one button, do as I suggested. Why, when it can be done as it is for the few who might need it? Has it? What is its name? It was the FSX list I referred to when you asked, and I didn't see it. Regards Pete

For FSX there's an interim update now available for testing: http://fsuipc.simflight.com/beta/FSUIPC4291.zip This uses an improved method for axis assignments routed "direct to FSUIPC calibration", avoiding SimConnect altogether, and by reports so far (it's only been half a day though) it is fixing problems folks have been having with SimConnect data corruption causing FSX to eventually crash. The change which might benefit those using multiple joystick axes for the same FS control surfaces is that this version does arbitrate for the maximum deflection when "direct to FS calibration" is being use. (It cannot do it for routing via FS controls because there's no way to add source data, differentiating inputs, that way). I think this will make the old method, of assigning extra axes to otherwise unused FS controls, redundant, at least for FSX. I may look to see if I can apply the same change to FSUIPC3, but no guarantees on that. Regards Pete

Test it on the default 737 autobrake first. If it works on that but not the PMDG one it means PMDG have implemented their own system. You'd either need to find the keyboard shortcuts for it, if any, or possibly see if the new FSUIPC mouse macro" facility works on that switch. You don't need to "restart FS2004" to test any assignments out, they should operate immediately you "OK" out of the Options. Regards Pete

Sorry, I've really no idea unless you tell me the name of the control you are using. For Mixture setting there is a generic one for all engines as well as individual ones for each of up to 4 engines. The mixture operates the starter idle/cutoff levers on jets. For props the mixture is either a true fuel enrichment/cutoff lever or a condition setter. Fuel selectors are for switching where the fuel comes from, not specifically for curtting off the supply -- that's always done with the mixture control. And you surely want a separate switch for fuel selection so that you can balance the tanks. There's no "switch all fuel selectors together" control (it wouldn't make sense, really, because you'd often need selector 1 set to tank 1, 2 to 2 etc), but in FSUIPC you can assign as many controls to the same button as you like. Best to program the first as usual, in the dialogue, then edit the INI file to add the others. They'll operate in the order you place them. The control numbers are listed in the "List of FSX controls" installed in your FSX Modules folder, and the format, if not obvious, is described in the Advanced Users guide. Note that once you have multiple or conditional assignments programmed in the INI you cannot again edit that button in the Options dialogue. (This is to avoid confusion and making a mess! ;-) ). Regards Pete

I suspect FSC needs direct access to your FS scenery library and so on to build its database. It would use ordinary file/folder sharing for that, not WideFS. Pete

Okay. I've modified it so that it still uses SimConnect but just for "mapped" axes (e.g. throttles 2, 3 and 4 when only using one). This otherwise causes a loop with interception followed by re-transmissions ad infinitum. Download this and try it, please: http://fsuipc.simflight.com/beta/FSUIPC4291.zip Please also still do the other checks I've mentioned in this thread. Thanks, Pete

Hmmm. No mappings, so I'm not really sure which aspect caused the loop -- but it will be something I missed, posting the control and intercepting it and re-posting etc. That's what was happening here. Anyway, I've worked through it logically and re-written the relevant part. I've re-tested all the combinations I've had time to do this evening and will continue tomorrow, but meanwhile maybe you'd like to try it. http://fsuipc.simflight.com/beta/FSUIPC4291.zip Regards Pete

Sorry I don't know it. You will want to talk to Eaglesoft support I think. However, I doubt if they use FSUIPC offsets if they've implemented their own A/P. I've still no idea whether you are talking about FSX or FS2004 or even FS98, nor which version of FSUIPC, so if you do come back for more, please do state a little more detail. Regards Pete

No, sorry, you misunderstand. Mapping isn't registered in the [Axes] section but in the [JoystickCalibration] section. I'm referring to the mapping of, for example, a throttle to 4 throttles, or Throttle 1 to 1,2 and 2 to 3,4, etc. All the mapping facilities are in the calibration section. you are confusing "assignment" and 2mapping". I cannot induce a problem UNLESS I set some mapping. Immediately i set mapping I get exactly the same symptoms as you. that's why I wanted to see your joysdtick section, not your Axes. Thanks, Pete

Whilst changing this might be an improvement, I think it's a red herring. I've managed to reproduce your symptoms -- by Mapping my one throttle to 4 throttles. Everything works fine but as soon as i do that, hang ... It looks like something I'm now doing is causing a loop when any single axis is mapped to more than one. I assume you have some? Perhaps you could show me your [Joystick] section parameters -- not all, just the section you use by default. I'll look at this later, after dinner. it may not be tomorrow till I have it solved. Regards Pete

Looks like it is in a tight loop repeating similar axis controlsI'm wondering if this is also what causes the problems for some folks with Simconnect. Look: 324477 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324528 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324578 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324628 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324679 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324729 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324779 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324830 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324880 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324931 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324981 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 325032 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 325082 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 325141 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET Since the value in each case is the same (16384) is shouldn't really be continually sending them. I'm guessing that the raw value for this axis is actually jittering more than the Delta, and so feeding different values to the calibrator, and that is seeing them all in a dead zone and so setting the max (16384). Fine. but it looks like i am missing the final check that says "if I sent this before don't send it again". I'll check. Look out for another link -- I'll remove 4.289 for now. the next one will be 4.291. Thanks, Pete

Strange. It works fine here. The main difference is that it is simpler -- the axes sent "direct to FSUIPC calibration" are then posted directly to FSX without using SimConnect. It's much much more efficient, using much less processor and resources -- the same method was used in FS2004 and before. I haven't used it before with FSX because i was "trying to be a good boy" and use the "official" SimConnect routing. I'm at a loss at present. Have you anything to show me, like an FSUIPC4.LOG for example? Does it still lock up with your version of FSUIPC.INI not using "direct to FSUIPC" assignments? Pete

Sorry, the calibration part only sees one axis. the arbitration isn't there. you need reasonably matched axes, as you do with the other method. Pete

No idea what the "55X" is (is that an add-on aircraft -- for which, FS2004 or FSX?), but usually the VS will reset itself to zero if the altitude it is supposed to gain is the one already reached. You probably need to set a target altitude, then set the VS value. Not sure about the VS mode itself, I don't think the default A/P has more than one vertical mode, so there's not a lot of difference between FLCH and V/S -- you adjust the V/S yourself or leave it to the default (like 1800 fpm). If you really do mean a sophisticated add-on aircraft with its own autopilot, then you'll need to check its documentation for its way of handling things. I doubt that it takes note of default A/P values such as those supported by FSUIPC. Pete

Download this and try it, please: http://fsuipc.simflight.com/beta/FSUIPC4289.zip It has the arbitration i mentioned. It also avoids using SimConnect for direct-assigns, so hopefully it won't cause other problems. I'll not release it formally till I know. Thanks, Pete

I've made a version of FSUIPC4 which avoids using simConnect altogether when you assign axes in FSUIPC for "direct to FSUIPC calibration". I'm hoping that this will stop these crash/hang problems, but since i've never been able to reproduce them I cannot tell. Download this and try it, please: http://fsuipc.simflight.com/beta/FSUIPC4289.zip Sorry, temporarily removed whilst I sort a potential hang out with Mapped axes. Look out for a link to 4.291 in the next 24 hours. Please also do the other checks I've mentioned in this thread. Thanks, Pete

No you do not! Just go to the Modules folder and check it. That message doesn't even exist in the current versions, and hasn't for a long time. That message is from a version of FSUIPC preceding the FS9.1 update. It is merely telling you that it doesn't recognise 9.1 and so cannot run. you either need to uninstall the 9.1 update and go back to the stated original release of FS9, or, better, update your FSUIPC. The only supported versions of FSUIPC3 at present are 3.81 and later. Your "Captain Sim" install is overwriting your later FSUIPC (quite wrongly, it is evidently a very poor installer), and, as the Captain Sim package is much older than FS9.1 it has a very old version of FSUIPC packaged with it. Please ALWAYS check your version of FSUIPC before asking for support. It is easy enough to do -- find the module in the Modules folder, right click on it and select Properties-Version. Pete

I don't know how it can be "from time to time"! Either it checks or it doesn't. A DLL doesn't alter itself back and forth -- perhaps you have some sort of intermittent hardware problem, like dodgy memory? Sorry, I really know nothing about that valueI just quoted some help from elsewhere, from Lefteris of PMDG I think. You may need Microsoft support if it isn't a hardware fault. Regards Pete

Can you save that copy of FSUIPC4.INI (so you can go back to it) and change them all to use the FS controls (you should still find everything you need, unless you are using FSUIPC's separate Reverser axes which don't exist in FSX). Then see if you still get the crash with both processors in use. Phew! That's some system you've got there! Do you get the crash with affiinity mask set to 1 instead of 2? (Just to eliminate a processor problem as such). Regards Pete

Hmmm. where do you find that info? I suspect mine is older. I don't think I have access to their downloads system at all, so I'd need to ask them. Maybe they have changed something and never thought to re-check it in turbulence. Pete

You may like to know that I've devised a way for multiple axes assigned to the same FS function via FSUIPC4's axis assignments, direct to FSUIPC calibratiion, to be arbitrated just like those using the special control number assignments facility. The maximum deflection is the one which is used, but the check is only performed when a change occurs on an axis. So once one axis is used instead of another, it remains in use for that function provided that the others assigned to the same function are either quiescent, or only provide values of less significance than the last one from the current axis. This avoids the need to assign larger "delta" values to stop jitter interference from the axes currently not being used. They simply need to stay "parked" (centred for control axes like aileron, elevator, rudder and their trims, full off for axes like throttles, spoilers, flaps, mixture and prop pitch). I've also changed the way the "Direct to FSUIPC" assignment works, to avoid using simconnect altogether, on the assumption that this is responsible for some of the problems reported in a parallel thread near here. Look for a new release in the FSX Downloads announcement above in a day or two, after I've tested it thoroughly. Regards Pete

Are you saying this is also only with axis assignments in FSUIPC "direct" to FSUIPC calibration, and not otherwise? Otherwise that sounds like a completely different thing altogether, and more likely related to a problem with your processor or motherboard. What about an affinity mask of 1 (to force the other processor to be used)? Maybe one of your processors is flakey? Only if the Intel microprogramming which handles the processor switches is broken or the hardware is flakey. I really wouldn't think there's anything in FSX which'll be having anything to do with that. The use of multiple processors in FSX is enabled by multi-threading, but its up to the hardware and microcode behind it to deal with the complications. Regards Pete