Pete Dowson

I may be able to do so, but as of this moment I have no information. What FSUIPC read and write errors? Have you any FSUIPC logging to show me? I cannot help without information. Regards, Pete

AhI know about that problem. Apparently, in VB, for some reason best known to Microsoft only I think, if you write: $F084 it assumes you meant $FFFFF084 in the whole 32 bits. I'm told it even does this if you say $0000F084, which is quite bizarre. Now FSUIPC reserves some of those bits for special uses (the Advanced Weather Interface for one), and the best it can come up with is the 8FF084 you saw. I believe that you can stop VB from doing this silly thing by adding another $ at the end, thus: $F084$ I would have thought that it would be documented someplace in the VB guides/manuals. Regards, Pete

Sorry, this is so out of context I do not know what you are talking about. Please don't start new threads assuming I can pick things up from elsewhere -- just add new comments onto whatever thread you posted your original problems in. Thank you. If you are having problems with FSXpand why not ask their support? I really know nothing whatsoever about the product and would be very unlikely to be able to help in any case. Sorry. Regards, Pete

In what way does FS2004 "not work", and why do you think it is anything to do with FSUIPC? Pete

It really does sound like it cannot be 3.65. Please show me the log, or check the version again yourself using any one of the many methods. The previous one was certainly not 3.65 then. Always check versions -- in Poperties, on screen, or in the Log. Regards, Pete

Sorry, I cannot help with VB. But have you tried to help yourself at all? First of all, look in the FSUIPC options screen and find the Tab "Logging". On the left-hand side check "IPC Read" logging. Then run your program and look in the FSUIPC.LOG to see exactly what you are actually asking for. That's exactly what these facilities are provided for, to help you develop and debug your program. Another tool which you should find some place in your VB compiler installation is a debugger, Try that too. It is a great help when developing programs as you can see exactly what is happening. Pete

Did you not even look at the User Guide? It isn't hard, only one step, as the documentation says: Installation Copy the FSUIPC.DLL file into your flight simulator Modules folder. There. Not too difficult, surely? ;-) There's no difference whether it's a "Beta" or not, for ten years now the installation method has been exactly the same as that! The current version is 3.65 by the way. Pete

It won't be anything to do with Squawkbox. Sounds like you need to calibrate your throttle. Pete

Sorry, the code is no good to me. It doesn't tell me what you are writing to FSUIPC. Please use the FSUIPC Logging (see the options, Logging page). Log IPC Writes, then repeat your test, and look at the log. Show me it if you like. You should easily be able to see what you end up writing to 32FA. Yu are probably writing a value that tells FSUIPC to let the message to stay there till replaced (eg zero), or maybe for a very long time (eg thousands of seconds). Pete

Use a toggle switch so you can see? I'm not sure where to put such an indicator at present. It can't go in 310A, that's a programmable control which times out in any case. I'll add it to my list of requests for now and see what I can do before the next release. Regards, Pete

I just received the Log and the Key file, thanks. Now, see this clearly shown in the log? ********* FSUIPC, Version 3.50 by Pete Dowson ********* The Key is good, but it was purchased in 2006 and you are still using a very old FSUIPC 3.50. It was made perfectly clear in the notification you received with the Key, AND in the top announcement in this Forum, that you need AT LEAST 3.53. The current version is 3.65. Please just update your copy. Old versions are not supported in any case. You can always EASILY find the version number of your FSUIPC, by any of these methods: 1) Right click on the FSUIPC.DLL itself, select proprties then Version. 2) Run FS and look at the FSUIPC options. The first page which appears shows the version number. 3) Look in the last FSUIPC LOG file generated by FSUIPC. The version number is on the first line, as above. Regards, Pete

No, no one has ever asked for such a thing. Both the Hot Key and the bit in 310A are just requests to FSUIPC to copy throttle 1 to the other throttles, ignoring their own inputs. Being a simulation thing, not a real aircraft one, I didn't think anyone would have a gauge or indicator for it! Can you explain more about this need, please? Regards, Pete

OkayI'd obviously forgotten a *lot* about EPICINFO. It is indeed quite possible for me to run it and test it (well all except the talking-to-EPIC bits) with no EPIC attached. I'd forgetten entirely -- in fact I remembered later that I'd even recommended this once for non-EPIC users as a way of tracing the behaviour of the assorted Gauge variables. Anyway, it makes everythnig MUCH easier, and it definitely means I can see a future for it, or an equivalent facility possibly built into FSUIPC, for FSX and beyond. I'll just need someone around like your good self to test it on real EPICs for me! . Tracing through the code for the Scaling option you are using I can see why the 32768 bit is being added. The -ve number flag isn't cleared by the scaling code even though, post scaling, the result must always be positive. As far as I can see this error has ALWAYS been there, it is an integral part of the way it was coded way back when. I don't know what you did originally to get around this nor why you remember it differently -- what HAS happened in between, for you? Anyway, I've fixed it (one line) and I am attaching 4.23 -- the first update for nearly 3 years as far as I can tell! Please confirm it's okay for you now. Oh, one minor thing. I think the correct SCALE lines you want should be: PLANE_PITCH_DEGREES=Scale 360,-179,181 PLANE_BANK_DEGREES=Scale 360,-179,181 The RANGE you want is 360 (0-359), and the upper limit of the input is 181 (this is exclusive, as documented, making the max acceptable 180). Regards, Pete EpicInfo4230.zip

