Pete Dowson

The "sig" is not visible when replying. I click reply (with quote) and see you message, nothing about any "sig". So I stop replying, go back, view the "sig" and see you mean FSX, but still nothing about what version of FSUIPC, whether you are using a supported version, nor if you have even registered it or are using it for anything! What winds control? There's no "winds control" in FSUIPC. It isn't a weather control program. So you don't even mean "back and forth" but "left and right", rolling? You implied it was an forward/back or up/down movement, which is why I suggested elevator or elevator trim! Maybe you have excessive turbulence from whatever weather program you are using? In FS9 you could suppress turbulence even from other programs, but in FSX the weather control is usually direct via SimConnect., so FSUIPC does have the option. Among other reasons for poor autopilot control at altitude is being overweight. Are you climbing too high before burning off enough fuel? A/Ps have limits, and the more realistic the simulation the more this will be evident. See if you get the same problems with less fuel, or less payload (throw the passengers out). Pete

So, does the CPFlight driver for the MCP work directly with FS, or does it need FSUIPC as the interface? I think it used to use FSUIPC. If it uses the programmable interface you wouldn't see any assignments. That's a bit pointless, because the problem you are talking about (" when increasing speed on my MCP : the view changes to right vc view") surely needs you to increase the speed on the MCP. It's only the events during that process that are of the least interest. You only need to get everything ready, including VC, then start the Event logging, do a quick speed increase, see the view change, then terminate FS. That should not give a huge log. And you could always cut the extraneous stuff off. BTW using the code parentheses is no good without selecting the text first. You merely parenthesised nothing! ;-) Have you checked with cpFlight and the aircraft makers about this, BTW? Even if you got the correct logging all I might be able to point out was whether it was more likely to be a cpFlight driver bug or an aircraft bug. If the Event logging still contains nothing different to what you posted last you will need to enable ipc Write logging -- another of the Logging options you'll see -- and try again. It might be that the cpFlight driver is using the wrong length for one of the variables it sends to FSUIPC, and that is corrupting something else. Those sorts of things will often be different between FS9 and FSX. Regards Pete Regards Pete

Strange. Used to work. You might need to make use of the 'phone support. But your brake pedals ARE axes, so calibrate those two. You mean they DO release with only one press of Ctrl . ? You don't say what the calibration problem is? Are you sure it isn't just the lack of a null zone setting in FS? The PFXC stuff is all really excellent, but calibration and so on isn't really much different from any other controls. For their USB stuff they have and supply a calibration program, I think. Regards Pete

There's nothing in FSUIPC which does things without you or some other application asking it to. FSUIPC is just an interface for other programs to use in order to connect to FS, and a utility for users to choose from an assortment of options. FSUIPC does not act of its own volition to interfere with your flying. That would be rather stupid, don't you think? It sounds like you have conflicting elevator or elevator trim assignments and jittery controls. But since you don't even say whether you are using FSUIPC for anything, nor even whether this is about FS9 or FSX or some other FS, I can't really help further. If you do want specific assistance you need to specify which Flight sim you are using, and also the version of FSUIPC -- assuming you are a registered user. Please also note that I don't support old versions, so if you are using anything before 3.98 (for FS9 or before) or 4.60 (for FSX, ESP and Prepar3D), then please update and re-test first. Regards Pete

Really? That seems to contradict what appears on its website at this page: http://www.flypfc.com/index.php?page_id=4 I've never heard of locking toe brakes. And Ctrl . operates the PARKING brake, not the toe brakes -- if engaging the parking brakes actually removes braking then it sounds like you have assigned to the parking brake not the toe brake axes. Or do you mean using Ctrl . twice, to toggle the parking brake on then off? What is more likely the case is that your brakes aren't properly calibrated. Did you try calibrating in Windows game controllers applet? You should also apply a little null zone (one of FS's sliders) so that when you are using the rudders you are not accidentally also applying brakes. You should be able to apply a bit of top pressure on the levers before the brakes engage at all. Pete

