Pete Dowson

Okay. My diagnosis was wrong -- FSUIPC already does match names in the same order each time. I think your lost axes assignments came about for the same reason as the crash you experienced when reloading all axis assignments. The routine to check and revise those assignments was in error. :shock: In fact the error was in the INI file handling routines, and could make corruptions in other parts of the INI file too. :oops: :oops: I am sorry about that. I have fixed the error in versions 4.438 and 3.874, now available in the Updates announcement. Please update your copy. I'm afraid you will need to rebuild your assignments -- unless, hopefully, you have a backup? Pease confirm that you get it back up working okay with the new version. And apologies again. i don't very often let a serious error like that escape. Luckily it only affected the updates over the last few days. Regards Pete

All offsets, 0000 to FFFF, are valid offsets in all versions of FS/CFS/ESP since and including FS98. The offset is either a memory reference to an area in FSUIPC itself, or it is mapped into a place somewhere in FS's other modules or assigned memory. Reading any offset cannot do any harm, though you may just get rubbish. Writing to an undefined offset may just get an error logged by FSUIPC, if it is listed as a definite no-no, but it could conceivably crash FS or get other unexpected results -- not in FSX or ESP, because ALL the memory is owned by FSUIPC in those cases -- but certainly in FS9 and before, since some of the mappings are to areas of unknown use in FS. So, for reading only you shouldn't need to worry. For writing you should realy first check the FS version number, which is avaiolable for you as an numeric code in offset 3308. Regards Pete

Good! Well done! Well the installer log showed it did install correctly -- you might want to check the DLL.XML file in the Flight Sim user location (see the path for the FSX.CFG I gave). Did you install anything else after FSUIPC? Maybe something else has edited the DLL.XML file and made a mess of it? Regards Pete

I think FSUIPC is not forgetting anything, but you have a problem: AutoAssignLetters=Yes 1=Logitech Extreme 3D 2=Saitek Pro Flight Quadrant 3=Saitek Pro Flight Quadrant 0=Saitek X52 Pro Flight Controller A=Saitek X52 Pro Flight Controller B=Logitech Extreme 3D C=Saitek Pro Flight Quadrant D=Saitek Pro Flight Quadrant Your two quadrants have exactly the same name. I suspect all that is happening here is that one time C equates to 2, and another C equates to 3. Auto-assigning, as you have done, is probably not a good idea when you have identical units to deal with. You need to assign C and D directly to the numbers so they don't get reassigned: A=Saitek X52 Pro Flight Controller B=Logitech Extreme 3D C=2 D=3 It may be correct like that, or maybe it should be C=3 and D=2. I cannot tell. You'll have to check by looking, or just try one then the other. Ideally FSUIPC shouldn't keep changing -- maybe I should make it check for duplicated names, and deal with them somehow -- maybe at least keep numerical order = alphabetical order. This won't help if you ever unplug them and plug them in again, unfortunately. The only other way I could deal with it would be to use the GUID identifiers for the devices, as FS does I think. But I really hate those -- although they are certainly unique, you cannot tell what they are. Not only that, but I think they change in any case if you unplug them and plug them in again, so it deteats the purpose still. No, I'll look at just keeping order. The problem I have is testing. I have only a couple of cheap joysticks which I use for tersting. All my real stuff is PFC serial port equipment driven by my own drivers. Maybe if i make an order check on assignments to duplicates you can test it for me? When did you set "AutoAssignLetters=Yes"? When you say "from one moment to another my controls failed" you surely only mean when changing aircraft, so making FSUIPC re-read the assignments? When you sayt yyour "controls", you surely mean only those on the two Flight Quadrants? Ouch! Really? That IS badI must find that. Can you please provide any more details. Does Windows show a message? Can you get the Module name and Offset? Regards Pete

Well FSUIPC does install itself for all users who have FSX.CFG files (another reason you must run FSX before installing). According to the Install log you posted you have installed FSX for users called "eXe" and "Flight Sim". THese names are from the Log-on name parts of these paths: Found FSX.CFG in "C:\Documents and Settings\eXe\Application Data\Microsoft\FSX\FSX.CFG"! Found FSX.CFG in "C:\Documents and Settings\Flight Sim\Application Data\Microsoft\FSX\FSX.CFG"! If you are trying to run FSX from a different LogOn name than these two, FSUIPC4 won't get loaded by SimConnect. Regards Pete

