Pete Dowson

Yes, it sounds exactly the same as the intermittent problem I had. Must be a bit of a design weakness in that area. The last time I did it was so long ago I don't recall, and I'm not taking it apart just now because it is working fine and the purchaser is collecting it this afternoon! ;-) Anyway, all I did was take the screws out holding that panel (just two on each side I think, and by the look of it), carefully lean the panel so I could get into the back of it, and widdle/tighten/check every connection or plug-in I could see might be associated with those switches. Then screw it back in place. I can't really describe it in any more detail. If in doubt, best to get PFC's advice. Best, if you want any support,to keep it up to date, please. I know the changes listed probably don't affect you a lot, but still. I always need to compare with what happens here, and I always use the latest. 4.34 is current. How do you mean, "gone"? See the buttons at bottom right? Predefined set 1 provides Panning, like a hat, on the right rocker buttons, with no assignment when released. Predefined set 2 provides the discrete views as you describe, with reset to forward when released. The panning is best for virtual cockpits, the discrete views best for the 2D ones. And no matter which set is selected, all of the usefully assignable FS controls are there in the drop-down, including the ones you mention. PFC gets this list from FS, using pointers and readouts provided by FSUIPC, so if it isn't appearing there it presumably isn't appearing in FSUIPC's assignment drop-downs either. Which means you have something seriously wrong with your installation -- either FSX is corrupt or FSUIPC4 isn't connecting correctly with SimConnect. Check your FSUIPC4 version (current is 4.40 but there's a better 4.438 in the Updates) and the FSUIP4.log file, see if any problems are reported. But update your PFCFSX first please. Regards Pete

Beacon? I listed that as bit 1. AND I already listed the value for that: 2! remember? See here: bit 0 = value 1 bit 1 = value 2 bit 2 = value 4 ... bit 8 = value 256 bit 9 = value 512 So the parameter is2!!! (In hex it would bex2, or x0002 if you like, but leading 0's mean as little as they do in decimal!) You don't need to convert things into hex if you know the decimal. Just enter the number. FSUIPC will change it to hex, but you needn't worry about that. Pete

Please don't worry about it. My brain has always been more agile at night! I make all my mistakes in the mornings and fix all my bugs at night! I should really only ever programme at night, then I wouldn't make so many! ;-) Regards Pete

Yes, but you need to use a rather technical facility in FSUIPC which works on the Offsets as used by application programs. The offset for all the lights is 0D0C. It has one bit for each light, as follows: 0 Navigation 1 Beacon 2 Landing 3 Taxi 4 Strobes 5 Instruments 6 Recognition 7 Wing 8 Logo 9 Cabin You need to assign to two special FSUIPC-added controls listed in the Advanced User's guide called Offset Word Setbits (to switch one or more lights on) Offset word Clrbits (to switch one or more lights off) You will find both of these in the drop-downs, for assignment. You must provide the offset (x0D0C) where it says, and a parameter too. The parameter is the value of the bit for the light you want to change -- or the addition of values for more than one at a time. Compute the values by powers of 2. i.e. bit 0 = value 1 bit 1 = value 2 bit 2 = value 4 ... bit 8 = value 256 bit 9 = value 512 Okay? There's a lot more you can do with these types of FSUIPC controls, but you really then need to refer to the FSUIPC Offsets documentation to know where things are and what they do. That is only available in the FSUIPC SDK, freely downloadable. All SET type controls need a parameter value. If that one actually works (I've never tried it), it will use the parameter value as an on / off control -- 0 for off, 1 for on. Regards Pete

Good! I am so relieved! ;-) No, I am in the UK, the times were between 12 midnight and 3:46 am. I can never sleep on a serious problem, not unless I have the solution in mind -- and then I can only leave fixing it till morning if no one is dependent on it. This one was so serious I had to pull the Updates off the Server till I fixed it! Regards Pete

I'm not aware of one fitting your description, but there have been changes, and it would be best to try the latest update from the Updates Announcement, please. Let me know. There have been a lot of changes recently. Most of those affecting user facility enhancement are documented there as well, but not all the small improvements and bug fixes which would not affect many folks. When did you try the links? I took the previous update off-line for a couple of hours (between 0200 and 0400 am here in the UK) whilst fixing a serious bug with the INI file being corrupted. Try again please. Regards Pete

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