Pete Dowson

Sorry, are you saying that before you installed FSUIPC 4.05 you did get an Add-Ons menu? If so, what was in it, please? How many other Simconnect client programs are you running, and what are they? But if FSUIPC4 was "wel loaded" and running okay, there would be an Add-Ons menu and it would have FSUIPC in it. Can you clarify please? You are not alone, but at present the answer still appears to be EITHER some sort of broken Simconnect installation OR a firewall problem. Please do double check that there is no firewall blocking the use of SimConnect client programs. I have also heard that merely re-installing SimConnect from its MSI file, or, indeed, the whole of FSX, doesn't always repair a broken installation. There has been advice given that you first need to find and delete the folder of the original Simconnect installation. Search in your Windows folder for Simconnect.dll. It will be in a folder with a horrible long and complicated name including "WinSxS". Only the DLL will be there. Delete the folder along with the DLL, then try re-installing from the MSI file. I don't know if this works, as I haven't yet heard back from others about this. Regards Pete

Hmmmthat is rather strange. Can you enable IPC read and IPC write Logging (see the Logging options), then close FS, restart so as to run that test again, then Close FS (very important), ZIP up the FSUIPC.Log file and send it to me at petedowson@btconnect.com (or show it here if it is short enough). Regards Pete

Glad you found it. What does it actually do? I guess it hooks into stuff on the Network? I wonder why it affected an outgoing connection (WideClient connects TO WideServer) but not incoming ones, like when you tried the Server on that PC? Regards Pete

Er, I still there's a lot of confusion in what you are talking about. There's no file I know of by the name PFC DDL. There is a DRIVER written by me, called PFC.DLL. In other words, the PFC driver for FS9 IS "PFC.DLL". I don't know any "DDL", and, yes, the PFC.DLL goes into the Modules folder in FS9. There's really nothing new for you to look forward to. The version 2.00 PFC.DLL will not be much different from the 1.999b available in the "Other Downloads" announcement above, except that there will be joint and slightly updated FSX + FS9 version documentation, and some minor improvements in both versions for pmSystems when using the PFC 737NG cockpit. Oh, and the FSX version (4.00) will turn off the Avionics displays when FSX is closed, which currently is a problem. Regards Pete

I have no control over their site. Version 1.0 must have been many years ago, obviously well before the C2 in any case. I assume they just put it up there when I first wrote it and forgot clean about it. The latest "official" version is always on www/schiratti.com/dowson, but I tend to provide updates here too, in the Announcements above. Unless it specifically says its for Beta testing, the ones here will be best, always. At present the only reason the one here isn't "official" is that I've not yet updated the documentation -- so you still need the official ZIP for the Dox. Please, do peruse the announcements above, they do tell you these things. Always the latest here, but with Dox from the Schiratti site. The only time that may not be so is when either (a) there isn't a later one here, or (b) the later one here explicitly says for testing this that or the other and you don't have any of that. I am in the process of tidying some things up both for PFC.DLL and PFCFSX.DLL and then they will both be released as versions 2.00 and 4.00 respectively. That will be on the Schiratti site, but announcements here will say too. ALWAYS install new versions. It's only the DLL itself you change in any case. The INI file contains your settings, you don't need to delete or change that unless you want to start again! I don't know what you mean "has a driver in there"? The PFC.DLL is the FS9-and-before driver for PFC serially connected devices. Simply copy new versions into the Modules folder. You won't wear anything out!!? Regards Pete

I think you misunderstood me there. You need to do "fine tuning" on your calibrations -- a larger null zone is needed to stop the constant jitter seem on all three axes (rudder and both brakes). The central "null zone" for the rudder is determined by the central two numbers in the calibration -- you need to move the pedals slightly one side and the other of centre to set two separate values there, far enough apart so jitter is eliminated. Similarly depress the brakes slightly before setting the brakes off position. Usually it's a good idea to depress them quite a way to avoid accidental application. My adjustment in FSUIPC is merely to avoid sending Events to SimConnect before those Event numbers have been established. It doesn't affect anything except the logging of spurious errors in the Log. I'm testing changes to FSUIPC4 now to try to recover from an erroneous SimConnect disconnection, but whilst it suffers from such weird errors there'll be some problems. I will try to recover exactly where it left off, after 5 seconds or so of non-communication, but data like the whereabouts of all the AI may be wrong for a while after that. Regards Pete

