Pete Dowson

YesI do! ;-) BTW it is "WideFS" not "FSwide". Oh yes I am! It is almost 100% C, with a little bit of ASM inserted in special places where I didn't like what C did, or where I couldn't do what I wanted efficiently without it. Currently I'm using the C/C++ compiler from Microsoft's Visual Studio .NET 2003, in Native C mode. Before that I used MSVC/C++ 6, and before that Watcom C, Topspeed C, Lattice C (on the Amiga) going back to BCPL in the 70's (BCPL was a forerunner to C). Between 1963 and 1981 I also used mostly assembly code for whatever machine I was programming, though dabbling a bit in Fortran and APL. I gave Cobol I wide berth! ;-) Regards, Pete

Unless someone has changed my original C source code in preparing something for Borland, the Read and Write calls do nothing but add requests into the data area allocated as a memory file by the Open call. There would be no communication to FS or FSUIPC at all. The job of the Process call is to send a message to FSUIPC to ask it to look at the memory file and process the accumulated requests. Not at all. It is the only call which actually talks to FSUIPC. There are Process calls in the Open request too -- to obtain the FS and FSUIPC versions. Having said that, the sources for all the stuff you use in your program are in the public domain and included in the SDK, and anyone may change them. However, including the message calling part of the Process call in every single read and Write request is grossly inefficient, as each such call invokes a process change. Of all the time needed for inter-process communications, it is the process switching which takes the most -- the actual reads/writes (no matter how many) are normally accomplished well within a single millisecond, whereas the process switching and message queuing involved can be tens or even hundreds of milliseconds. I had a quick look inside the Borland ZIP in the SDK and cannot see any library that I'd recognise as such -- I don't know the filetypes BPR and DFM though. Isn't the Borland package there just a wrapper for my original C provisions? Regards, Pete

If the distance is not too far, i.e. the points are close enough to regard the intervening Earth's surface to be pretty flat rather than spherical, then isn't that merely a matter of simply right-angled triangle trig? How did you determine the distance -- wasn't that by similar assumptions, then using pythoagoras? Otherwise it gets more complex for both, as you need great circle calculations for the distance and some spherical trig for the angle. Regards, Pete

I think the program became payware before I started the accreditation system. Abacus Software own the license I think. It certainly would have done with FS2002 and the version of FSUIPC which was available at the time. You are talking about an add-on program with is at least three years old, probably four or five. Assuming it will work with FS2004, yes. Either that or get the Author to apply for a freeware licence for it, which would probably also need permission from Abacus. I would not dare provide access to a commercal program without the author's permission, especially when that might violate some other commercial arrangements. Sorry. If you are using FS2002 or earlier you can do that. You would need to find a version 2 FSUIPC. Most programs like the one you are talking about would have been packaged with a suitable version of FSUIPC in any case. Regards, Pete

Download the FSUIPC SDK from http://www.schiratti.com/dowson. It is all in there. Pete

Thanks. I've released it now in the "Interim Versions" announcement above. Regards, Pete

When you say "often", can we get that more specific? Isn't it only when reloading FS after you have closed it sometime before, in the same Windows session? There are no items relevant to FSUIPC loading other than the FSUIPC.DLL file. The other changes you make cannot be at all significant. The message only arises, on loading FS, if there is already a copy of FSUIPC running in the system. This can occur for one of three reasons: 1. There are actually multiple copies of the FSUIPC.DLL in the FS modules folder. This can only happen if you ever rename the module. NEVER rename the module. 2. If a copy of FSUIPC.DLL, renamed or not, is placed in the main FS folder as well as or instead of the FS Modules folder. 3. Finally, and the most likely, if the previous session of FS is not actually fully terminated. It may look as if it has closed down -- no window, for instance. But check the Windows process list (Ctrl-alt-del, Process list), and see the FS9.EXE process listed. The last can happen when one or other add-in program you have installed (module or gauge) has failed to terminate when FS terminates. This leaves the whole process still running, in the background, on your PC, including FSUIPC.DLL. As an example, one earlier version of ActiveCamera for FS2004 did this -- it never terminated correctly, leaving an invisible copy of FS9 actually running all the time. If this is the case you can recover by closing the FS9.EXE process in the Task Manager's process list, but you'd best be trying to determine what add-in component is causing the problem. Regards Pete

Hi Michael, Found it! A very old error for sure. Please try the attached PFC DLL version 1.993. If this is okay for you too I will put it up with the Interim releases at the top of the Forum. Thanks for your help, Pete PFCDLL1993.zip

