Pete Dowson

Many add-on aircraft for FS come with EFIS control panels. These are the small panels with rotary switches for Nav Display mode and range, rotary encoders for DH and altimeter pressure setting, and buttons for an assortment of options and displays. You'd need to search for those aircraft which contain the type of EFIS you are interested in. To start with, Boeing or Airbus? Or some other manufacturer. For hardware implementations, PFC (http://www.flypfc.com) make an MCP with optional EFIS attachments, 737 style. Take a look there. I would also suggest asking around in the cockpit builders forum and over in the Project Magenta webgroup/forum (you would need to join). http://www.promagenta.com. Have you tried Google? There are some excellent sources of information on the real aircraft. I'm not sure what model interests you most, but for 737 try http://www.b737.org.uk/. Regards, Pete

Yes, I do know what they do. Sorry if I gave the impression I didn't. I just said I'd never had one -- all my rotary "encoders" (I use the term "switch" generically to emcompass all these things, sorry for my inaccuracy) produce pulses on separate lines according to the direction. I understand the two-phase ones are easier to obtain, and possibly cheaper. There are other threads here which discuss both and give some links to suppliers of the 'simpler' type I have. The example in the documentation was programmed and tested and provided by a user who did have the two-phase types. I'm sure the logic is sound there. Regards, Pete

No. As I said in my first reply, FSUIPC interfaces the old FS98 interface to FS2000, FS2002, and FS2004. You must have missed a paragraph? The whole point of FSUIPC, when it was first released for FS2000, was to allow all the nice FS98 programs to be used with FS2000. Similarly FS98 and FS2000 on FS2002, then FS98, FS2000 and FS2002 programs on FS2004. So FSUIPC still supports all the FS98 interface as well as the FS2000, FS2002 and FS2004 ones. It does the data matching internally. It is all smoke and mirrors and you don't need to worry about it. The weather was markedly improved with FS2000, but roughly the same in FS2002, so the "Advanced Weather Interface", developed in FSUIPC for FS2000, applies to both of those. Both of those old interfaces only dealt with Global weather setting. In FS2004 this proved to be insufficient, as weather is localised with time. So in FS2004 only the "New Weather Interface" is provided. That is actually rather more transparent, a sort of Window into FS's WEATHER.DLL, only made in a format suiting the FSUIPC interface design. There are two weather programs provided in the FSUIPC.ZIP package -- WeatherSet which uses the AWI and WeatherSet2 (for FS2004 only) which uses the NWI. Check the details provided in the SDK. Regards, Pete

How complicated! It sounds like that Hagstrom controller is absolutely not suited to such rotaries. To be honest I am not sure it is even possible. But I have no experience whatsoever of 2-phase rotary switches -- all the ones I've ever had produce chains of pulses on one line one way and on another line the other way. I do think, though, that your button programming looks completely wrong. I am comparing it with the example provided to me for publication in the Advanced User's documentation for FSUIPC. Please look at the example. Search for "two-phase" in the document and you should find it straight-away. There's a good half-page or more spent on explaining it. Regards, Pete

FSUIPC has not yet got beyond version 3.5xx, and WideFS has been at version 6.5xx for a long time, so I don't know where you are seeing "4 something". You can easily check version numbers -- right click on the program or module and select Properties - Version. I see your name associated with a registration for FSUIPC (29th Oct 2004), but not WideFS. When did you purchase that? You'll have troubles if you try to use a fake registration. What, exactly, says "access denied"? Please be more specific. If you want help please try again, get the error, then close down FS and show me the FSUIPC.Log file, which you will find in the FS Modules folder. Regards, Pete

Because it was set by something writing to the FS98 weather interface -- please review my earlier reply. Regards, Pete

I have had no one else report that the broadcast connection facility, which was added in version 6.50 last August, does not work on WinXP networks. Now I also find that it works well with Win2K -- it is only WinMe and earlier systems which apparently don't support the needed facilities. This of course doesn't mean no one else has such prblems. after all, I assume you have previously been using 6.51 and even 6.50, but didn't think to either try the facility or report the problem, nnot until we discover it when I propose an interesting use for it (that of easier change of protocol via server INI change only). I'll send another WideClient tomorrow (Thursday). Regards, Pete