You sent me some good logs illustrating the problem with the disappearing menu (and FSUIPC4 operations thereby stopping). You said: I don't think I need any more logs, thank you. Those illustrate it well enough. In the SimConnect log, which is mostly full of GoFlight stuff initially, then a reasonable mixture of GF and FSUIPC4 traffic (the lines with #62 are GF, #63 FSUIPC4), the thing that killed the FSUIPC4 connection occurs in the 1215th second: 1215.99501 [63] I/O Error! How the hell SimConnect can experience an I/O error when everything is happening in the one machine with no actual I/O involved I've no idea, but it evidently can and it appears it have no recovery built in as it never again talks to FSUIPC4. I am wondering if it is something simple like running out of TCP/IP buffers of somethnig stupid like that. I am really hating the methods Simconnect uses more and more with each passing day! There's not a lot I can do except to detect a number of seconds with no Events arriving and re-initialise the Simconnect link. That would be my 'recovery'. I'll put that into the next Interim FSUIPC4 version, which I'll be posting in the Announcement above within the next day or two. Please try it and let me know. There's also one interesting result I can see in the log which needs a little adjustment from me. You appear to have jittery Rudder pedals/brakes, and FSUIPC4 is sending loads of rudder events to SimConnect. It starts doing this quite early, and in fact BEFORE those events are registered with SimConnect. This is a result of my delayed Simconnect initialisation (to avoid FSX crashes when two clients try to initialise Simconnect together). That results in these errors initially: > 39.32469 [63, 30]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-8192, GroupID=2, Flags=0 < 39.32474 [63] >>>>> EXCEPTION=1, SendID=30, Index=2 <<<<< > 39.32507 [63, 31]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-8356, GroupID=2, Flags=0 < 39.32510 [63] >>>>> EXCEPTION=1, SendID=31, Index=2 <<<<< > 39.32657 [63, 32]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=256, GroupID=2, Flags=0 < 39.32661 [63] >>>>> EXCEPTION=1, SendID=32, Index=2 <<<<< 66387 and 66388 are left and right toe brakes, 65764 is the rudder. If you aren't shuffling you feet on those whilst FS is loading up then it seems they aren't calibrated well with a decent centre "null zone" to avoid jitter. Anyway, I'll tidy up FSUIPC4 so it doesn't send these events on until it knows they've been registered. Thatt'll be in the interim version too. I'll send the details of this "I/O Error" directly to my MS contacts. Perhaps you could make a detailed report, including the Simconnect log (the other logs won't be of interest to them) and send it to tell_fs@microsoft.com too, please. Regards Pete

Are you now using FSUIPC 3.71 on both computers? If not why not? Nevertheless the problem is in MyFSTools, and you need to contact the supplier/author to find out what the above message means. It makes no sense to me -- it presumably means something to the author! If the "2" is the error number returned by FSUIPC_Open, then this means "Cannot link to FSUIPC or WideClient", which is simply a failure to get the SendMessageTimeout through to FS for FSUIPC to see. It probably simply means that Windows is so busy swapping processes or threads between FS and FSPilot that the messages from MyFSTools are timing out. Most programs try many times before giving up. Maybe MyFSTools has no or few retries built in, and FSPilot is very greedy in its dealings with FS. I'm afraid your recourse still lies with the author(s). Regards Pete

Something is bad in the drivers or network hardware on that Client. There a no loops or places in WideClient which can use all that processor time -- it is getting stuck deeper down, inside the drivers somewhere. All WideFS operations are aynchronous, based on reacting to Windows messages sent when data is ready to be read or the line is ready to accept data to be written. One possibility is interrupts clashing. This is usually sorted out well by Windows XP, but it used to be a big problem on Win98 and so on. You don't say what operating system you are using, but that is somethnig to check. If the Network hardware on that Client is on a PCI card then moving the card to a different socket might help. Otherwise all I can suggest is uninstalling the Network hardware and letting Windows find it again so it re-installs the drivers. If you continue to make no headway, you can set "Log=DebugAll" in the Client's INI file, and this will put everything that the Client is doing into the Log (it may get very large), but based on past experience of this sort of problem I suspect it will only indicate that same as above. If you do produce a large log, ZIP it up and send it to me at petedowson@btconnect.com. Regards Pete

