Pete Dowson

It isn't my subject, but isn't the VB .Net Shell part of the FSUIPC SDK useful? Regards, Pete

It's likely to either be a bug in FS, or one in the PSS gauge code, but one which is probably either very timing dependent, so a clean tidy new faster install doesn't fail, for example, or which is derived from uninitialised data. Something as simple as entering a loop with a count of 0 or -1 (decremented) instead of some small positive number could easily produce such an error, and if that count is picked up from the stack or other uninitialised memory then it is just luck what the value was -- though it may well be consistent in a particular set up (because of how things are loading and running with that particular order of installation etc etc.) If the error can be reproduced on a test machine, one with, for instance, a debugger running on it, then it would be relatively easy to find out what is going on during that 20+ second freeze. But that's the thing -- reproducing it on a machine where you can do that. Anyway, I do have a copy of the latest PSS Dash 8 here now, and I will see if happens on my PC. If it doesn't then I'm afraid it is still dependent upon PSS tech support only. The other possibility is that it doesn't fail at all with the forthcoming official Microsoft FS2004 update, but we shall have to wait for that to tell. Regards, Pete

Well, it's only written as a test program for my FSUIPC weather interface, and provided as a free demonstration of what can be done. I'll note your request and maybe try to fit it in when there's nothing else needing attention, but I really cannot place it at any priority, sorry. Maybe this would be a good training exercise in FS application programming for someone? All the information needed to write such a small utility is available in the FSUIPC SDK. Regards, Pete

So there was something funny about the way the computer was set up, before? Hmmm. Strange. Maybe something very specific with timing. What about the others with similar problems? Have you told them so they can try to resolve it too? Regards, Pete

I'm afraid I know nothing about helicopters, so I am dependent upon others telling me what there is and what works. The drop-down lists in Keys and Buttons are simply taken from a table in FS's own CONTROLS.DLL. There are these variables which I never found any explanation for and haven't mapped: ROTOR BRAKE HANDLE POS ROTOR BRAKE ACTIVE ROTOR CLUTCH SWITCH POS ROTOR CLUTCH ACTIVE ROTOR GOV SWITCH POS ROTOR GOV ACTIVE ROTOR LATERAL TRIM PCT and these FS controls, which I don't know: ROTOR_BRAKE ROTOR_CLUTCH_SWITCH_TOGGLE ROTOR_CLUTCH_SWITCH_SET ROTOR_GOV_SWITCH_TOGGLE ROTOR_GOV_SWITCH_SET ROTOR_LATERAL_TRIM_INC ROTOR_LATERAL_TRIM_DEC ROTOR_LATERAL_TRIM_SET Whether any of these actually work or not, I don't know. Test them with a real helo model, not the FS2004 Robinson which I think has been implemented using a normal aircraft model. As far as the variables are concerned, if they are needed and likely to work I can probably find a way to map them, but I need some explanation first so I can understand a bit about what I'm looking for. Regards, Pete

Not without more information. I don't know this "CWR", what is it? * When you say "after a few seconds FS2004 goes in crash", can you elaborate please -- a few seconds of what? When you do nothing, or is there something specific? What sort of "crash" is it? Is there any message? What is happening on this "crash"? Does CWR use FSUIPC? Have you checked with support from the author about this problem? Please enable IPC read and write logging (in the FSUIPC Logging page), and run it once with 3.317 and once with 3.400, zip up both logs and send them to me at petedowson@btconnect.com. I will take a look. * [LATER] I now know what "CWR" is -- I didn't recognise it by that name, but as "WxGauge.gau", and, yes, it does use FSUIPC. Odd thing, though, nothing it uses has changed at all between 3.317 and 3.400. In fact, 3.317 is very similar to 3.40 -- a few additional user features have been added, but they will be inactive unless used. It is beginning to look at if there may have been a problem anyway in the Gauge which didn't cause a crash before simply because of some different memory arrangement (with things changing in size and so on). I'll check the logs and maybe ask Florian about this. Regards, Pete