Further on this: Hurrah! I can reproduce this. It appears to be irrelevant whether throttles are mapped -- in fact the phenomenon is completely independent of the quadrant assignments, once it occurs. It is obviously a corruption in the 1st Slope table (after the default linear setting, that is), as it affects that #1 slope selection identically on any axis to which it is applied, not just aileron! The interesting thing is that it is not due to the action of selecting a quadrant setting with mapped throttles, nor even using it subsequently. The problem only arises if such a quadrant is active when FS is first loaded. So it is something to do with initialisation of the slope tables. RightI have a lot of clues, now to dive into the code! ;-) Regards, Pete

I'm afraid I don't know their software. What sort of "assignments" can you do? If you cannot test values in FSUIPC offsets then I don't think you can use it. You'd need to be able to differentiate between 0 (off), 16383 (hex 3FFF, green) and any other value (red). Regards Pete

Okay -- that's good information. It indicates a corruption in the table for the one curve. With your INI (now received) I should be able to locate that and fix it. For now, use one of the response curves that works! ;-) Regards, Pete

It is part of a large data area for many FSUIPC-maintained values, and, yes, it is all zero to start with. It should be zero if the aircraft has never been airborne, but that does depend on my code seeing the "aircraft on ground" flag. If during initialisation, that flag is zero then there is a possibility that an uninitialised value from FS itself is being copied in, at FS load time. The same value would also be seen in 02C8 though, albeit transiently. I'm not sure if there's a way I can prevent that -- if the user deliberately starts FS with the aircraft in flight then I have to do this in any case. Quite honestly, I never expected folks to want to know the touch-down V/S before they've even been flying. That would probably be too late if this is occurring during FS initialisation. I don't think FS's monitoring starts that early even if it was enabled on the previous session. If the aircraft has never been airborne to you or your user's knowledge, what would be the use of this value? I must admit I am rather bemused here about what the problem really is. If it is just some sort of initialisation problem then I could probably try to delay its update until FS is "ready to fly". this is some seconds after it looks ready, for safety, about the same time, for instance, as I start up WideServer. Regards, Pete

And no filtering, just in case, please. Regards, Pete

The units are 256 * metres / sec in any case, as they are for 0ffset 02C8. -59999 would convert to -12.8 ft/min. If this is after you have done such conversion, how does it end up with such an interesting number as 59999? Do you limit it? The location 030C is not in FS, it is local to FSUIPC, and it is only updated whilst in the air. As soon as the aircraft touches the ground, the last value written there is left untouched, until you are next airborne. On FS2002 and before, it is copied from 02C8 whilst in the air. On FS2004 (only) it is copied from the place in FS where 02C8 in mapped -- somewhere within FS's SIM1 private sim data. No, as the data source is the same as for 02C8, and in any case the value isn't touched whilst on the ground. Why not use FSUIPC's own monitoring facilities to log the values both in 02C8 and 030C? See the Logging page, right hand side. Log as type S32 to the normal Log, then compare the results from the two locations on during a landing. Don't enable this logging too long before the landing as the log will get rather large. Log the "aircraft on ground" flag too (0366, as a U16) so the moment can be seen. Regards, Pete

That's the sort of thing which would give the results Michael is getting. On my Jetliner yoke the left side of the aileron is playing up too -- jitters up and down a bit near the centre of the left side movement. I have proven it is definitely the hardware input -- I think it needs a new pot, or at least a clean in there somehow. I don't currently use it for real flying only testing, so I've not asked PFC about it yet. The one in the 737NG is fine. Phew! That doesn't sound good. Their build quality is usually very good indeed -- you must have been very unlucky! Were any of those other things responsible for jitter in the aileron, though? Surely that was all down to the pot? Regards, Pete