I've had a look at the code for this inside EPICINFO, and in fact FSUIPC is not involved at all! Those two variables, like nearly all of those listed for PHs, are obtained directly from the FS PANELS.DLL using the same interface as used by Gauges in FS panels. The only thing I can think of it that you are comparing some results from a much older version of EPICINFO. I do have some changes marked as being done in EPICINFO version 3.893, which affects the conversion of the floating point values I get from FS for these variables (all angles): PLANE_BANK_DEGREES PLANE_PITCH_DEGREES ATTITUDE_INDICATOR_BANK_DEGREES ATTITUDE_INDICATOR_PITCH_DEGREES but currently I don't see how these could affect the scaling. The change seems to have been to normalise the integer result to a value between 0 and 360. I'm not sure how EPICINFO then arrives at what you see. I really am so busy at present, and this would take quite a bit of ancient code analysis for me to figure out, especially without my old EPIC ISA boards usable (I've no PCs with ISA slots these days). I do have a USB EPIC here someplace, but I really never got into programming that so that would take even longer. On second thoughts, maybe I can run EPICINFO with the logging and so on and no EPIC card? I don't remember. I'll check that out when I get a chance. My problem still is making enough time to embark on something like this. I need a space of 2 or 3 days to suddenly appear. Very difficult at present. Is it really possible that you only recently upgraded to EPICINFO 4.22? Regards, Pete

GPSout needs a COM port number or name. I've really no idea how USB serial ports look, thouh there is one example someone gave me which I put into the TXT file documentation (did you look?) -- some thing like Port=\\\WCEUSBSH001 though I suppose this might be different for different devices or serial/USB drivers. The other thing is that, for most PDAs, as soon as you plug them nito the PC they get taken over by the automatic synchronisation software you or Windows installed to handle them. Somehow you would have to stop all that running too, to free up the port for others to use. I don't know how to do that. I never ever managed to get my PDA linked up, so you are not alone. Regards, Pete

1. FSUIPC 3.0 is far too old for me to support (3 years now). The current version is 3.65. Please review the announcements at the top of this Forum. 2. I very much doubt that any FS2002 dated program will have correct access to FSUIPC 3 in any case -- does it say in its documentation that it works with FS2004? If so, then they presumably have an access key for it. If not, then you have no option other than to buy a user registration for FSUIPC 3.xxx, or maybe to try to find a very old copy of FSUIPC (I think 2.975 was the last one for FS2002, nearly 4 years ago). 3. Your proper recourse for support for any third party application program is to the suppliers and/or makers of that progam. I'm afraid I couldn't possibly even consider supporting all of the thousands of add-ons out there that may or may not use FSUIPC, let alone those from years ago. Sorry. Regards, Pete

It most certainly sounds like it, yes. If you want me to check, try again, be sure to close FS after the error, then Zip up the FSUIPC.LOG and FSUIPC.KEY files from your FS Modules folder and send to me at petedowson@btconnect.com. Regards, Pete

No, because FSUIPC is not hardware dependent -- it deals with FS controls, not with hardware controls. Also there is no way I could possibly become familiar with all the hardware which could be connected to FS -- in this case, for example, I have no CH devices and I've never heard of that Vmax device you mention. Check the FSUIPC user guide. There is a step by step guide to calibrating FS joystick controls in FSUIPC, including both the generic single throttle (which, like the FS ones, has no reverse range), and the multiple separate throttles which, in FSUIPC, are made to have reverse by introducing an idle "centre" -- the "centre" which should be calibrated around your idle detente. It also expalins how you can map the one to the others should you be unfortunate enough to have only one throttle lever (which i would assume you are not). Regards, Pete

I'm afraid you've come to the wrong place. WidevieW is by Luciano Napolitano and is presumably supported on his own site. Please check the documentation for it, I'm sure it tells you where to go. Regards, Pete

Sorry, I think they must've meant someplace else, like the cockpit builders forum, somewhere near the top of the simflight forums list. I wouldn't know where to start -- this is mostly about software here. Pete

The methods used to provide the inter-process communication, between your program and FS, require access to assorted bits of the Windows API. Your program may not actually need to have a Window (or if it does it can be an invisible one) -- maybe it can be a "console program" -- but it certainly needs to be loaded by windows and have access to Windows APIs. Including the Windows header will allow that. But by all means, try just defining DWORD before calling up my header. Regards, Pete

Yes. The error refers to Line 37. Did you look at line 37? It is this: The data type "DWORD" is a Windows data type. This won't have been defined -- you have not even included the Windows header -- since, to access FSUIPC, you must compile a Windows program, this is essential. You could of course define DWORD yourself (it's an "unsigned long" in a 32-bit system), but you will probably fall foul of other things later if you do not include any Windows definitions. Please see if you can find a book on Windows programming -- for C the one by Petzold is good, almost essential. Once you can write a Windows program I'm sure FSUIPC interfacing will come much easier to you. Regards, Pete

Hmmmvery clever! Thanks. you are most welcome. Regards, Pete

No, it's okay. I'll sort it when i understand it. I am thinking of incorporating everything into FSUIPC for FSX and beyond (WideServer and GPSout are already absorbed), or at least making the other DLL's mere satellites (depenfing on size). I'll be looking at what I might be able to do for EPICinfo in due course. it is just in testing I will have some difficulties now. Pete

Ah, maybe that should have been reviewed with each release of FS. Sorry. Not having used EPIC stuff since FS2000 makes this quite difficult for me. I am pretty sure I wouldn't have used the term "original" for something derived. I would really need to compare the results from FS2002 and FS2004 to offer an sort of comment on this. Sorry. Have you removed FS2002 already? Regards Pete