But I just told you that if you weren't using at least 3.98 to update! :roll: Version 3.96 is very old and completely unsupportable. Where did you get it 2 days ago? Please update to at least 3.98, from the proper download site (www.schiratti.com/dowson) as linked from the purchase page at SimMarket. Even 3.98 is now a year old and it will actually be superseded next week by 3.99. I am just finishing off the documentation updates now. Always make sure you are up to date before you come for help. Where does it tell you to do this? Naturally, if you want to assign axes in FSUIPC you should unassign them in FS (you certainly don't want things doubly assigned), but it never tells you that you MUST assign in FSUIPC. Why do you want to? I can't help you with such an out of date version. There were problems in 3.96 with joysticks timing out, which is why it was not on release for very long. Update and try again. Please don't come back here until you've installed a supportable version of FSUIPC. I really cannot support old versions. Pete

Thanks for confirming this. Hope you find the fix. Regards Pete

Hmmm. Did you not think to look at the other recent thread in this forum, entitled "Wico Airbus Throttles ", just about 10 entries below your new one? This is one advantage of Forums, that you can find answers already there. You only had to look a little. As far as I know, at least as applicable to the (earlier?) Wilco Airbus A320 release for FSX, is that it simply needs straight-forward AXIS THROTTLEn SET assignments with the original range, -16k to +16k, all forward, no reverse zone. You can achieve this by assignment to those controls either in FS or in FSUIPC. That's no problem. But in calibrating, you then need to select the NRZ (No reverse zone) option, AND you need the UseAxisControlsForNRZ=Yes parameter set in the appropriate [JoystickCalibration] section of the FSUIPC4.INI file. This is documented in the Advanced User's guide and it does explicitly mention the Wilco A320 -- you could have searched for it, as I just did. If it isn't calibrated in FSUIPC and isn't assigned in FSUIPC, then something else is wrong with that aircraft and you need Wilco support, because FSUIPC isn't involved. If it isn't assigned in FSUIPC as "direct to FSUIPC", and isn't calibrated in FSUIPC, then FSUIPC is having nothing to do with it. If it is assigned to the standard AXIS THROTTLE controls then it is not terribly relevant whether it is assigned in FS or FSUIPC. It is still not processed in FSUIPC unless you have enabled its calibration, and i already told you that and how to turn it off. Well, I've given you what I am assured is the definitive fix, above, one specifically designed for the Wilco A320, but ignore that if you wish. Just don't calibrate in FSUIPC instead, as I've now said three times. Regards Pete

Latest version? What is the version number? Is this version 3.98 or 4.60, or 3.989z or 4.669? You need to be more specific. I don't even know if this is for FS9 or FSX. What are you trying to do with FSUIPC? Do the throttles work in FS with FS assignments? Do they work with other aircraft? Where does FSUIPC come into this? Er .. ignore axis in the axis assignments page only ignores it so you can assign another axis when you have a troublesome one which jitters so much you can never see another. As soon as you exit that TAB the axis is not ignored. The calibration pages only show FS axis controls, not any specific joystick axes. For any joystick axis to show there it must be getting assigned somewhere. If you assign an axis to a calibratable control (whether in FS otr FSUIPC) you can calibrate it in FSUIPC if you like. You don't have to, but you can. If you want to calibrate it you press the "Set" button (so it changes to "Reset"), and if you have calibrated it but don't want to you simply press the "Reset" button and it changes back to "Set". When that left hand button says "Set", FSUIPC is not calibrating the control, it is not doing anything to it at all, it is merely showing you what values are being passed on to FS from your joystick assignment, wherever you have made it. Get your throttles working properly with default aircraft first. When you've done that -- and it doesn't matter how -- only THEN try an add-on aircraft. If normally assigned (in FS) throttles don't work with an add-on aircraft you must seek a fix, or at least an explanation, from the makers of the aircraft, because surely they should make aircraft which are usable with standard FS-accepted joystick controls. If you have messed about in whatever unknown version of FSUIPC you have and are not sure what you've done, try deleting the FSUIPC (or FSUIPC4) INI file, so it loses all your settings, and starting again. Maybe something you've done earlier is now confusing you? Regards Pete

