Pete Dowson

sounds like you have some severe cross-interference. Well, there's really no realtion between the separate inputs to FS as far as FSUIPC is concerned. Try to record this in the Log with FSUIPC axis logging enabled. Take care though, the log can get VERY large. Only enable it for the short period you get the anomaly. Regards Pete

Yes. I originally faced this problem programming displays via EPIC (the original Flight-Link TR-1 and KR-1 avionics stacks, in fact) way back in FS98 -- before FSUIPC in fact. The only sensible way to do it is as follows: 1. When your dials are adjusted, update your displays locally with the new values as well as sending the new values to FS. 2. If the values are changing fast, don't try to send them all. It is probably best for the routine you use to send to FS to "sample" the current updated value every 250 or 500 mSecs and send the new values at that time. 3. Whilst the values are being updated locally, IGNORE changes being read from FS. 4. After a time (say 1 second or so -- experiment) from the last local change, THEN start reading FS values again for display. If you don't do it something like this you will find it very difficult to do adjustments accurately as the FS read-out will always run behind. You watch an MCP being adjusted in a real aircraft and you will see how fast you can "spin those numbers". Try to implement it locally like that. Just let everything catch up in FS when the value stabilises. Regards Pete

It's read-only becase I can't find a way to write it directly. You can easily wind it up and down using the appropriate controls, as you would in a real Cessna using the knob. I don't know why you'd need to specificaly set it directly? I think the Controls are called "ATTITUDE_BARS_POSITION_DOWN" and "... UP". You can either program them on a button or send them to FSUIPC via offset 3110. Regards, Pete

There aren't any. What would they say if thee were? There's not a particular limit on the number of simultaneous views in FS. If you only want to change the default window view, use an FS control. If you want to find out whether any open (and visible?) window contains a particular view, I think you need to be running on the same PC as FS, then try to analyse the assorted FS windows by ennumerating them. It certainly isn't easy. Regards, Pete

Don't forget that much of PM communication is via "NetDir". I assume you've run the PM checking program -- does that give everything a clean bill of health? It did? So, what has changed. Have you installed anything, removed anything? If you've changed nothing, and you are sure you have not acquired any viruses or worms, then the problem may well be hardware -- software doesn't "develop" faults, they are either there or they are not. However, the possiblilty of file corruption, somehow, does arise -- reinstallation is then usually needed (more below ...) Again this reference to "blindness". It sounds like the Netdir access for PM, not WideFs. Run the check program again. Your best bet for help with this is Katy Pluta of PM support. She helps me when I have Network Problems. Are you sure the when this happens the Glass Cockpit is actually really fully closed? Just because the window disappears doesn't mean it has gone -- check with the task manager (Ctrl-Alt-Del), look in the Process list. All the cases I know of with WideClient locking have actually been due to the application locking. If the PM process has gone completely, then the hang will be in the Windows networking routines or in the network driver. Try re-installing the network card -- in the Windows hardware manager uninstall it and reinstall it. If necessary, and it is a plug in (PCI) network card, actually deinstall it completely and re-install it. BTW, you aren't using "pmGetWeather" are you? I find this occasionally locks -- it takes 99% of the CPU when it does so and everything else on that PC grinds to a halt. Anyway, back to corruption: earlier this week something somehow corrupted something in my system. Upon booting up I was getting six or more consecutive crashes reported in "SVCHost", Windows Explorer took two minutes or so to open "My Computer" (every time!), and the whole PC reset itself now and then. I was going crazy. Katy suspected a worm or virus, but nothing was detected. Eventually, via the Event Log I found that the initial crashes were when Windows tried to start a service -- something about Image Acquisition. I found the service and disabled it -- and everything has been okay since! I suppose I still have a corrupt part of Windows, but, since it is a part I don't use, it now doesn't affect me. I expect that if I wanted to use this disabled service I would need to re-install Windows completely. Maybe this is what you will need to do? Regards Pete

The acknowledgement is automated I think. The registration requires humans. SimMarket are pretty quick -- almost always within 24 hours, as it says. Some things I register only guarantee 2-3 days ("working days" at that). What do you think will be "going on"? Has it been more than 24 hours? If so, raise a problem ticket. Yes of course. Didn't you read the details on the site? Perhpas when you ordered them folks were asleep in Germany (where SimMarket is based)? 24 hours is a pretty good turn-round, and it even applies most weekends, which is better than many. Regards, Pete