Sorry, I don't understand. If all the tabs are visible then the whole dialog box is surely visible? The tabs stretch almost the whole width anyway -- or are they wrapping onto two lines on your system? FSUIPC uses standard Windows calls to make, size and display the dialogue box. No sizing or font selection or anything is done in any of my code, only by standard Windows routines and settings. And the FSUIPC code for doing it hasn't changed since version 2.00, several years ago, when the on-line options were first added. I can only think that something is your Windows system is wrong. Maybe something you've installed has replaced one or more of the standard system libraries, like COMCTL32.DLL? If you post in the FS2004 Forum and ask Katy Pluta about this, she might know how to go about fixing it. Quite honestly, I have absolutely no idea. Sorry. Regards, Pete

But as far as I know there's no NMEA protocol defined for USB, so there's no way that will be used for NMEA connections. The USB connection to GPS's and PDA's is for transfer of data, not for real-time updating of position from an external GPS, which is effectively what GPSout is simulating. The NMEA protocol appears to defined ONLY for a serial port. Check your GPSMAP 96 specifications more thoroughly and I think you'll find there's no way of getting it to track a position supplied externally via USB. Regards, Pete

Good. That's correct when you are operating the taxi-winds manually. You can use automatic mode too, of course. Regards, Pete

Good. Thanks for confirming. Regards, Pete

Thanks -- I got one of those last year (see awards on the Schiratti/Dowson page! :D :wink: ) Best regards, Pete

That's because I didn't know about it and no one ever asked before. I think I've found it. I'll map it to: Engine 1: 3828 Engine 2: 3768 Engine 3: 36A8 Engine 4: 35E8 They are doubles (FLOAT64) and in degrees Rankine. Shame you didn't ask a week ago, I could have slipped these into version 3.40. Meanwhile I'll email a test version with this mapping, for you to test for me. Okay? Are you able to check in on FS2002 also? It may or may not be correct there, I'll need to know for the SDK. Regards, Pete

I've not seen that, and it hasn't been reported elsewhere, but please try FSUIPC 3.40, released a couple of days ago. I am not looking at anything on 3.30, there have been far too many changes since then. Regards, Pete

It adds random turbulence, occasionally, to weather provided through the FSUIPC interface -- i.e. from external programs like FSMeteo, ActiveSky and FSMetar. Regards, Pete

The list of all my modules, including which one's need FSUIPC and which don't, appears near the top of this Forum. I think with FS2002 you will need FSUIPC installed as well as GPSout. It was made independent for FS2004. Try it anyway, it may work without. All my modules are available in http://www.schiratti.com/dowson. Regards, Pete

Well, I would if I had any idea. I'll see if I can get the latest version first and see if it happens here -- it certainly doesn't happen on my PC with the old FS2002 version of the Dash 8, that flies fine in FS2004. Otherwise I'm afraid all I can do is show you how to get the evidence together to send to PSS. I already did that with the log you sent, but Thanos' has a better log and more precise data he can report. Regards, Pete

Okay. Thanos got in touch too and sent me another log with writes shown too. I think this locates the places the gauge us freezing rather more accurately so I asked him to send the details to PSS. Meanwhile, I found a copy of the PSS Dash 8 on my PC (I think they sent it to me to check something a while back), and I've just flown a short flight with it in FS2004, manually, using the normal 2D cockpit, and it ran as smoothly as I would expect. Certainly no freezing at all. So, am I one of the "lucky ones" or is there something different about my installation? The main PSS Dash 8 gauges I have are pretty old, though -- PSS-Dash8.gau is version 1.0.0.1 and dated 15/12/2002, and the PSS-Dash8Q.gau is the same. This is way before FS2004 of course, and they don't register themselves for access into FSUIPC, so they won't run on a non-registered FSUIPC. Yes, do please let me know how you get on, too. Regards, Pete

No, it certainly does not. Thanks anyway. Regards, Pete

The TrafficToolBox DLL was written by the same person who designed and wrote the FS traffic system in the first place, so obviously he knows all about it. Unfortunately there is nothing else in the traffic SDK to help anyone else write such tools. I spent a lot of hours finding the things I have found. Regards, Pete

