Pete Dowson

Even unplugging them and plugging them in again? Either way, it's a very telling fact. I don't know what P3D is now doing, but it is certainly succeeding in messing things up. I think you need to report this on the P3D forum, with a request that when controllers are disabled they don't touch any USB devices at all. I really can't see another possible solution. i can't imagine what could be happening to make devices unrecognisable afterwards like that. Maybe also a report to PFC? Maybe they can understand what can happen on the USB ports, though maybe not as I suspect they buy in standard USB chippery. I'm not sure I can advise anything more productive at present I'm afraid. EW321, who contributed above, tells me he also does get a few "error 2" reports on the avionics stack, but nevertheless it carries on working. Some sort of timing or hardware difference, maybe? Are you using Windows 8 -- that could be a significant factor too. I think EW321 is using Windows 7. Pete

Hmm. Strange, because there's absolutely no difference in FSUIPC or PFCHID in dealing with any devices whether you are using FSX or P3D (or indeed, any other version of FS back to FS98). So i'm at a loss to understand why using P3D can mess things up. One thing to check: have you disabled controllers in P3D? Maybe it is doing something with those USB ports when PFCHid is also trying to get things sorted. That certainly indicates some sort of USB problem. So does nothing then allow PFC's test program to see them again until, what ... PC power cycle, USB re-connection, what? That also implies that P3D is doing something which has messed things up. I know P3D 2.2 now does something different for Joystick devices than it used to -- part of L-M's attempts I think to get over all the problems folks were reporting with joysticks and Windows 8. Those affect FSX as well, of course, but no one is amending FSX any more, and folks are instead solving it by disabling controllers in FSX and using FSUIPC exclusively. Can you clarify whether the logs refer to the exact same test session? The FSUIPC log shows only one significant entry: 184908 ***** HID USB device reconnected: re-initialising FSUIPC connections Is that when you unplugged it and re-plugged it? The PFCHid log shows both the Console and Avionics are detected, but: 15: ... Ok, added as device #2 10218: **** ERROR: Device #2 command discarded due to "WriteFile" failure [00000002] 20249: **** ERROR: Device #2 command discarded due to "WriteFile" failure [00000002] 30280: **** ERROR: Device #2 command discarded due to "WriteFile" failure [00000002] etc, ad nauseam. Every attempt to send data to the Avionics encounters error 2, which is "file not found" -- in other words the device is no longer there! Of course nothing is sent at this stage to the console, so no error is reported there. There are only two things I would have suggested, but since you presumably have no trouble with FSX (?) maybe there's only one: 1. Check the USB connection. Avoid using a hub if possible -- if not possible make sure it is a good quality powered hub. 2. Make sure controllers are completely disabled (not just de-assigned) in P3D. There is just one checkbox I think. #1 is probably not applicable if it is all okay, consistently, with FSX. Obviously it is possible to make these things work with P3D 2.2, because Thomas (EW321 above) confirms this. I can't think of anything else but the above at present. Oh, one other thing. Instead of unplugging them and plugging them back in again, see if going into FSUIPC's options, selecting either Axes or Buttons & Switches, then simply exiting again helps. That should also re-scan USB devices and might also do the job. If not, then there's definitely something messing up something deeper in Windows, as in fact your report about the PFC test program indicates. Pete

Only if you do get a crash. I'm awaiting confirmation of other changes, for the Radar Contact window, before i make a formal release. It'll be 4.933. Pete

Really? When I had the Cirrus the yoke was definitely always treated as a normal joystick. I do have support for aileron and elevator built into PFChid, but I'm pretty sure I never had it routed that way. Strange. Yes, but of course you can do that with any joystick type device axes. Anyway, I would need to see what the OP has got in those files. I'm wondering if he actually has a Cirrus configured for a third party seller, like Elite. I know the older serial port devices made for Elite won't work with my drivers. The protocol is completely different. Pete

