Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Yes, i understand that. When I get such situations I have to insert extra logging to get more information. Yes, but the check which results in the error is in your process, your part of the code, not in FSUIPC. The source for it is provided in the SDK. Error #12 is defined, in the IPCuser.h header file as folows: #define FSUIPC_ERR_SENDMSG 12 // IPC sendmessage failed all retries and is detected here: // send the request (allow up to 9 tries) while ((++i < 10) && !SendMessageTimeout( m_hWnd, // FS6 window handle m_msg, // our registered message id m_atom, // wParam: name of file-mapping object 0, // lParam: offset of request into file-mapping obj SMTO_BLOCK, // halt this thread until we get a response 2000, // time out interval &dwError)) // return value { Sleep(100); // Allow for things to happen } if (i >= 10) // Failed all tries? { *pdwResult = GetLastError() == 0 ? FSUIPC_ERR_TIMEOUT : [color="#ff0000"][b]FSUIPC_ERR_SENDMSG[/b][/color]; return FALSE; } So it occurs not due to timeouts (which can happen if something causes FS to stop FSUIPC getting any messages for long enough), but because the call actually fails. I suppose better information would be obtained if my code did something with the error number returned by GetLastError, but it really never happened (before the days of Vista and Win7 and privilege levels). You seem to have described it as "error sending message" which is a little vaguer. Is this why you don't understand what it means? The other one, the "already open", shouldn't arise normally -- on the first failure, the failed exit from the FSUIPC_Process call in the FSUIPC_Open should have closed the Memory Mapping stuff via FSUIPC_Close. Maybe the Managed code (which I don't know) is missing something? The other odd thing reading a bit more of the thread is that someone said the connection must have been made because the aircraft position is shown ...? If that's true, then possibly the failure somehow occurred during a successful connection, and your program or the managed code attempted to re-do the link without closing the current one. But if this is indeed the truth of the matter, I really have no idea why the SendMessageTimeout would have failed -- unless possibly Windows failed it because FS had hung or was closing, so the addressed Window was inaccessible. Regards Pete
  2. Unless you installed FSX in its default "Program Files" place you shouldn't need to run it "as administrator". That's really only needed when you are running other programs which have to be able to access its folders -- folders in "Program Files" being write protected. And then the have to run everything "as administrator". If WideFS is enabled it ALWAYS adds details to the FS title bar. That's been the case, with no change in the display, since WideFS was first published in its current form, in FS2000 days. Pete
  3. Perhaps Bluetooth might work from the PC, if the bluetooth driver running there looked like an openable serial port, like USB connections often do? Sorry, that link doesn't appear to work. Does it tell you how to set the PC end up? Just a port name, like COMn or one of the more complex USB port names. If you wanted to send the data to an IP address that would best be done by using a Lua plug-in. There's a Server/Client example pair of Lua plug-ins provided in the FSUIPC installed package which drive a slave copy of FS from a master. You could probably adapt that. You'd need to change the data format being sent to NMEA sentences, of course, and reduce the frequency from its 20 fps to more like 1. Yes, I know about that one. I did actually try it, but its mapping is too bad outside the US. Their solution at the FS end is similar the one you'd get with a Lua plug-in. If sending it via WiFi instead of USB is easier to set up in the iPAD, i'd advise looking at doing it that way as it might be easier in the PC end too. Regards Pete
  4. Hmm. Strange, as I remember making little adjustments in the detente facility zone delineations to specifically make that work better with the PMDG 737. The default values for the Microsoft 737 caused difficulty setting the Flaps 1 and 2 levels I think. I managed to find compromise values which worked with both default and PMDG versions. I thought most of those switches could be operated via Mouse Macros? I'm afraid I don't have any add-on aircraft at all these days to check it for you. Have you tried? Regards Pete
  5. Odd, because the error message comes from his program, reporting an error detected in the application part of the interface, for which he can easily check because the source is available. In fact if it is reproducible it is debuggable because of that. Just the messages would have been as good, if not better. The "already open" one has go to be because of two or more attempts to open. The original error, however, would need debugging. The only problem I know which is not always obvious is when someone is running FSX at one privilege level and the Application at another. In other words, running FSX "as administrator" but ADE not, or vice versa. Windows then prevents the two exchanging data. I did try to program a way around that in later versions, but I see you are still on the main 4.60a release. You could try 4.669 (see Download Links subforum), but really first make sure you are running everything at the same privilege level. Regards Pete
  6. So, a comparison of the two INI files would prove very helpful, would it not? A much easier way to diagnose the problem than trying to work out which bits of the INI you supplied applies to that aircraft? Isolating just those lines rleevant to Throttle axis assignments and calibrations, you have: 1=CH THROTTLE QUADRANT 1.GUID={631A6290-C9A3-11DF-8002-444553540000} So the Throttle is joystick #1. 2=CH FLIGHT SIM YOKE USB 2.GUID={631A89A0-C9A3-11DF-8003-444553540000} Doesn't the yoke also have a throttle mounted on it? I seem to remember, aeons ago, my CH yoke having one, on top. [Axes] 3=1X,256,D,9,0,0,0 4=1Y,256,D,10,0,0,0 5=1R,256,D,42,0,0,0 6=1V,256,D,41,0,0,0 Those are Throttle 1 and 2 and Reversers 1 and 2. [JoystickCalibration] Throttle=-16384,16383 Throttle1=-16253,-10532,512,14208 Throttle2=-16384,-8842,512,15232 Seems okay except you have the default throttle calibrated too? Best press "Reset" on that. [Profile.Jets] 1=PMDG 2=FeelThere Boeing 3=Learjet 45 4=Level D Simulations B767-300ER 5=Commercial Level 6=Boeing 737-800 7=Boeing 747-400 8=Bombardier CRJ 700 9=CS 727-200 10=CS 727-100 11=Captain Sim 757-200 11=CS 767-300 12=Boeing 777-223ER 13=CS 767-300 14=CS 767 Captain AWACS 15=MS-760_AAF 16=LSH MD-82 17=Super 80 Professional 18=Eaglesoft Citation 19=PIC Citation X 20=jf_A320-211 CFM56 21=jf_A320-232_IAE 22=Airbus A321 23=A330-200 24=Feelthere A340-300 Airbus 25=Feelthere A340-600 Airbus 26=CS_B707-300 27=Concorde 28=Embraer 175 29=Embraer 195 You have a ***LOT*** of aircraft categorised in your "Jets" profile! And these are all fine with the throttles? Which here will your LevelD B 737 match to? Or have you not assigned it to a Profile? We'd need to know to understand which calibration is appropriate. Also, you appear to have "Level D Simulations B767-300ER" listed as a Jets profile aircraft whilst also having a separate Profile for it too: [Profile.Level D Simulations B767-300ER] 1=Level D Simulations B767-300ER [JoystickCalibration.Level D Simulations B767-300ER] [buttons.Level D Simulations B767-300ER] To be honest, I'm not sure which of the two assignments will take priority in such a case. However, carrying on: [Axes.Jets] 3=1X,256,D,9,0,0,0 4=1Y,256,D,10,0,0,0 5=1Z,256,D,11,0,0,0 6=1R,256,D,43,44,0,0 7=1U,256,D,12,0,0,0 8=1V,256,D,41,42,0,0 That's the Jets profile 4 throttles and 4 reversers. [JoystickCalibration.Jets] Throttle=-16384,16383 Throttle1=-16384,-512,512,14208/32 Throttle2=-16253,-512,512,15360/32 Throttle3=-16384,-512,512,14720/32 SyncSlopeThrottle3=26/26,33/33,44/47,62/66,85/86,104/104,127/128 Throttle4=-16384,-512,512,14848/32 Reverser1=-16384,14848 Reverser2=-16384,14848 Reverser3=-16384,14208 Reverser4=-16384,14208 SyncSlopeThrottle4=26/33,30/47,53/66,81/86,109/104,127/128 SlopeLeftBrake=15 SlopeRightBrake=15 You appear to have the default throttle calibrated too. Best to "Reset" that. Not sure why you sre Synching throttles 3 and 4 but not 2. Is it because they are behaving very differently? Anyway, there's nothing i can see here which would mess up only ONE "Jets" profile aircraft and not the others, assunming your 737 fits as one of those listed. Looks like a comparison with your older but working INI is necessary. Regards Pete
  7. You posted a support question into the User Contributions subforum, which is a repository for user contributions so they don't scroll down and get lost amidst normal support requests. You are lucky I noticed it. I've moved it here to the proper Support Forum. How does your real GPS in your aircraft connect ot the iPAD? Or are you, for that use, using the iPAD's own GPS? If the latter, then are you sure the iPAD application even accepts NMEA positional data to override the internal GPS readings? In any case I suspect you'd need a specific USB driver written to do the PC end, as at present when you connect an iPAD to a PC it is registered to it as an external disk drive. The iTunes driver obviously exploits other parts of its interface, and it is those you would need to tap into. If it could be treated as a normal serial port then the standard GPSout facilities in FSUIPC4 might work once you find the right port name and sentences. Or, you could experiment with a Lua plug-in to FSUIPC. The latest Lua com library includes facilities for handling USB devices. Are there any PC applications which do talk "NMEA" with your iPAD apps? If so then you could probably discover how to do this with a USB Port Monitor program, such as that from Aggsoft. (http://www.aggsoft.com/). That's what i use. Regards Pete
  8. Where did you get "VertSpeed" from? It isn't listed in the CSV file. Sounds like you edited the file whilst FS was running? I know no way any software of mine would find and delete entire sections of an INI file. You are using the correct version of PFCHID.DLL, aren't you? 1.20 dated 15th June 2010? Regards Pete
  9. I'm afraid I don't know anything of this "matlab" or "Aerosim blockset, but it sounds as if your WideFS is either not connected (i.e Wideclient is not connected to WideServer), or there is a problem with the Registration of either FSUIPC or WideFS. I cannot help further without information. Close everything down, then find the Log files and paste them into a message here. The logs I'd need to see are: FSUIPC.LOG from the FS Modules folder WideServer.LOG from the FS Modules folder WideClient.LOG from the folder on the Client PC where you placed WdeClient. Regards Pete
  10. Okay. But the names you are choosing for the actions don't all correspond with the ones which the PFCHID driver will be using. You haven't looked them up in the PFCmacroIndex.csv file provided! Therefore they cannot be invoked! For example "Speed" should be "Airspeed", and probably "VertSpeed" should be "AltPreSetVs" (There's also an "AltPreSetVsC" which I don't remember. Try both, see which one matches your VS preselect knob -- else get back to me and I'll try to dig out the specifications if I can. not seen them for a couple of years!). Not sure what you mean by "Vert". "FDCapt" is "ApFD", and "A/T-Capt" is "ApAutothrottle". Please don't ignore the stuff I provided. A lot of work went into that to make them all automatically assignable, once you made the matching Macro file. Er, exactly as it says in the document. did you miss the bit that says: So, obviously I thought (?), you can name it PFC.mcro, or keep it named pmdg747.mcro and put MacroFilename=pmdg747 in the INI file. Didn't you read the User documentation at all? That file is where you find the macro names you need to use. With this system you don't do ANY assignments in FSUIPC. Instead the PFCHID.DLL invokes the macros for you (via FSUIPC) by using the names it knows, the ones listed for you, and the macro file it also knows the name of! Please tell me why none of this is obvious from the documentation supplied. I'd really like to know how it failed so miserably to tell you any of this. :-( Regards Pete
  11. I assume by "FSUIPCS" you mean "FSUIPC"? What is this "Fsp" you open? The Registration of FSUIPC is handled by the Installer. When you run the FSUIPC Installer it ends with a screen allowing you to register. You enter your details there., nowhere else. And all three parts -- name, email and 12-digit key MUST be exactly correct. Use cut-and-paste if you aren't sure. Also check that you purchased the right key. FSUIPC3 (for FS2004 and before) uses different keys to FSUIPC4 (for FSX and later). The earliest supported version of FSUIPC for FS2004 and before is 3.98, and for FSX and ESP is 4.60. Prepar3D needs 4.663 at least, available in the Download Links subforum. Regards Pete
  12. Well, as you'll see from the PFCHID documentation, you can build an FSUIPC Macro file, using the pre-defined macro names listed in the CSV file supplied with the driver. If you don't have this stuff, check the DownLoad Links subforum here for the full PFCHID package. To make the macros work on the PMDG 747X you'd need to refer to the methods that aircraft needs. There's quite a full implementation contributed by Guenseli in the User Contributions subforum. One way to implement things would be to simply make each of the PFCHID macro entries call the Guenseli Lua package with the required parameter. That wouldn't be the most efficient way (melding the two would be better), but it certainly wouldn't take so long. Note that there's really not much in common between the console you are using and a fully implemented 747 like that from PMDG. I'm not sure how much you hope to achieve. Folks using hardware to interface to such aircraft have to have masses of switches and knobs they can assign and label. I think you would have to be prepared to use the mouse and on-screen panels for many of the functions, especially most of the overhead, and a good part of the MCP and EFIS controls. The radios should work okay as is. The GPS is not used in the 747. The main flight controls, throttles etc should all be okay. 747's are flown with autopilot and FMS's. Of that I suspect you can only really hope to operate some of the A/P and A/T functions on the console switches and knobs. At least you don't have the problem of displaying A/P read-outs on your console's "MCP" -- that's the usual problem with PMDG aircraft, extracting data for hardware MCPs. Regards Pete
  13. This is probably because the aircraft creator has used his own simulation for those things. You'd first need to use the supplied Lua plug-in to log "L:Vars", to see if they are used and if so which ones change when operating those switches. Just place the Lua file into the Modules folder, run FS, and assign a keystroke or button to it. When it runs it displays the L:Vars and changes to them. For examples of how to do things then, checkout some of the submissions in the User Contributions sub-forum. Well L:Vars might be usable. I see that there are already several A2A aircraft supported that way -- see the A2A Spitfire, B17, P47 and B377 threads in the User Contributions subforum. Regards Pete
  14. Versin 4.26 is years out of date and completely unsupportable. Where did you get it? The oldest official version for FSX at present is 4.60, soon to be superseded by 4.70. Please update. Of course. Why on Earth would you think not? Yes, that, and the 4.60a (or better the 4.638) installer -- see the Download Links subforum. 4.26 is most certainly NOT okay! Regards Pete
  15. I am still astonished that you can get FSX to load, from a freshly booted system, in such an incredibly short time. You must surely be talking about reload times, not initial boot? If you do mean the latter, then, yes, even on my lesser systems, despite plenty of assignments and so on, FSX will reload in 15-20 seconds. Here's a typical log (and this is with a brief stop of the initial FSX selection menu while I clicked "Fly Now", and a Console Log window being maintained by FSUIPC as well): ********* FSUIPC4, Version 4.669 by Pete Dowson ********* Reading options from "E:\FSX\Modules\FSUIPC4.ini" Trying to connect to SimConnect Acc/SP2 Oct07 ... User Name=########### User Addr=################## FSUIPC4 Key is provided WideFS7 Key is provided Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=255 282 System time = 29/03/2011 23:53:01 282 FLT UNC path = "C:\Users\Pete\Documents\Flight Simulator X Files\" 329 FS UNC path = "\\LEFT\FSX\" 1204 LogOptions=00000000 0000001D 1250 SimConnect_Open succeeded: waiting to check version okay 4172 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 4172 Initialising SimConnect data requests now 4172 FSUIPC Menu entry added 4235 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y 4250 C:\Users\Pete\Documents\Flight Simulator X Files\738 EGCC ready.FLT 4250 \\LEFT\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.AIR 17922 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 18750 System time = 29/03/2011 23:53:19, Simulator time = 23:53:06 (22:53Z) 18829 Aircraft="Boeing 737-800 Paint1" 18938 Starting everything now ... 19016 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N 20079 Advanced Weather Interface Enabled Mind you, I've never really cared about the load time. Better things are done then than spread out throughout the actual flying time, which for some things is the alternative. This is why FS builds its indices at load time. Strange that the load time matters more to you than good controls. Are you re-loading FSX many times a day? I tend to load it once unless I'm testing something which requires reinitialisation, like changing FSUIPC or similar. Seems odd to worry about 2 minutes in a possible many hour session? If merely having FSUIPC registered makes it take some 90 seconds longer on an FSX reload, then I'm guessing there might be a rogue joystick driver installed on your system, especially possibly an old Game Port driver. Those used to measure joystick positions by timing the discharge of a capacitor. If no such device is connected they can take seconds on each interrogation merely to detect this and report it. Use the Windows Game Controllers to find out, and uninstall any you don't need. BTW 4.638 is quite old now too -- that was just the last Installer update. The current "latest" is 4.669, which will become 4.70 and replace the 4.6x series as the only supported version for FSX. Regards Pete
  16. I don't know that PFC system. Is that a Cirrus console, or some version of their cockpit? Have you checked that you can see all the buttons and switches in FSUIPC? I think the USB driver tends to have all of them pre-programmed for their labelled function, and the translation of those functions into FS will be aimed only at the standard FS functions. If it is a console using my "PFCHID.DLL" driver, then that is not only compatible with FSUIPC, but it needs FSUIPC to run. In that case the switches and knobs are reprogrammable via named FSUIPC macros, as described in the document I supplied with the PFCHID.DLL driver. The PMDG aircraft are well-known for inventing all their own subsystems and not using all that much of what is controlled through standard FS options at all. So it doesn't sound terribly hopeful. Don't you think you should have researched this a little before making such investments? However, that said, there are solutions to some of the areas - see the User Contributions subforum. I use a PFC cockpit with a PMDG-originated aircraft, but I discard all of the PMDG panels and subsystems and substitute Project Magenta instead. Whether that is possible with your PFC device I don't know. The 737NG cockpit I have pre-dates all of PFC's USB stuff by years. And the drivers I wrote for non-USB equipment allow complete assignment flexibility. So, in summary, without knowing more, I really don't know. I doubt that any PMDG aircraft is fully controllable from any hardware, though there are some solutions for the FS9 versions -- as can be seen in the User Contributions subforum. Regards Pete
  17. Just save the FSUIPC INI file (the "configuration settings") plus any macro files (.mcro) and Lua plug-ins (.lua) you may have created, downloaded or whatever. These are all in the FS Modules folder. You can put them in the new Modules folder after installing FS and FSUIPC, and re-registering same. There's is no problem transferring aircraft specific or Profile settings, as the names used don't change. However, if you have more than one controller (yoke, pedals, throttle) on separate USB connections you might want to consider using the Joystick lettering facilities in FSUIPC before you lose your current setup. The joystick numbering using the Windows-assigned IDs which identify your different control devices might change in the new setup, and this will make all your current assignments get mixed up on wrong devices. FSUIPC can track devices, but it needs to be told to use letters instead of the ID numbers, over which it has no control. There's a chapter about all this in the User Guide. Regards Pete
  18. First, please NEVER use all CAPS as you are. It makes it more difficult to read and comes across as shouting. No, it isn't readable. Can you read it? Maybe you've got a huge extremely high res screen? Mine's 24" running at 1920 x 1600, and it certainly isn't readable on that. In any case it would be a lot easier for you, and quicker too, to just say what the error it purports to show is. I didn't see any of your parts because you included them in the quote of my reply. Pete
  19. Ah ... I see what you are doing with your replies. you are quoting my whole reply then inserting your bits INTO my reply. That's not good. It means I can't quote you back, and it is unlikely that I even notice your added contenyt because there's no point in me reading my own words. Please either quote things properly -- i.e. only quote my reply bits, not your insertions, or don't use the quote facility at all. I'm going to edit your last reply so I can deal with it. ... Pete
  20. What was the last message for? Are you expecting me to be able to read that graphic somehow? Please NEVER post a message with no explanation. It is pointless just posting a quote of my last message and an unreadable graphic only. If it was something from FSX saying it had a problem with FSUIPC4 it is probably only the well known glitch with SimConnect's trust checking. It's an intermittent problem which occurs infrequently -- Microsoft knew about it but never managed to fix it properly. You just need to retry a couple of times and it cures itself, it seems. Alternatively, if you look in the Download Links subgforum you will find later versions of FSUIPC -- a new installer 4.638 and a very much updated version 4.669. Pete
  21. Sounds pretty normal. Takes longer on mine, but I do have a helluva lot of scenery. 4.57 is very old and completely unsupportable. If you want help here you must use a currently supported version. 13 seconds? From a freshly booted Windows? That's incredible -- sounds like you have no add-ons at all. I've never seen any load time that short, and my system is an i7-980x running at 4.65GHz and using separate SSDs for Windows and for FSX. Are you using FSUIPC's facilities? Have you tried disabling WideServer (in the FSUIPC options) and deleting the FSUIPC4.INI file so that it resorts completely to defaults, with none of your facilities active (better take a backup first!)? Also, have you defragmented recently? BTW I see you registered FSUIPC and WideFS 7 months ago. Have you only started using it recently, or is this a new "problem"? And why register such an old version? 4.60 was out 4 months or more before your registration. If you have any more questions please update to a supported version first. Regards Pete
  22. Check the "on ground" flag in offset 0366. Sorry, too difficult for one who doesn't know VB at all. Can't you adapt the example in the SDK? Regards Pete
  23. I don't know about the G940 at all, but you might find useful tidbits in the assorted SubForums in this Forum, particularly the 'User contributions" one. If you have any specific questions on how to program conditional button actions which aren't answered in the FSUIPC documentation (and those examples would be in the Advanced User's manual), by all means ask. But I can't offer to write a complete tutorial for you. See what you can find first.. I'm not sure what the "FSUIPC for Dummies" document you refer to was, but there is SimSamurai's document available in the FAQ subforum. Regards Pete
  24. Good. That's okay then. Pete
  25. What does FSUIPC have to do with any of this, and what do you think uninstalling it and re-installing it does? It's only a DLL and if that gets corrupted it won't run in any case. It sounds like installing CS757 corrupted your PMDG 737 installation and maybe other things. None of that is at all related to anything FSUIPC does. But check and be sure you are running a recent version of FSUIPC. nothing earlier than 3.98 should be used. Sometimes aircraft or application installers overwrite later ones with earlier ones, so always use the FSUIPC Installer. Regards Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.