add WideServer.dll The wideFS bit there is just WideClient.exe. You can arrange for WideClient to load the other programs for you when FS is ready for them on PC 1. I do this, then put a shortcut ot Wideclient in the StartUp folder so it loads when the client PC boots up. It doesn't do much and doesn't take up much space whilst waiting for FS. Wideclient can also close the programs when FS is closed. It's the easiest to configure and it is installed by default, so, yes, it is supported by WideFS. For a long time I only supported IPX/SPX which is slimmer and faster (not needing to work on a world-wide Internet). I had to give in as Microsoft seemed to tail off their support. It does still work though -- in fact since SP1 Windows XP has been pretty good on IPX/SPX -- problematic before then though. Regards, Pete

You'd probably be better off putting ActiveSky on the second PC too. It wouyld releive some of the load on the PC you really want to keep clear for FS's needs. ActiveSky isn't a processor hog, but it may cause some jitters in FS when it is downloading weather every now and then. You only need WideFS. Check the documentation. There's not a lot to do. Come back if you get into trouble, but most folks just install it, tell the client what the Server name is, and that's it. Well, naturally I'd love for you to buy FSUIPC, but it isn't necessary -- you will have to buy WideFS though. Regards, Pete

Why? Why not use the value you just sent? Don't you believe it? Both the write and the read are being done in the same Process. That will only work (on the same PC as FS) where all FSUIPC has to do is copy the value into some memory, because obviously the memory will be just written in the same call. It will not work on a client PC because the process is being done by WideClient. It will send your Write over to FS, but it will give you the value for the read that it has in memory. Until WideServer sends it the update any reads on the Client will return the previous value. It will be two network cycles before you get an updates -- possibly 50 mSecs, more likely anything from 100 to 300 mSecs. More on a very busy system. If, for this particular value, FSUIPC cannot simply write to a memory location, but has to send the value to somewhere in FS for processing, then you cannot expect the value to be read back correctly in the same process call to FSUIPC. It cannot be done. You should write your program with cycles either approximating the FS frame rate, or regularly, say one FSUIPC_Process call every one or two or more "timer ticks" (each 55 mSecs). Requests sent on one cycle may be seen to be effective on a later one -- hopefully the very next one for something simple like this. For some weather and AI traffic reading requests there might be a longer delay. And of course, over a Network, through wideFS, you mst allow for much longer as a rule. Regards, Pete

The easiest way to see any offset is to use FSUIPC's Monitor -- see the right-hand side of the Logging options page. Add 02D4 as type U16 and check the Hex option, then check the "AdvDisplay" option below to see it in real time on screen. BTW, I've just tried it on the PMDG 737-600 cockpit and it is all working fine. Regards, Pete

The second ADF is only provided in FS2004, and then only if it is implemented in the Aircraft you are using. Check your Aircraft.CFG file and see if it has one or two ADFs. Pete

Yes, and the big advantage then is that you get ATC voiced through separate speakers (from the sound card on the Client PC), and can have it through a headset if you like. Regards, Pete

Check the sensitivities in FS (Options-Controls-Sensitivities). For some strange reason FS2004 seems to sometimes automatically initialise axes to ZERO sensitivity, giving exactly those symptoms. Whilst you are there, make ALL of the sensitivities maximum and all the null zones minimum if your are using FSUIPC calibration for everything. This will give you the best resolution and flexibility. As you are using the CH quadrant you will find Bob Church's notes helpful -- http://www.stickworks.com (Look for his CMNOTE02.ZIP), Regards, Pete

Have you tested your program direct to FSUIPC at all? What does the WideClient Log show? What versions of WideFS and FSUIPC are you using? It means that after a number of retries your program could not get an answer from WideClient or FSUIPC, whichever it is running on. It uses "SendMessageTimeout" and wants a response within a timeout period. when FS is really busy that timeout may occur, so the library code I provide does a number of retries. Provided FS is available within about 10-20 seconds it should work. Otherwise you get that error. However, in the case of WideClient, even if FS is busy or even if it isdn't actually running, the response to the SendMessageTimeout from WideClient.exe is nearly always immediate. If you are getting such failures on a client then it sounds like WideClient isn't running, or is hung, or has crashed. Regards, Pete

Not one number, two numbers. You want a structure or an array with two numbers. In C something like: int controls[2]; DWORD dwResult; controls[0] = 66507; controls[1] = 70; FSUIPC_Write(0x3310, 8, (BYTE *) controls, &dwResult); etc. You must be able to do that in any language, after adapting it to suit of course. Regards, Pete