You've not supplied enough information I'm afraid. Some clarifications: 1. The connection of the PFC USB devices through PFCHid and FSUIPC is totally independent on the version of flight simulator used. There is no difference between FS2004, FSX, P3Dv1 or P3Dv2.x in this regard. 2. The yoke (and pedals if connected) on the console is NOT handled by PFCHid. It should be recognised as aileron, elevator (and optionally rudder and toe brakes) directly in P3D and in FSUIPC's axis tabs. So, questions: 3. Have you not used this console before? Is it new from PFC? 4. Does P3D see the yoke? 5. Is the a PFCHid menu entry in the P3D Add-Ons menu entry, as well as an FSUIPC entry? I need to see the following files. Paste them into a message here or Zip them together and send them to petedowson@btconnect.com: FSUIPC4.LOG FSUIPC4.INI PFCHID.LoG PFCHID.INI You will find them all in the P3D modules folder. There are other tests you should do as well. I think PFC provide or make available a test program for their USB devices, called something like "PFCtestGUI". (not sure about that). Did you get it with the device, or can you obtain it from them and run it to see that the devices are indeed working properly? Download and run this program of mine: HidScanner It produces a log file, displayed on screen and written to the folder in which it is run. Show me that log file (or include it in the Zip you attach). ("Hidscanner.log"). Really it is PFC's job to support their devices, but I'll see what I can do once I have the information. Pete

I've fixed the P3D 2.x call for Traffic Zapping and tested as best I can here. Please try the interim update and let me know. Download FSUIPC4932bTest and try it. Please let me know as soon as you can -- I'm on holiday from Saturday for 10 days and would like to get this sorted and release 4.933 before then if possible. Thanks! Pete

Okay. I made a couple of changes. I don't know if they'll help because I'm not really sure where the problem is arising. i'm now checking the coordinates and making sure that the docked window is within the confines of FS's display. And I've separated the code more from some new code added recently to support the WideFS Lua "TextMenu" facility. I'm suspicious that there may have been some unwanted interaction there even when the latter isn't actually in use. So, I need feedback, please. download FSUIPC4932bTest and try it please. Let me know as soon as you can -- I'm on holiday from Saturday for 10 days and would like to get this sorted and release 4.933 before then if possible. Thanks! Pete

There's no "P3D release" of FSUIPC, there has just been a constant series of updates of FSUIPC4 for the last 9 years. P3D support has been included for several of those years. The "Radar Contact" window support is the same as the support for Lua display windows and so on. They are all part of the one FS facility. I don't know why you are observing a problem recently which you'd not had before, but nothing anywhere near related to these Windows has been knowingly changed for years. Maybe there is a new problem, but i would need to know more and ideally be able to reprduce it to work out why. I am going to put in checks for the Window position, making sure it is within screen limits. For a docked Window it must be within the FS window, so that should be easy enough. I can't really limit it so easily for an undocked Window as that can be moved onto other screens. There's no registry keys associated with FSUIPC. All of your settings are in your INI file and your registration is in your KEY file. There's nothnig else, and either of those files are touched by installing, except for the KEY file if you opt to re-register for any strange reason. BTW are there lots of reports of this phenomenon over in the RC forum? I would have thought there's be more reports if it was really an FSUIPC problem rather than some strange interaction causing this off-screen positioning. Regards Pete

In that case the most likely thing is something else is also controlling the throttle. Check for other assignments, both in FSUIPC and FS. If you recently had a different throttle attachment which was assigned, and now it is disconnected, it could well be related to that. If you aren't sure about FSUIPC assignments show me your FSUIPC INI file -- past its contents in a message here. Pete

I've had a quick look, and P3D2.2 is no different in this facility from P3D 2.1 or 2.0. But 2.x is different from P3D 1.4 in one crucial aspect I hadn't noticed:- the function I call to delete the AI is identical, line for line, except for one important change which I missed -- a second parameter, never actually used in any case, must now not be supplied, otherwise the return corrupts the stack! Odd that no one has experienced this problem in 2.0 or 2.1, but it must often crash those too. The fix is a bit messy, and I'm tied up tonight and maybe tomorrow, but i'll get an update out as soon as i can. It'll be 4.932b. I would still like to see the details I asked for, to confirm what I've found by inspection. Pete