Yes, thank you. I've got it. Of course, since you only enabled IPC read logging and not both read and write logging, as I asked, it does only contain part of the story. However, if we assume that it doesn't do many writes, and also that at least they are not occurring in the gaps that appear, then the Log is a bit useful. Not for me, but for you in your bug report to PSS I think. The access the aircraft makes to FSUIPC is fast and furious and appears to be all good stuff, but there are long gaps (hopefully not full of writes which you didn't log): After the Gauge registered itself, here: 179516 Module "PSS-DASH8Q.GAU" access registration is okay there was immeidately a 46 second delay till it started doing anything else with FSUIPC: 225172 READ0 32FC, 2 bytes: 02 00 That seems an awfully long time, but it may well be that you are using the initial Flight menu in FS, and I see the aircraft is loaded as your default aircraft, so the gauge will load early, long before all the scenery and stuff is loaded. It might be a good idea if you changed your default Flight to load some default aircraft, then changed to the PSS Dash 8. There are many problems reported with most versions of FS when complex aircraft are loaded by FS initially, before it is fully initialised. I think some of the more sophisticated gauges do things which are really not proper that early. There are then good sequences of FSUIPC interface activity, interspersed with delays. The first such is about 35 seconds, till: 259985 READ0 32FC, 2 bytes: 02 00 then a 6 second delay: 266485 READ0 32FC, 2 bytes: 02 00 and another 48 seconds: 315500 READ0 F000, 2 bytes: 28 00 and finally one of 31 seconds: 346235 READ0 32FC, 2 bytes: 02 00 Sorry, it is not a problem I can solve -- evidently the whole freezing sequence is inside the gauge (or as you say, the MDL perhaps). But try with a default FS aircraft loading first, as default (this means going to the flights menu and selecting a default flight and marking it as default, then closing FS and starting again). Load up your PSS Dash 8 after FS is up and running and "ready to fly". If you get the same problem report all you've learned and collected today to PSS. If you don't get the problem, then I'm afraid that is the way you will need to run in future. It means the aircraft is doing something too sophisticated for FS before it is fully enabled. Regards, Pete

You could just test with different (FS2004 default) MDL and AIR files, for the closest aircraft to the Dash 8. It would at least show whether it's gauge code or not. Really I think it must be the latter because, as you say, there's no delay when FSUIPC isn't there. The delay is therefore something the code is doing after it successfully connects to FSUIPC. All I'm trying to do with the Logging is see whether the gauge code is looping furiously doing silly things across the FSUIPC interface. If it looks normal, then it is something it is doing elsewhere but only after successful connection. Regards, Pete

Er, as I said before twice "switch on IPC read and write logging in FSUIPC's Logging options page (ALT M F)." When you press ALT M F in FS the FSUIPC options comes up, as it always has when FSUIPC is installed. It's part of the Modules menu. Can you not see the tab marked Logging? How is it you cannot use FS menus? I'm getting very confused here as to why you are not understanding even how to do keypresses. :cry: Please, please, please take a little time one day to at least peruse the FSUIPC User guide. It would save a lot of time and anguish. Regards, Pete

I'm not surprised. It would be really puzzling if it did. It was only a straw, nearly the last. Er, as I said "switch on IPC read and write logging in FSUIPC's Logging options page (ALT M F)." The Logging page has a tab entitled "Logging" and there you will see checkboxes for IPC read and IPC write logging. I thought I was completely explicit? How wasn't I? Regards, Pete

Okay. It certainly isn't registration being any problem. I've only got one other straw to clutch at. Add [buttons] PollInterval=50 to the FSUIPC.INI file, before running FS. Let me know. Up till now this has only been needed with Win98/Me/2K installations, and is defaulted that way now in FSUIPC 3.40. I've had no problems reported with WinXP, but try it just in case. If that doesn't work, switch on IPC read and write logging in FSUIPC's Logging options page (ALT M F). Do this BEFORE loading the Dash8. The file may get huge. ZIP it and send it to petedowson@btconnect.com.Don't keep those options enabled afterwards. Regards, Pete

I can't tell from the code what offsets you are reading or writing. When you say you "get a Throttle Level of Zero", is this looking at FS when you write something different, or is this something you are reading? Please explain what you are doing rather than show me code which is completely alien to me, I'm afraid. See the FSUIPC SDK, the Programmer's Guide therein? Check the offsets and definitions of what you are reading and writing. Check these also with the tool FSInterrogate, provided specifically for this purpose. Also, use FSUIPC's IPC read and write logging to check what it is you are doing as far as FSUIPC is concerned. You can also use the monitoring facilities in the FSUIPC Logging page to monitor values at offsets in real time. Please use the tools available and I'm sure you'll solve your own problems. If not, explain what you are doing and seeing and I'll try to help. Regards, Pete