Well, I've tried all sorts of things and cannot make anything go wrong here. I am using a slightly later version of PFC.DLL, but the changes are only in relation to PMsystems and overgead switches in the PFC 737NG. I definitely need your PFC.INI so I can check with the same options and selections. Tell me also: 1) which user config in your setup you are selecting 2) using Throttles R12, R34 or just forward thrust 12, 34? 3) Flitering on or off? 4) Slope selected or flat? You say that the little dot on the Slope depiction zooms off the wrong side, but that is manipulated by the driver. Please watch the "input" value for the aileron, the first figure under the little "RVS" checkbox. Does that undergo similar sudden changes? If so, then it is definitely something on the hardware side, as that is reflecting the raw input. Let me know these things, then we'll try logging to get hard data. I attach PFC DLL 1.992, just to be sure we are using the same version. Please do the tests with this from now on. (Note that the Version Info on this build says 1.991 -- there's no difference, both were internal builds on the same day). Regards, Pete pfcdll1992.zip

What version of FS? What version of FSUIPC? Check the FS Modules folder, look for a file called "FSUIPC.LOG" -- show me that. By "installing" and "upgrading" FSUIPC, what do you actually mean? The entire process for both events consists purely and simply of copying the FSUIPC.DLL into the FS Modules folder. Do NOT put it into the main FS folder. In that case it was NOT "FSUIPC.DLL" which you "uninstalled", since there is no other change made by FSUIPC -- if it is in the FS Modules folder, it is loaded by FS, if it isn't, it isn't. It is as simple as that. You probably "uninstalled" something needed by FS, one of its own modules (maybe "FSUI.DLL, the FS User Interface?). Most DLLs in the Modules folder are part of FS and needed by FS. And what EXACTLY is the 'result'? FSUIPC does very little by itslef. Simply copying the DLL into the Modules folder installs it, but if nothing uses it , it does very little. Certainly nothing to stop FS running. Please describe EXACTLY what you are doing and what you see, and show me the FSUIPC.LOG file, otherwise I really cannot help you. There are many thousands of users who simply copy in the DLL and forget it. It is not a complicated thing to do! Regards, Pete

Yes, from Michael's description it does sound as if it MUST be hardware in origin, as I think the calibration displays are showing the raw inputbut maybe the "slope" tables come into it. I need to check. What is so odd in Michael's case isn't so much the wrong deflection (which can, I think, be a little "dead" spot on the pot or something else electrical in the controller) but that, by his testing, it only happens when he has mapped the throttles! I need just to be sure there's no corruption occurring internally to the driver. Once I have checked that here and found no sign of it, then I will have to ask Michael to turn on some Comms logging to check the raw data arriving from the PFC controller. May I ask, in your own console repair, what did you actually do? Was it a change or clean of potentiometer? Or something electronic? Regards, Pete

Could you Zip up and send me the PFC.INI file from the FS Modules folder, please? (petedowson@btconnect.com). I'll try checking this out tomorrow -- if I can't reproduce it here I may ask you to do some tests for me with different options. Seems odd that no one has reported it before if it is in the old version too, so maybe it is related to specific options, slopes, etc. Thanks, Pete

Hmmm. I'm not at all sure how to interpret the information you've provided. Are you actually saying it ONLY occurs with the PMDG 747? The Flight Controls page in the PFC driver Options should really only be reflecting what is being input from the hardware, so I would first suspect the pot on the yoke -- a dirty section perhaps. But then you'd expect to be able to see this no matter what aircraft you are flying. Certainly, whilst in the PFC options the current aircraft loaded in FS shouldn't matter at all -- unless for some reason its activity is interfering with the PFC link to your PC, but I really can't see how that could be. Even if it were, you'd expect that to play rather random havoc, not a specific type of error. So you are possibly deducing that it is related to the mapping of the throttles, independent of the aircraft itself? Can you verify that with, for instance, the default 747? Is it only since you purchased the PMDG 747 that you have been mapping the throttles linke this? I'm not set up at present to conduct experiments on this here, but I will within the next few days. Meanwhile, any further information you may find will be useful. Oh, could you try the current "official issue" PFC.DLL (from http://www.schiratti.com/dowson) just in case it is some problem introduced over the last year or so. Thanks. Regards Pete

There's no difference in the handling of any one throttle over another in FSUIPC. Re-chack your assignments, calibrations, and in particular the FS sensitivities and null zones. Make sure you have a good "idle", as without idle you cannot engage reverse. Check that the lever itself is okay be swapping assignments over, say, between Throttle 1 and 4. Lastly, check and report the "INPUT" values for that lever, as shown in FSUIPC and compare them with the others. Pete

Sorry, but I think you are rather confused. FSUIPC 3.53 does not assign axes at all, that is done in FS -- go to Options-Controls-Assignments and check the FS settings. FSUIPC only does final calibrations, completely optionally. Do not use it first, get it working in FS first. Pete

I'm afraid I can't advise on hardware programming it -- SimKits needs to do that, but the three reds and greens can and should be operated easily from the three indications in FSUIPC offsets 0BEC, 0BF0 and 0BF2, as documented in the FSUIPC SDK. You don't need any artificial delay -- the gear positions in those offsets show when the separate gears are fully down (16383) = green, and fully up (0) = off, else they are in transit, = red. Regards, Pete

Yes, of course. FSUIPC does not (cannot) operate FS's menus. When FS is in any of its menus, the User is in control, not the program. Automatic facilities provided via FSUIPC are for automatic use. User facilities via menus are for real users, on keyboards and such. Regards, Pete

Sorry, you are losing me now. If you know what the indicators actually mean, then surely you know what values trigger them? How else are you going to know what they are for or what to do about them? I really don't know what you are doing, but I am assuming they are warning lights for low levels of oil or fuel, or high temperatures or pressures? The levels, pressures and temperatures are available 9they are displayed on gauges, for instance, and are listed in FSUIPC's lists of values). The warning levels will vary from aircraft to aircraft -- that's for you to determine from aircraft spcs etc, surely? Pete