Hmm. I don't see anything wrong there apart from the failure to connect. Seems the system clock is wrong on one of the two PCs though as those logs start 22 minutes apart and you closed FS down after just over one minute of starting it. Are you sure you are giving it enough time? Is that IP address, 192.168.1.138 the same one as shown in the WideClient log file when you connect to FSX? One possibility which this wouldn't show is a firewall on the server PC. Possibly you have a firewall up and have allowed FSX.EXE through but not FS9.exe? I can't see any other possible reason for what you are getting. You might want to try a more recent version of WideClient, though, just in case. See the Download Links subforum. Regards Pete

I need to see the WideClient.log from the client PC and the FSUIPC.log and WideServer.log files from the FS9 modules folder. Please close down FS9 and WideClient first. You can paste the contents of the files in a reply in this thread. Please try to enclose the text in "code" parentheses (the <> button above), as this makes it easier to read. Regards Pete

I have moved your post from the "FAQ" subforum. It won't get a reply there. That's a repository for Answers. For support please always use the Support Forum! I always need to know FSUIPC version numbers. You can find them on the main About tab in the options, or in the Log, or in the DLL properties. If you are not using at least 3.98 then update first. Why are you disabling joysticks in FS9? If you do that you will have to do all the assignments in FSUIPC. You don't need to do this just for calibration.in FSUIPC. Where are you looking to see "joystick functions" and what, exactly, do you mean by them? There is nothing special or different about any of those CH devices, they are standard joystick connections and have always worked with every version of FSUIPC. I'm afraid you'll need to explain things in rather more detail. Remember, I can't see what you are doing from here. Regards Pete

You can paste the contents of the Log in a message here. It would be neater if you enlosed it, not as a Quote (like above) but as "code" -- the button looking like <> above. I don't know how you've assigned the functions, if you have, or if they are supposed to emanate directly from the cpFlight driver. So we might need to proceed in steps. In the first instance, only put a check mark against "Events". Don't touch anything else on that tab at all. Not yet. Keep the session as short as possible, only enough to reproduce your problem. Then close FS. Paste up the whole log, and describe exactlyt what you did. Regards Pete

Great! Could you do us a favour, please, and post this with a suitable heading it the User Contributions subforum? That way it remains a reource for others. Left here it will scroll off and disappear pretty quickly. Thanks! Pete

That doesn't mean FSUIPC4 is the cause, and it certainly doesn't happen IN FSUIPC4 as you saw. There's obviously some interaction going on. I assume you don't have an EXE.XML? In the DLL.XML try changing things like this, temporarily, to stop possibly clashing programs loading: <Launch.Addon> <Name>RealTrim</Name> <Disabled>True</Disabled> <Path>.\modules\realtrim.dll</Path> <Commandline/> </Launch.Addon> <Launch.Addon> <Name>FSCopilot</Name> <Disabled>True</Disabled> <Path>Modules\FSCopilot.dll</Path> </Launch.Addon> </SimBase.Document> If that fixes it, it is either "RealTrim" or "FSCopilot". So try re-enabling one of them to see which it is. There were versions of FSCopilot that didn't get on with FSUIPC at one time,. When you do find it, you can look for an updated version of that package, or you can also try changing the loading order. For example, move that FSCopilot ahead of FSUIPC in the list, or RealTrim after. Regards Pete