Okay. done and tested -- versions 3.873 and 4.437 contain this change, now in the Updates announcement. Regards Pete

I meant the first launch of FS after installing FSUIPC. It makes no odds. You will get that prompt on the very first time you ever use any of my software, but if you then use the recommended choice odf saying you trust me as publisher, you don't get prompted again. Perhaps you didn't. Re-install what? Re-installing FSUIPC won't make any difference. If you've been attempting to uninstall and reinstall FSX, that can make a mess of SimConnect -- in fact it seems to be the main cause of all such problems. No, but you should certainly not try to install SP2 without installing SP1 first, and I've seen folks state that things can get messy if you don't run FSX between each update. However, I doubt if any of that affects the state of SimConnect as much as whatever you did BEFORE trying to install. How did you proceed with the uninstall? I don't think FSX's uninstaller does it very well. It leaves bits and pieces about, and can easily mess up the SimConnect it leaves behind. Regards Pete

This is with which aircraft? The default 738 and 744 both work okay here. FSX does appear to need the fuel switched on earlier than fS9, around 18%, but 20% always works too. It should be 25% according to stuff I've rad, at least for the 737, but FSX certainly won't get that far. Maybe it's something to do with the aircraft model you are using? You've not mentioned it. Always test with default aircraft. If not, then I suspect your options aren't set correctly for this mode. Strange. I don't know what you've got there. I've not released any version of PFCFSX.DLL since 14th December 2008, and that was 4.34. The DLL called PFC.DLL is for FS9 and that's still at version 2.307 from 9th October 2008. What's the problem with quoting the version number for me? It is shown in the log, on the screen in the options, and it is in the properties of the DLL itself (right-click, Properties-Version)! Yes, well of course if you program it to send AT Arm Toggle or Off it will disarm the AT. That is not what I intended to happen with the AT Disco button. It sounds like you just don't like it doing what to me seems sensible -- that is flicking AT Arm off and back on so that all vertical/speed modes are disengaged and you are back on manual throttle control till you engage another such mode. If you call that 0% operating, fine. I don't. Of course. That's inevitable the way you've done it. But please yourself. Personally i prefer having the TO/GA on those throttle buttons (as the console doesn't come with the TO/GA buttons normally fitted too). Otherwise you have to find and preess the N1 button to enable TO/GA. The AT Arm switch is to hand in any case. Load it into Notepad, or any other text editor, select it all and select copy. In your message insert. It is that simple. If you think it is too long and makes the message hard to read, select it in the message and use the "List" button to encapsulate it. I still think your switch 3/4 problems are hardware related. I had problems with those. Since i fiddled about re-seating the hardware connections behind them they've been fine. Regards Pete

Why would you want to? You can assign keystrokes to buttons and switches, asnd you just confirmed that you can operate it by a keypress combination. I have my Trim up and down with an axis, but it takes quite long, and I figured I wanted to try a center position to set FMC Trim (and I'm running out of buttons :x ) Two points there: 1. You can calibrate your trim axis to give you a faster result -- just don't use so much of it. Calibrate it for less movement from full down to full up. You can also use the slope facility to give you the needed sensitivity near level trimming but with fast movements from further afield. 2. You can also assign the FSUIPC control to press and release a keystroke, if you are thinking of getting the Axis assignment tab to send it using the zone facilities on the right-hand side. The last example of axis assignments in the FSUIPC user guide features such controls. I'm really puzzled by what it is extra to all these facilities you need, and by why you keep trying to find something by logging. If an add-on changes things directly in FS without using FSUIPC or any standard FS controls then there's no way FSUIPC logging wil do anything for you. Even if it did, what do you hope to gain? Please tell me why you cannot use the facilities available to send the keystroke you already have. Regards Pete

I don't know what sort of numbers your axes put out through Phidgets, but the way those offsets are currently wired up inside FSUIPC yu need to assign them in Axis assignments, to be send "direct" to fSUIPC calibration, then go calibrate. However, it only accepts: In RAW mode , range 0-65535, no negative values. Those would be treated as large positive ones. Or with RAW mode not enabled, only 0-127 (this is the range PFC serial devices provide). This value is multiplied by 512 before being sent for calibration. So, RAW mode is probably appropriate, unless you only get numbers 0-127 max. I'm changing the code to accept negative numbers too -- -32768 to +32767, in RAW mode. The non-RAW will have to stay as it is for use with PFC devices. If you need this change please let me know which you need first -- FSUIPC3 or FSUIPC4. Regards Pete

You are talking about zones -- maybe 20 of them, or only 10 counting entry and exit boundaries separately. Obviously FSUIPC needs to know what numbers mean what action, as as you cannot rely on EVERY possible number always being seen as you move the lever, they have to be ranges, however small. i.e. zones. Yes. You do it on the right-hand side of the Axis assignments tab. The axis assignments chapter. There are only 10 zones allowed, so for 20 keystrokes over the range you'd need to program both the entry to and exit from each of 10 zones to send the "Key Press & Release" -- as in fact shown as the last example in the Chapter. Regards Pete

I was investigating the solution I suggested that I might be able to implement when I stumbled across something already implemented in the current versions of both FSUIPC3 and FSUIPC4. This was a sepcial facility to allow my PFC and GA28R drivers to send axes direct to FSUIPC's calibration facilities. Being of, as I thought then, limited usefulness it was not documented in the FSUIPC SDK, but only in the PFC driver document. Here are the details: Application program axis handling When using FSUIPC version 3.30 or later, application programs or modules can access the raw PFC axis values at offsets 3BA8 onwards. One 16-bit word is allowed for each (although currently all PFC axes have a maximum range of 0 to 127, this may change in future). The axes are: 3BA8 0 Aileron 3BAA 1 Elevator 3BAC 2 Rudder 3BAE 3 Quadrant axis 5 3BB0 4 Quadrant axis 3 3BB2 5 Quadrant axis 1 3BB4 6 Left toe brake 3BB6 7 Quadrant axis 6 3BB8 8 Quadrant axis 4 3BBA 9 Quadrant axis 2 3BBC 10 Right toe brake 3BBE 11 Elevator trim 3BC0 12 Aileron trim 3BC2 13 Rudder trim 3BC4 14 Steering tiller 3BC6 15 not used There are control flags (to disconnect these axes) at offset 3BC8. Each bit, 2^0 to 2^15 can be set to disconnect the equivalent numbered axis above. The cowl flap axes are not part of this facility. Soplease try this: get your Phidgets software to send the Rudder value to 3BAC, and the Tiller value to 3BC4. Best to do both this way for better chance that the automatic switchover takes place based on airspeed and so on. Let me kknow how you get on, please. If this is useful I might add the details to the regular offsets list. Regards Pete

I've just re-tested the switches and they are operating okay at the moment. At least, with FS9 and PFC driver 2.307 they work for a 2-engined aircraft with the mixture enabled by moving switches 3 and 4 to the "start" at the appropriate time. I can't make that go wrong -- so check your option settings for that. With a 4 engined aircraft and the "auto" option selected for the mixture to be enabled automatically at 20% N2, all engines start okay when reaching the right speed. I tested it too with FSX and PFCFSX.DLL version 4.34, and it's okay with thatso, sorry, all I can say that it is either the hardware itself playing up, or possibly some combination of options which doesn't work correctly. If the latter then obviously I need more information -- specifically version nmubers of everything, and the INI file. I cannot reproduce that here. Need more info -- version of the PFC DLL, version of FSUIPC, version of FS? Option settings in the PFC driver (PFC INI file?) On this I have found what you may consider a problem, but isn't, but at present I'm not sure it is nor whether it is the same as yours. First, I assume you HAVE set the "Main" tab option to use the buttons for A/T disconnect? By default, although they are labelled "A/T Disco" they are assigned as TO/GA buttons. I did this because the AT toggle switch is close to hand in any case, and having TO/GA close to hand is, in my opinion, more useful. Second, the way the AT disco button works is to toggle the AT Arm switch off, then on again -- so the speed modes do get correctly cancelled in the A/P, but the AT Arm is still correctly set -- reflecting the actual switch position. Are you sure you are not simply misinterpreting this action? It does the job you want, disconnecting the speed control, even though it leaves the AT armed ready to re-engage a speed mode or TO/GA subsequently. Regards Pete

The exact same thing happens to mine sometimes. They actually go intermittent. I did open it up once and reseated anything that looked moveable -- then they works fine for a while before starting to play up again. I think there's a design weakness in that area which makes them vulnerable. As I say, the problem does seem to be intermittent. Not sure what would be going wrong there. What actually happens? Is this with FSX or FS9? If you have that option set in the driver, then provided the starter is actually operating, the remaining actions are all in the PC -- unless it is getting a signal to tell it that the starter is moved to cut-off. If you have a mixture of symptoms it is sounding a little like some sort of communications problem, though if so it is odd that your prime complaint is the same as one which has affected my own console from time to time. Erthat makes less sense to me. Are you saying the same button works 100% when assigned via FSUIPC, but 0% when processed directly inside the PFC driver? Regards Pete

Interesting. Why would you want to? You can assign keystrokes to buttons and switches, asnd you just confirmed that you can operate it by a keypress combination. Why? I don't think any of those would be relevant to setting an analogue value like the trim. If there is anything sent to FS via the normal systems by the MD-11 code it would be using an Axis control -- you logged everything except axes? Only axis controls can set analogue axis values, unless the value is written direct to FS's internals, perhaps via FSUIPC or perhaps not. Regards Pete

FSX doesn't get a "Modules" tag. All SimConnect clients with menu entries go in the Add-Ons menu. That shouldn't be re-occurring once you've said you trust programs signed by the publisher, Peter L. Dowson in this case. It only happens every time with unsigned software. All my programs are properly signed. The install log is fine. If FSUIPC4 isn't showing in the Add-Ons menu (go and look), then see if there's an FSUIPC4.LOG file. If there is, show it to me. If not then you probably have a corrupt SimConnect installation. On the face of it you seem a little confused about what FSUIPC4 does in FSX. Please re-check. Regards Pete

Not that I know of. It's certainly not going to affect FSUIPC. The usual reason for disabling that is simply to avoid surprises. But I have it enabled on several of my systems, just not the main flight sim as I'm fussy about which drivers I use. Okay, but in my opinion there's a bug in 9.1 which may well be new since 8.11. But rather than go backwards, if you can by all means wait for the next ATI Catalyst update to see if they've fixed it. I had to bypass all of the nVidia 180.xx series drivers. Every one of them caused Blue Screens of Death on my system several times a week with FSX running. Not even flying, just idling parked at a terminal for 30 minutes or so could do it. I had to go back to 179.xx drivers. I've now moved onto 181.xx drivers but haven't had time to even get the cockpit switched on to see if nVidia have fixed things yet! [sTOP PRESS] I've actually now got 182.xx drivers, but not installed yet! Regards Pete

Before I start on yet more changes to FSUIPC (I need to wrap up the many amendments made in the last few weeks, ready for release), could you please first check and confirm that the Phidgets driver WILL allow an axis setting to be sent as either part of two 32-bit offset writes (3114 then 3110), or one 8-byte write to 3110-3117 inclusive. If so, i will be glad to add the facility. If not then i really don't want to waste my time nor yours. Let me know, please. Regards Pete

I'm not sure what you mean by "Main PDF". All the FSUIPC documentation is supplied in PDFs in the ZIP (for FSUIPC3) or in the installer, for the Modules folder, for FSUIPC4. The main "History" PDF never gets "cleared down -- it is an accumulating history starting from "version 1". For those who want to try or help me test interim versions which I post in the Announcements here, I've always listed just the differences between that interim version and the main release. The only change recently was to put that list into a PDF because it was making the Announcement itself too long -- you had to scroll down a long way to find other "goodies". That's also why I grouped all the links to the programs themselves at the top of the Announcement. These last few weeks have been unusual in having so many "little" updates posted. Many of them are only relevant to very specific requests or inquiries which i've dealt with and for which references will be fond scattered among these posts. One of the main reasons though is that with the cancellation of ESP and TS2 I saw no point in continuing separate development of ESPIPC and what would have been TSUIPC. In order to dispense with ESPIPC, though, I had to do quite a few changes to FSUIPC4 which wouldn't concern the end user nor make it to the History documentation in any case. I'm under a little bit of pressure here to get the next full documented user release done (FSUIPC 4.50) before the end of the month, with a proper installer for ESP and FSX, because the evaluation copies for ESPIPC expire then. On top of this, my own code-signing signature expires in August and I'm having to make other arrangements as none of the established authorities now issue certificates to individuals. Every copy of FSUIPC3 and FSUIPC4 will stop working in August unless I can get a revised codesigned version out and everyone updates before then. I want to allow a good overlap (6 months) so there's no excuse! When 4.50 is released, the interim update in the Announcements above will disappear, as with the PDF. Another will no doubt start up as later interim updates appear. I hope this has made it all clear? Regards Pete

That's what the History document is for. Regards Pete

This is a FORUM. All forums have a list of threads, started by inquirers such as yourself. But right at the top of the forum, before all those, are ANNOUNCEMENTS. These are VERY VERY important as they are my way of informing everyone about my programs and helping them help themselves. I've not idea how you arrive at a Forum and not see the Announcements right at the start. How do you do it? :-( It seems my time trying to help folks in this way is wasted on many. I thought Announcements were bound to be seen by everyone. This is VERY disappointing! :-( Pete

In that case the first so-called [General] section is not seen by windows as a [General] section at all. I notice you always type this as (General), with round parentheses -- if it is like that then it is not a section at all and will be ignored. The lack of a [General] section cannot stop you programming a button -- perhaps you could explain what you did and why you think that was unsuccessful? Button programming does not involve reading anything from the INI -- it only writes the results there for the next reload, and they go into a [buttons] section. Well the easiest thing normally is to paste it into your message, and use the "List" button to wrap it into a scrollable window. It just arrived. There's nothing wrong with your FSUIPC. The reason the first [General] section doesn't work is because it looks like this: Section names must have the line to themselves. Windows won't like all those ^^^^^ you've put in front. The rest of it looks okay. You have quite a few Buttons already programmed, Axes assigned, and calibrated. The only reason you are getting the "second" [General] section is because there isn't a recognisable first one. If you have any suspicions about whether FSUIPC is "working" or not, the INI file isn't the place to look. you should look at the Log file, as i said before. Regards Pete

Aha, now we are getting to the truth of it. Are you saying that none of your axes are seen as axes by FS or by FSUIPC? How are you assigning them, then? How are you seeing that little rudder movement? Obviously I am still not understanding everything you are saying. The Axis assignment facilities in FSUIPC are for DirectInput or Windows joystick axes -- axes that can be seen and assigned in Windows' programs. If your system is getting this information into FS in a different way, then the steering tiller assignment (or any other assignment) is not possible in FSUIPC's axis assignment facilities. If you can access FSUIPC offsets through your system, and provided you can send a control value AND a parameter (the control value to identify the axis, the parameter for the axis readout), I could add a facility via offsets 3110 (command) and 3114 (parameter) to get axis values sent "direct to FSUIPC calibration". The command values would be something like 64000 - 64044 according to intended axis, and then you'd calibrate in FSUIPC as usual. You wouldn't use the Axis assignments facility, that would be bypassed. This is not difficult to do, but it isn't implemented at present. If you think it can be your solution, let me know. Regards Pete

Please see the Announcement above about what to do when you lose your keys. Pete

Sorry, but you'll need to explain some of that. It sounds like you are not using FSUIPC at all for this, so maybe that's the problem? -- What are "Phi Values" and "FS Values"? Where are you seeing those? -- When you say "using Rudder control (Fs Var Assignment) to communicate with FSX" what exactly does that mean? None of these terms seem to relate to anything i provide for the steering tiller axis in FSUIPC, so I wonder why you are asking me the questions in the first place. Perhaps, if you could say EXACTLY what you are doing where, and exactly where you are seeing what, I might understand and be able to help. Please don't tell me things in terms of what Phidgets software may or may not say. I don't know it and so it doesn't help. If you need help with that you'd need to talk to the authors/support folks for that. If you want to use FSUIPC for a steering tiller axis you must assign both the tiller and the rudder axes in FSUIPC, selecting "direct to FSUIPC calibration", and then calibrate both. FSUIPC then uses the tiller axis to drive the FS rudder when on the ground and at airspeeds of less than 60 knots (an adjustable figure), and the rudder in the air and on the ground above 60 KIAS. Below the changeover speed control is divided proportionally between tiller and rudder, so that, for example, at 30 knots it is half-and-half. Regards Pete