I'm not clear what you mean: "did not appear" where? In the GFdisplay INI file? If you have your GF MCP installed on your FS PC, then it will be controlled by the GF MCP DLL installed in your FS Modules folder. If you want FSUIPC+GFdisplay to handle it you will have to remove that DLL. Pete

The Goflight MCP is not ideally suited to PM's MCP -- there aren't enough buttons to start with. Does your PM demo include the MCP or are you just using the PFD/ND/EICAS part? If the latter then the GoFlight MCP will be okay controlling the default FS autopilot. If you get seriously involved with PM and want to use it all with GoFlight equipment then there are two possibilities. One is to download my GFdisplay package (which is a free add-on for a "payware" FSUIPC). It already has example files ready to adapt to GoFlight hardware and PM. The other is to ask GoFlight if they have got around to supporting PM yet. I think it was mooted once. As far as the PM Demo possibilities are concerned you will have to talk to PM support. I'm not sure what sort of restrictions and differences there might be. Regards, Pete

I don't know PFD logging. The PM support team would have to advise about what sort of Read Errors they are -- the sound like file access, which is not via WideFs. I also did not know the PFD actively "looked" for a CDU. Probably it looks for the NetDir in order to see if there are V-speeds and a route to display? Well, there's certainly no trouble with WideFS for the first two hours or so. I'm afraid I cannot say what happened to the program itself. Regards, Pete

WideFS is merely a Network extension of the FSUIPC interface, so almost any external program which interfaces to FS via FSUIPC will run on a client PC. There are a few exceptions, where programs rely on direct local access to other things in FS's folders, but very few have such needs and some that do have ways around it provided or documented. If you look to the list on the right-hand side of the http://www.schiratti.com/dowson page then many of those will work on a client. Not the aircraft, of course, nor any programs which are not actually externals but run inside FS, like FSNavigator and gauges. The external programs I use across WideFS are: ActiveSky or FSMeteo FS FlightKeeper (highly recommended, includes moving map)) TrafficBoard FS Real Time AI Smooth Radar Contact (better ATC than FS's) ShowText (from inside my AdvDisplay package) SA_WXR (weather radar) and also the entire Project Magenta suite -- the CDU, PFD/ND/EICAS, MCP, plus pmSystems and pmSounds. For mapping programs which aren't written specifically for FS, like Memory Map Navigator, Jeppesen FliteMap, even AutoRoute and so on, you need a serial link connectd, and then you use GPSout instead. Such programs naturally have no FSUIPC interface and in general the only way to input positional information is via their GPS input option. I'm afraid I don't know Rana Inside Moving Map so I couldn't say which solution fits. Regards, Pete

I did start to describe some of these way back in my first Controls List -- the one for FS2000, still available on http://www.schiratti.com/dowson. Those that you need and which were in FS2000 may be described for you there. Unfortunately I've never had time to develop that at all. There is now a huge number of controls, but not all of them do anything (they are either old ones which Microsoft forgot to remove or new ones they didn't get time to implement) and some don't exactly do what they seem to say they do. The only way, really, to determine exactly what they do is to test each one and see. Those that are assignable in FS's own assignments should be reasonably well documented in FS's own help system. The descriptions you see in the FS assignments dialogues are not the same as the Names, of course, but if you look in your FS9.CFG you will find KEYBOARD and JOYSTICK sections which use the control names, exactly as I list, so you should be able to relate them well enough. In the KEYBOARD sections the keypress encoding is the same as that used by FSUIPC -- you will find a table for that in FSUIPC's Advanced User's documentation. Controls are only inputs. They relate to keys, buttons, switches and joystick axes connectable to FS. They are never outputs from FS. Officially FS only "outputs" via its Gauges interface to the gauges that make up its panels (though there is also a "netpipes" interface but by all accounts it isn't good). The gauges interface is documented in Microsoft's own SDK for panel making -- in fact this is where you may also find more dcoumentation for some of the Controls. Look through the main gauges header file (gauges.h) for example. FSUIPC provides an interface for external programs to read the same sort of values that gauges can, and it also provides a lot more. FSUIPC is the general way to add on displays, but you have to be able to write your own interface program if you do this directly. There are a number of specific implementations for which display support is already provided. My own EPICINFO does this for EPIC-connected displays, as does FSCommunicator. There's software from both GoFlight and my own GFdisplay for GoFlight displays. And there are developments like FSBus and others for interfacing to other specific hardware types. In other words, if you design all your own hardware you will naturally need to look at programming your own driver for it and interface that to FSUIPC. But if you are using some already designed hardware interface you should find that the designers/makers have already done that part for you. Check the cockpit builders forums. Regards, Pete