Yes, just the integral number of degrees. You can't set fractional a values on those things. Well, that's not FSUIPC or FSX. It arises from the units adopted originally by FS98 way way back in time. FSUIPC's interface derived from a previous program called FS6IPC by Adam Szofran (who later worked for Microsoft Aces). The whole point of FSUIPC through out its long life has been to maintain compatibility, through FS98-FS2000-CFS1-FS2002-CFS2-FS2004-FSX-ESP-Prepar3D, so I could never change things applications already used, only add new things. The offsets for OBS date right back, but so do the more complex ones like latitude and longitude, to FS6IPC which merely provided a window into a memory area of FS98 itself, no manipulations, no cloak and dagger maneuvering. The usual reason for the odd looking units is efficiency. PCs weren't as fast back then, and were certainly nowhere near as efficient as they are now at large floating point computations. Most of FS's calculations were performed using fixed point arithmetic, so values were stored in fixed point ways. The typical heading and other angular values stored in 16 bits are stored with as much precision as possible by making the maximum value you can possibly fit just a tiny bit less than 360 degrees. Hence 65535 = 359.99999... degrees, and you get the formulae you see in the FSUIPC references (multiply by 360.0 and divide by 65536.0 for degrees in floating point). 04CE and 05CE only ever need to contain a simple small integer, so they do. They would be only 1 byte each is 0-255 were enough, but of course it isn't. These days, internally, FS9 and FSX are relatively wasteful in memory -- because they can be, memory is so much more available. They use 32 bit values just for a 1 bit indicator (1 = "TRUE" or 0 = "FALSE"), and full 64-bit floating point for most all computations because it is now as fast as, or even faster, than fixed point. A lot of those new values are exposed in FSUIPC's offsets. Additions have been made through the years as other values become useful to applications. But the old values still remain, for compatibility. Regards Pete

It is the "Course" setting on an MCP or a VOR/ILS, not just on an HSI. But it was always known in FS as the "OBS" (Omni bearing selector, a VOR being an omni-directional radio). There are two, one for NAV1 at offset 0C4E, and one for NAV2 at offset 0C5E. There are FS controls to change them too of course. Those use the abbreviation OBI (omni bearing indicator): VOR1_OBI_DEC 65662 VOR1_OBI_INC 65663 VOR2_OBI_DEC 65664 VOR2_OBI_INC 65665 Regards Pete

Did you run the search as administrator, and with system and hidden files enabled? It is obviously there someplace. Windows wouldn't invent a DLL name to deliberately mislead you in its crash data! You could proceed in the other direction. If it is crashing during loading FSX, then, since it is not part of FSX itself it must be getting loaded by one of the applications SimConnect loads. Check your DLL.XML and EXE.XML files for what you are loading automatically with FSX, and maybe disable them in turn till you find the culprit. Regards Pete

Sorry, but this isn't really related to FSUIPC4. You have some other add-on there. "CONVINST.DLL" isn't part of FSX nor anything to do with FSUIPC4. You'll need to check the other add-ons you have installed. It doesn't appear to be part of Windows nor any development system I know of, so I think it must belong to a third party add-on. find out where it is and check its properties to see who made it, if they own up to it there. Regards Pete

How strange. Have you tried logging Events in FSUIPC? The log might show what controls are being generated. I really have no idea. Nothing in any software I've ever been involved with has different affects in VC compared to 2D mode, except panning versus view selection. Certainly nothing to do with sending increments or decrements to an autopilot value. More information is needed. Try the logging, always a good first step. Regards Pete

Assuming it is only that aircraft which gives this double click result I think that sending the command to FS does the toggling okay, and the aircraft gauge sees this and alters its switch, which in turn sends another control. I wouldn't think there was any way around that without a fix in the gauge. Possibly the switch can be operated via Local Panel variables (L:Vars)? Regards Pete

Good. Thanks for getting back on that. Regards Pete