Write the string to offset 3380 using FSUIPC_WriteS, and a code (for delay, scroll, whatever) to 32FA using FSUIPC_Write. Check the Programmer's Guide in the SDK for these offsets. Pete

Okay, thanks. It is exactly as I feared I'm afraid. The Server is okay, it is quite happy and certain it is sending mailslot messages with no errors: 44031 Broadcasting service every 1000 mSecs 44031 Preferred protocol = TCP 44531 Mailslot message sent okay ...) And the Client is also certain that is it listening and wating for them with no errors reported at all, yet nothing being received either: 3675 Mailslot being created 3675 Mailslot "\\.\MAILSLOT\MS_WideServer" created ok 4676 Readfile for mail returned 0 (read 0 bytes, needed 28 or 26), Error=121 Error 121 just means the read timed out (set at 1 second -- as can be seen here, the difference between 3675 mSecs and 4676 mSecs). So, what are the possibilities? First, perhaps they are being blocked somewhere. How that can be I don't know. Sorry. Second, perhaps there is some service or other part of Windows which isn't running for some reason. Again I have no idea what or why. Third, perhaps some other service, some add-on perhaps, is hooking this system and losing or blocking the messages -- though is is really the same as reason 1. Fourth, and this is more obtuse but possibly experimentally provable, perhaps the message is only available to be read for a short time and by some coinicidence it is never there in the 1 second out of every 3 that WideClient is waiting for it. I don't wait all the time because I found, even if I do this in a separate thread, it makes the WideClient window rather unresponsive to mouse operations such as Window movement/sizing or closure. What I could do is supply a WideClient with both the interval (3 seconds at present) and the timeout (1 second at present) configurable. Then you could experiment, from the daft (timeout of 10 seconds, every 11, or similar) to the fast (timeout of 100 mSecs every 150 mSecs) -- assuming I set the values in mSecs. What do you think? Is it worth a try? Let me know. I sohuld be able to fit that in tomorrow some time. Regards, Pete

Ah .. the ancient and venerable FS98 interface. I didn't know anyone still programmed for that these days. Yes, in FS98 you could only enable or disable gusts. In order to interface the old limited FS98 weather system to FS2000, FS2002 and FS2004 I do some manipulations on the current windspeed to calculate a reasonable gust increment, which should work out at a random value somewhere between 5 knots and 5 knots more than 120% of the wind speed. This served well in comparison with what FS98 used to do with the "on/off" option then available. This means that to get as high as your 99 knots the base wind speed must have been of the order of 40 odd knots. Are you writing the speed first? If not the gust value may be calculate based on something else. Also, I hope you are not doing a Process call for every individual read/write. You should accumulate them all for one cycel and send one Process. If you cannot figure it out, enable the Weather and IPC Write logging and show me the Log. Regards, Pete

Thank you. Pete

Gusts are controlled by a value specifying the maximum difference in Wind Speed. Where do you get the idea that they are either on or off? It sounds like you have misunderstood something somewhere. Which of the three weather interfaces are you using? Where are you writing the "1 or 0"? Regards, Pete

It would be a good idea, please, to check the FSUIPC solution too if you can. I probably won't be taking the extra code out. Regards Pete

I attach FSUIPC 3.559. Please try this. I could not reproduce your problem any way I tried, including the circumstances you listed. All I have tried now is forcing a message through to WideServer using a separate thread running continuously in FSUIPC but only sending the message when the value in 3365 is non-zero. I really can't think of anything else to try. Please let me know. Regards, Pete FSUIPC3559.zip

You can Zip them all together and attach them to an email to petedowson@btconnect.com, please. Regards, Pete

Okay, more things to try now -- not that it'll fix anything, but hopefully the Logs will show why it is wrong on those PCs on which it doesn't work. Please install the versions of WideServer and WideClient attached (both "6.598a"). Edit the INI files for both, changing the Log= parameter in the User section to "Log=Mailslot". Run it in each of the circumstances you already tried, carefully saving both Server and Client logs each time and labelling them (renaming them) appropriately. The logs should tell us what is going on, IF it is detectable by the programs. If the mailslots are merely being blocked or discarded somewhere deeper down then I'm afraid I don't know any way to find out why. Thanks, Pete WideFS6598a.zip