I'm afraid this is not a WideFS "connection issue". The links those programs make to NetDir and the FlightSim folder are direct, via normal Windows file sharing, not via WideFS. WideFS only provides the link to FSUIPC, which appears to be working fine. I don't think any PM glass cockpit goes looking for a CDU or MCP. The links are the other way I think. But that's all PM stuff which you'd need to discuss with them. A "few minutes"? The log shows the Airport Chart viewer starting up at time 296065 (296 seconfs after WideClient was started on that PC), and there are no problems until time 7440809, which actually looks about when FS or something was closed judging by all the other logs. 7440809 - 296065 = 119 minutes, or nearly two hours or incidentless connection! Then there was a loss of connection for about 38 seconds (maybe you were reloading something in FS or using its menus?) after which it carried on for another 2605 seconds (43 minutes) with no troubles. The errors after that seem to be the same as on all the others. Furthermore, as the figures at the bottom show, it enjoyed a reasonable connection, probably commensurate with its demands: 8140365 Reception maximum: 25 frames/sec, 1075 bytes/sec 8140365 Reception average whilst connected: 10 frames/sec, 408 bytes/sec 8140365 Transmission maximum: 8 frames/sec, 595 bytes/sec It made 3,210 requests over the two hours 42 minutes. The one for JENNY seems to be for a completely different session -- the time doesn't match at all. There are no errors except at the end, and the program hasn't been closed when you zipped the file. REMUS started a little after GAIA and its "troubles" also occurred about 2 hours later, with pmSounds and pmRJ running without incident for that time. The sequence after two hours is the same as for GAIA, so it is probably activity on the Server interfering with the connection. Exactly the same applies to NICO, with pmRJ again running okay for two hours or so. Looking at the Server log (which, by the way, is also not terminated -- you do need to close FS so that the performance is logged), there are a couple of isolated NASTY errors: 76594 **** ERROR! Sumcheck or length fails on received socket 2876 block, len=1000 (time=0) 850015 **** ERROR! Sumcheck or length fails on received socket 2864 block, len=43 (time=0) The first was on a block from GAIA, the second from NICO. Neither would do any lasting harm, but these sort of errors should NEVER occur. They mean data is occasionally getting corrupted. I've no idea how that can happen -- it'll be more likely hardware than software -- cables, hubs/switches/NICs. Possibly sharing an IRQ would do it too. However, neither of these would have done anything noticeable. They are one-off errors and very very infrequent at that. Apart from that, the disconnections and reconnections happen at the same time as they are reported in the Clients -- i.e. after the two hours of good running. They could be due to almost anything in FS other than flight or slew modes (lengthy times in menus, delays or long stutters loading scenery, aircraft, etc. These are quite normal and recovery is quick afterwards. The whole period of such errors is a bit long though). If you were not doing things in FS when this period of problems started after the 2 hours of good flight, then I'm wondering if it is due to a memory leak problem. There are quite a few of these in FS, some fixed by the FS9.1 update. There are add-on sceneries (autogen I think) which can do it, especially if installed incorrectly it seems. If you are using FS with many add-ons it might be a good idea to search the various forums for help with this sort of thing. Regards, Pete

See the list of supported programs, above, and get the program from http://www.schiratti.com/dowson, where you will also find my other FS related programs, as well as the FSUIPC SDK. Regards, Pete

Ah! Thank you Doug. I didn't know about those. Pete

I don't know of any way to do that by ID, but you can send the FS controls for Panel 1-Panel 9 selection via offset 3110. You'll need the control numbers, which you will find in the "List of FSxxxx controls" documents availavle -- the FS2004 one is included in the FSUIPC package these days. I don't think there are any 'offsets' for that. Sorry. That's an area of FS I know very little about. I suppose if you are running on the same PC as FS you could ennumerate FS's Windows and try to identify them by window title, though that's user-definable I think. All the ClassNames are "FS98CHILD" so you can't identify them that way, and if they are undocked you have even more problems to find them. Regards, Pete

You got the PMRJDemo from PM -- PM = Project Magenta. The PMRJDemo is presumably a Demo of the RJ gauge set from PM? http://www.projectmagenta.com. If not, then I have no idea what PMRJDEMO is -- you'll need to work out where you got it from. Regards, Pete