I don't know FS Commander, but isn't it some sort of moving map and so on? How do you use that with FS in full screen mode on the same PC? From the little I've heard, I would have thought FS Commander was more suited to running on a networked PC using WideFS? The original FS9 release used to do that, but I think most of the bugs that caused it were fixed in the FS9.1 update. Are you using the original version? Otherwise such crashes tend to be related to video driver problems. Try different drivers, or different settings in the drivers and/or FS9. All on the one PC? I know it is quite a powerful one, but still ... Run-time error 5 sounds like a Visual Basic type of error message -- which program gave that? Surely not FS. Isn't FS Autostart the program which automatically stops a number of "inessential" processes for you before launching FS? Do you think it may be stopping something it really shouldn't in this case? I'd try a process of elimination on that if I were you. Regards Pete

Thanks for the logs. The main problem seems to be another Add-On you have, "bglmanx.dll", which adds a "Addon Manager X" entry to the menu. It seems to clobber SimConnect good and proper. Try renaming that (it looks like it is in your main FSX folder). If everything then works okay then you have another case of the symptoms caused by having more than one SimConnect client. Also, it looks like that bglmanx.dll is keeping SimConnect constantly occupied with very repetitive action, very frequently asking it the very same question. FSUIPC4 is not getting anything from SimConnect at all and in fact is unable to proceed. It looks like it never gets any acknowledgement of its requests, let alone a log of them. Please forward this stuff to Microsoft with your own descriptions of the problems, and the AVG stuff. send to tell_fs@microsoft.com, and be sure to include the word "SimConnect" in the title. Don't expect a reply. Meanwhile, please also contact whoever supplied "bglmanx.dll" (which I've not heard of at all) and show them the larger SimConnect log, because it certainly looks pretty bad. The only other advice I would give at present it to completely uninstall AVG, for now at least, to see if that alleviates the problem. even with these things apparently disabled, their hooks are still there, and this looks to be a problem with SimConnect at present. Regards Pete

Hi Andrew, Thank you for the logs. Unfortunately these are both contination logs, so they don't show me a lot of the information which may have been useful, like the aircraft concerned. It is writting the elevator value okay. It looks like it expects the read-back to be the same as what is written, which it isn't in FSX. I'm not sure WHY it isn't, though. However I'm equally not sure why that program treats it as some sort of error -- you'd need to take that up with them. What aircraft are you using for this Fly-by-Wire? Not the FSX A321 I hope? Because if you are that probably explains it -- for the first time MSFS have implemented Fly-by-Wire. You can't have your inputs passing through two FBW processes. You'd need to turn off one of them. You may be able to turn off FSX's FBW. If not in the cockpit, in the Aircraft.cFG file. Regards Pete