It sounds like interference between components or chips inside the beast. I certainly think you need to contact PFC, yes. To compare results here with the Cirrus Pro I've done exactly the same as you -- deleted my INI, checked the default assignments (which are wrong at present, as I have already explained), and assigned the Quadrant axes one at a time, and so on. I don't get any random fluctuation on any axes, they are all as steady as a rock. And certainly the flaps lever just does what it says. Next week,, or even possibly over the weekend, I will Release 3.99 which fixes the default assignments, which should at least remove any chance of jitter on your three unused axes interfering with the used ones, but there's certainly nothing i can do regarding the weird flap switch interactions. And you shouldn't really be getting jitter in any case -- that's usually a result of a poor power subbly or varying temperatures or humidity. Sometimes dirt, but that manifests itself as jittery movement when actually using the controls, not when they are left alone. FS will show "differential braking" for even the smallest difference between left and right input values. It shouldn't matter as you don't look at that when braking -- you look at the runway or taxiway ahead and simply brake and steer to keep straight. Certainly if they are calibrated correctly you should have a dead zone at the brakes off end, so they don't come on when using the rudder only, and also a dead end beyond the maximum, so you can always reach maximum pressure. In the latter case, pressing fully on both left and right should give just "brakes" not "differential brakes" because both will be sending the same max braking value. If not you've set the maximum wrong in calibration. I have FS set to show none of those unrealistic red messages on screen. I have an older PFC rudder with digital toe brakes (i.e. not analogue -- they are either full on or full off), so I can't test with the Cirrus. And in any case they don't work as they are with the Cirrus because the connection (an older Game Port type D-connector), whilst plugging into the Cirrus, is not recognised. They did say they were going to tell me how to get over that, but nothing happened about it. As I don't use the console in any case it didn't really bother me. [LATER] Just looked at your INI file. I see the quadrant calibrations are better, but the brakes: LeftBrake=-16380,16380 RightBrake=-16380,16380 are left at the default values, so you've not actually calibrated them yet? Regards Pete

Correct. It's pretty much the same with all PMDG aircraft I'm afraid, though we are still hoping for a more open attitude with the forthcoming 737NGX.. In the early days, for FS9 aircraft, PMDG did say they were going to release an SDK but I think they changed their mind and only sold it to some hardware manufacturers with strict NDAs -- or at least only a few could afford it.. Sorry, no. Whilst I did use to hack into Flight Simulator itself to find things, back in the old days (before SimConnect), I wouldn't be able to do it for 3rd party add-ons without violating the trust between us. If PMDG don't want folks to know, that's their prerogative. As an individual and for private use I don't suppose anyone would mind, but I am another software publisher. Well, since you are talking about the FSX version, the PMDG 747X, have you had a look to see if they are using Local Panel variables (L:Vars) for any of them? There are facilities in FSUIPC4 to list them in the log, and there's a Lua plug-in provided to display them with changes as they happen. Many newer aircraft add-ons for FSX use XML gauges, and most of those do seem to depend quite heavily on L:Vars. But PMDG still write most of their code in C/C++ I think (more compact, more efficient, more work), so it is less likely that you'd find the values you need. But it is worth a look. Another possibility is that they use SimConnect custom data, which can be read and written by other SimConnect clients provided you know the name to use to open it, and the position and nature of each of the values within it. Regards Pete

you can probably adjust any specific aircraft's performance by experimenting with parameters in its Aircraft.CFG file. For instance things like (these are from the default C172 in FSX): ;Moments of Inertia empty_weight_pitch_MOI=1400.0 empty_weight_roll_MOI=1137.0 empty_weight_yaw_MOI=2360.0 empty_weight_coupled_MOI=0.0 and even more likely: [flight_tuning] cruise_lift_scalar=1.0 parasite_drag_scalar=1.0 induced_drag_scalar=1.0 elevator_effectiveness=1.0 aileron_effectiveness=1.0 rudder_effectiveness=1.0 pitch_stability=1.0 roll_stability=1.0 yaw_stability=1.0 elevator_trim_effectiveness=1.0 aileron_trim_effectiveness=1.0 rudder_trim_effectiveness=1.0 Regards Pete