No, that's clear now -- though previously I had assumed you only meant menu movements not entry into dialogues, because here I cannot, on any PC (I have 12 on my Network) reproduce the case where it is not non-zero when in any of the dialogues -- though maybe I didn't test all of them. I will certainly re-test the ones you mention. I was getting zero in 3365 when pressing ALT and moving around in the menus, without selecting anything. But the change I made to FSUIPC did fix it 100% here, so your results are indeed a puzzle. But of course I am using the latest interim release of WideFS (WideServer 6.596 and WideClient 6.598, available above). Perhaps you could just re-test with those, in case there's some quirk or timing difference, and let me know, before I start trying to find other ways of fixing something which isn't broken here? Regards, Pete

Erthe change I made only operates on menus, not on dialogues. In all my testing the other bit in 3365 is always set when I'm in a dialogue. Before I try to do anything else (not that I can think of anything else at present) can you please clarify EXACTLY now what you mean by "menu" in this context. Evidently you meant something different to what I thought originally. :-( Hmmm. Odd. That most certainly doesn't happen here -- if goes non-zero directly. What Windows system are you using? Maybe there are differences in the messages it sends when ALT is pressed. I'm not sure I can help any further, but I'll have one further look if you can be very explicit. Since it now works 100% here on all my Winodws XP SP2 systems I will have difficulty figuring a solution. It would be guesswork I think. Regards, Pete

I am sorry, but I really have no ideas about this. Later today I will add some optional debug messages to the code and send versions to you to try. If we look at the logs it may tell us what my Mailslot windows API calls are returning which prevents it working in each circumstance. Don't go crazy yeteven if we never get it working, you can still configure WideFS without it, it is just one feature less. Later then ... Pete

That's quite an astounding difference, much more than I could have reasonably expected. I am very pleased it all works so well for you. I've not actually done any numerical comparisons like you, only watching everything subjectively. Thanks! Pete

Okay. That does seem to confirm that the system assumes UDP blocks are "dispensable", that if there's a clash the UDP block is lost and not re-sent. With TCP and SPX, if there's a timing clash anywhere I think the block is re-sent. The sender "cares" about the block getting there, but not with UDP. That is a good solution then, Do you notice if things are smoother, or about the same as with TCP or SPX? I think my PM gauges look smoother (so the block timing is better, less latency from the replies confirming receipt presumably), but it is very subjective. As with FS's own "smoothness", the frame rates are no measure for this -- WideServer regulates the frame rates to match FS in any case. The only time they will appear to exceed the FS rates is when the data from one frame needs to be split into more than one block to keep within protocol and buffer limits. Regards, Pete

Yes, please. Regards, Pete

Thanks for posting this! I am sure such information will be useful to others. Regards, Peter

You are using Borland? I'm afraid I can't help with that, I only ever used MS for FS development. Didn't you find a Borland ZIP with stuff you can use in the SDK? A kind previous Borland programmer submitted some helpful material -- check the UIPC_SDK_BCB5 zip file. Pete

All my code, including examples, are actually C, not C++. Maybe you need to tell your linker that? I'm really as confused as the next person by the plethora of rather arcane settings you need to check in Microsoft language systems, especially linkers. Sorry. Perhaps you need to take the source code of the Library (also supplied) and use that? Strange that you've not sussed any of the function prototypes out. There are many Windows functions which, like the FSUIPC_ ones, return a success/fail indication as the result, but store the data returned in the locatin you point to. After all, the data could be anything from a single byte to an area of offsets many kilobytes long -- it isn't suitable for returning as any "typed" function result. If you look carefully at the prototypes for the Read and Write functions you will see that you have to supply not only the offset (start) value, but also the length in bytes (which could be large), and, most important, a pointer to the data to be Written or to the area where you want the Read to deposit the data. That might be a byte, a word, a DWORD, a double, an array, or a structure, or even an array of structures (as for the TCAS data, for example). Please study it a bit more, and revise what you learned in school about pointers, arrays and structures. Look again at the example and see how the data it displays is read. Regards, Pete