and did you ever read the "User Guide" at all? Right on the first page it says: Sorry that it is actually called "FSUIPC4 for Advanced Users", but I think is close enough to be recognisable!? It is very saddening. One day perhaps folks will actually read what I write, or even have a look to see, do you think? :-( Regards Pete

Yes, you must have done it wrong, somehow, as I have just tried it and it works fine --- as long as the ATC window isn't open. Do they? They don't here, at least not when the ATC window is open! Anyway, I've tried all sorts of things. Amazingly MANY of the key functions change when the ATC window is open. It seems to be capturing many of them and passing them off using its own equivalence table. FSUIPC is unable to get above this as the ATC window is receiving the keys first. This is really quite a big bug and you should certainly be reporting it as such! Sorry I can't find any way to help -- the only thing you could for now do is get a mouse or cheap joystick. Regards Pete

Seems as though they meessed things up then. I have a record or an "MyFsTools.dll" being issued with an access key on 2nd April 2005. That will apply to all version 3.xxx of FSUIPC -- except 3.71 for which no access keys are required in any case. I fail to understand why you insist on keeping to FSUIPC 3.65 on the PC on which you have this problem. If you don't want to update it, you don't get support from me in any case, and you need to talk to MyFsTools folks. Pete

Erplease hold on a moment then. Are you saying you ARE using multiplayer, and the problems occur after you've enabled multiplayer? If you are saying this, then, as I said, this is a known SimConnect bug, reproduced by Microsoft, and there is a work-around implemented in FSUIPC4. Download version 4.05, the current version. If you are NOT actually saying that you are using multiplayer when the problem occurs, or not before that in the same session at all, then, yes, please go ahead and get some logs. The same applies of course if the work-around in 4.05 doesn't fix it. Regards Pete

Not heard of "MyFSTools". Sounds interesting. Is there any reason you didn't update to 3.71? And what does that mean? Do you have any "MyFSTools" documentation to explain it? Have you asked them? I've no idea, since I've never heard of it. Sorry. If it doesn't work and it needs FSUIPC and you haven't registered it as a user, then that is probably the reason, but you need to ask the suppliers of MyFSTools. Pete

Sorry, I've never heard of "FS-C". What is it, please? I've no idea what it means by that, nor how it is trying to operate the elevator. I need more information, please. Like what IS FS-C, and some FSUIPC4 logs. Really it would be best if the program's authors could work out what they think is wrong, and if they think it is an FSUIPC4 problem, for them to discuss it with me so that we can fix it. Really it is very difficult, if not impossible, for me to diagnose programs interfacing to other folks' products. So, with that in mind please contact them and ask them to look into it and contact me if necessary. Meanwhile, please first ensure you are using the current version of FSUIPC4 (4.05), enable IPC read, IPC write, and Axis logging in the Logging options page, then run your test (keep it short -- only just long enough to see this error message), and then close FSX (very important to close it), ZIP up the FSUIPC4.LOG and send it to me at petedowson@btconnect.com. I'll then take a look to see if it is anything obvious. Regards Pete

It certainly sounds like Simconnect has simply stopped responding. I've had one other case only of this so far, and I was trying to get more information so I could put together a complete report for Microsoft when he decided to do a complete uninstall and re-instal of FSX -- so maybe that fixed it, or maybe he'll come back. I don't know. Are you by any chance using any type of multiplayer facility in FSX? If so, then that is one already known reason for SimConnect stopping -- I've implemented a work around in FSUIPC (you would need to install the current version, 4.05). Otherwise, maybe you could please go to the trouble of getting the needed information? If so, do this: We need a SimConnect log so I can see what is happening, and then you and I can both report it to Microsoft (you via tell_fs@microsoft.com, me direct via my contacts there). And, you never know, maybe I can figure out a work-around in FSUIPC4. To do this create a file containing these lines: [simConnect] level=Verbose console=No file=C:\SimConnect%01u.Log file_max_index=9 The 'file' line there can place the logs wherever you like -- for simplicity I've just suggested putting them in the root of your C: drive, but adjust it to wherever you want them to go. Save this file as Simconnect.ini in your "My Documents\flight simulator X files" folder. Then, keeping things a short as possible, reproduce the problem. Close FSX, Zip up both the Simconnect log and the FSUIPC4.LOG and send them to me at petedowson@btconnect.com. WE'll take it from there. If it does look like I can implement a work around, you'll be one of the first to get a test copy! Thanks & Regards Pete

Just delete the FSUIPC.KEY file from the Modules folder and re-register. Leave the FSUIPC.INI file alone, that contains your settings. Pete

Oh, thank goodness for that! There's must have been a corrupted DLL in there someplace. Thanks for letting me know! Regards Pete

Ah, someone still using the old original program loading facilities in WideServer, eh? Those actually date from before FSUIPC. Although they were left in the separate version WideServer.DLL for compatibility, the facilities were really replaced long ago by the [Programs] section facility in FSUIPC itself. Now that I've re-written the code as one DLL it seemed pointless having two similar facilities in different sections. The FSUIPC-based ones offer the same sort of facilities, or probably more, but use a different format (for instance, there's no separate Close parameter line, you can specify that action on the loading line). Ful details are in the Advanced User's guide for FSUIPC4 (and FSUIPC) under the heading: Programs: facilities to load and run additional programs Regards Pete

No, there isn't. Why does it shut down? The registration page is an ordinary Windows dialogue like any other. It sounds like you have something suspicious in your PC. Try shuttong everything else down -- one or other process is interfering. Maybe it's a Kensington Mouse driver -- folks have had lots of problems with that. There other things, like window Blinds that interfere with ordinary processes. Pete

How do you view the documentation? Nearly every program in which you can view my documents there's a search facility. Often you press CTRL+F and say what you want to search for. Surely you've used an editor before and searched for words? Pete

Sounds like you have something set for calibration in FSUIPC4 which you shouldn't have. On A/P I should think the only thing which might possibly do what you say is aileron trim or more likely the rudder or rudder trim centering -- but you should then notice you need to compensate in normal manual flying as well. Are you using rudder pedals? Check the calibration. If the rudder is off-centre to one side the A/P will have to compensate with opposite aileron -- the A/P doesn't control the rudder, you do. If you have been messing in the options and don't know what you've done, please simply delete your FSUIPC4.INI file and let it build a new one. FSUIPC4 itself doesn't alter or touch any part of FSX. Anything which occurs is always through some user or application activated option or assignment. FSUIPC4 is merely the interface to enable these things. Regards Pete