As usual, I need information. If it crashes citing FSUIPC then there is more information attached to it. That information is ALWAYS needed as it gives me the location of the crash and the error type! Also please supply the complete FSUIPC log up to the point of the crash. Again, a 100% requirement. Not supplying such info with the initial report only succeeds in delaying a fix, if there is one 9i.e. if it isn't something I can't get around in P3D And you have no information either? :-( Pete

Why have you posted this under the thread title "FSUIPC and EZDOK"? Folks who do actually know Bodnar boards and might therefore help you won't be looking at this thread with such a title. Please always think before you post. I think you misunderstand. FSUIPC is not a hardware driver. It is an interface into FS for applications, including third party hardware drivers. As far as I know the Bodnar INPUT boards are standard USB boards which emuiate joystick devices, Both FSUIPC and FS support joysticks with up to 8 axes, 2 POVs and 32 buttons. If your board has more than this then the others would need to be dealt with by a separate program, or by a Lua plug-in, programmed using the com HID functions. For outputs, to indicators, lights and displays, you'd certainly need to write the driver yourself, maybe as part of that Lua plug-in. You might get more help over in the myCockpit forums where there are a lot of Bodnar users. See http://www.mycockpit.org/forums/ Pete

It's nothing really to do with either FSUIPC or EZDOK, but simply loss of keyboard focus on FS. You can stop FS pausing on lost focus -- it's one of its Settings options. But to get the focus back on FS you would need to click on its window after you've finished with EZDOK settings, which are in a separate process (hence the loss of focus on the FS focus). Pete

Do you mean there's no response at all to any movement in that lever? If so, then it sounds like a wiring fault. FSUIPC cannot fix hardware which isn't working correctly. Its calibration facilities are just a more precise way of doing what FS should do in any case --it isn't essentially different. And in any case, you always first need to calibrate in Windows (the game controllers app, or properties for the device when selected). As the saying goes, "rubbish in, rubbish out". Better calibrated rubbish is still rubbish I'm afraid. Regards Pete

My PFC and PFCFSX drivers are for the serial port PFC models, no longer made -- all of their new equipment is pure USB. There is a PFCHID driver for the USB consoles and throttle quadrant, but their current yokes and pedals are normal USB joystick devices and need nothing extra. And yes, my FSX stuff all works with specific supported versions of P3D -- they rely on FSUIPC for the interface, so you'd need to see the release data for FSUIPC to check versions supported. Thanks Thomas. Does A2A know their modelling is so far out? Regards Pete

I think you need to deal with the A2A folks about this, then. I am pretty sure that you can change parameters in the Aircraft.CFG file to alter aileron and elevator (and rudder) effectiveness. Perhaps you can experiment and apply your practical knowledge to the problem, then, when you have it right, inform A2A of just how wrong they have it and how to put it right. This isn't my arae of expertise so I'm not the one to advise on aircraft modelling. All I know is that it is wrong to attribute the blame to the controls and there's no way of making them truly more sensitive without penalty, such as limiting the amount of movement you can apply. Obviously if the whole range of the control input were applied only to the central region of surface movement, then , yes, a small amount of yoke movement would yield a bigger amount of surface movement. But that wouldn't make the reaction of the aircraft less "sluggish" -- the actual speed at which the aircraft reacts to the surface changes is to do with the modelling. BTW re-reading your original post, I see this is in error: I just checked, and slope 15 is the least sensitive in the central area, as clearly indicated by the central flattening. If you want a faster response in the centre, then the negative slopes, down to -15 are obviously the ones, as the steep centre slope shows. Of course, in order to maintain the complete range over the yoke movement, you pay for this will less sensitivity at the extremes. I've not tried any A2A aircraft, so I can't compare. I learned to fly in a Cessna 150 and 150A, and also flew a Cherokee for a bit. But because of my Retinitis Pigmentosa (only discovered when having my medical ready to go solo) i never could proceed to a license. That is why, all those years ago, I resorted to simulation. Pete

You should absolutely NEVER need anything out side the normal slope by more than a little flatness, to actually LESSEN sensitivity a little near the centre where otherwise you get a tendency to over correct. Really the linear response (0) is what the aircraft designers have designed for. The properly calibrated yoke will deliver the entire range from full up to full down elevator and full left to full right aileron. The rest is up to the aircraft model. A fast fighter jet or an aerobatic stunt plane will give you a much more sprightly and immediate response than a large airliner or prop. If you aren't happy with the modelling, find a better model, or revise your thoughts as to what feels correct. No yoke will be any different in this regard. It isn't the sensitivity of the yoke, it is the behaviour of the aircraft. Pete

Delete all the old files (go by file date), leave only those listed in the INI - or simply delete them all if you don't really want to resume flying from any. Then tell me EXACTLY in what circumstances you get one left over from the 10 in future. Otherwise there's really nothing I can do. As I said, the facility has been working for everyone else for over 15 years and i'm not about to change anything now without good and proven reason. Pete

The files are all FLT, WX and FSSAVED files? Really? There's no way FSUIPC wouldn't delete those unless you've deleted the INI file on occasion, which would destroy its ability to erase them because the list of the last 10 would be gone. FSUIPC doesn't actuall save any files, BTW, it simply calls the FS facilities to save them, sane as you can via the ; key or the menus. They will all say "saved by FSUIPC" in the comments because that comment is provided to FS. Pete

It isn't FSUIPC keeping those. It is keeping 10, those 10 shown above, all for Friday. Maybe you aren't looking at the FLT/WX files but some files saved by some other add-on aircraft? FSUIPC can manage those for you too, but you have to give it the details of their names and locations, as documented. Pete

The mouse button press was always optional, and in fact added later than mouse look. There are assignable controls to turn on/off/toggle mouse look, as documented. Please see the drop-down assigments list for buttons or keypresses. Pete

Why are your autosave files kept for a long time? I have autosaves made every 3 minutes, with a maximum of 10 saved. After 30 minutes flying the ones older than 30 minutes old are gone! Please explain to me what you are doing which results in such confusion, then maybe I'll understand, because at present it does seem to me extremely strange. The autosave system in FSUIPC is the same as it was in the separate Autosave module for FS204 and actually dates way back to FS98 days, i.e. 16 years, with no one ever being so confused or wanting it changed in the way you are suggesting. Pete

Well, I didn't anticipate people accumulating or saving these for so long. A week seems more than ample when the whole idea of Autosave was to allow a previous position to be reattained after a crash (aircraft or FS or PC crash). And the old ones are deleted as new ones are created, only saving a certain number (10 by default). Surely you aren't using autosaved files as starting positions dating back more than a few minutes, or hours. Why isn't a week enough? If for some strange reason you do want more definitive dating please just look at the date of the file.. Pete

Well, the log is incomplete as you stasrted a New Log, so lopping off the initialisation, and you didn't close FS beforehand as I asked. Nevertheless, as far as it goes it shows everything is correct. The very last part, before you stopped it (rather than close down) shows RC displaying: <MEVEL>38m/25./0 1-Ground on 13522 Main-0. I'm sure that window is actually somewhere off screen -- check your INI file again for the Radar Contact window parameters. Maybe they are also being stored in your flight, the one you are loading to start with? Check that. The ones there may override FSUIPC's settings (the Window is an FS window and it really controls where it goes). The section in the FLT file will be similar to the one in FS's INI file, if it is there. Somehow I think you've had some sort of problem, with Windows being mispositioned (maybe a corrupt FLT file) and the bad parameters have stuck around. Pete

Cryptic numbers? Like what, please? I use no cryptic numbers, only day and time, so you know how long ago your restart will take you. DDD HHMMSS, day of week, hour minute second. How much easier could it be? Pete