Jump to content
The simFlight Network Forums

Alpin-Flier

Members
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Alpin-Flier

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Untersiggenthal

Recent Profile Visitors

413 profile views
  1. Hi Thomas Yes, these are the correct event values. But I must use 8192 for power up and 16384 for power down in the parameter box and switch on the repeat function. Actually I leave the levers as axes and define an additional range at the end, where FSUIPC sends the parameter 8192 repeatedly. That seems to work fine (up to now 😉) Best regards Urs
  2. Hi Thomas Of course, you are right. To make it more real, I should use individual controls. I already found this in the PMDG SDK: #define EVT_CONTROL_STAND_REV_THRUST1_LEVER (THIRD_PARTY_EVENT_ID_MIN + 680) #define EVT_CONTROL_STAND_REV_THRUST2_LEVER (THIRD_PARTY_EVENT_ID_MIN + 681) I will make tests with them. Thanks again and best regards Urs
  3. Hi Thomas Thank you very much for answering. I make some precisions: My setup uses the possiblity in FSUIPC to separate throttle and reverser levers. Throttle levers 1 & 2 and reverser levers 1 & 2 are programmed with "send direct to FSUIPC calibration", then Joystick calibration page 3, checkbox "no reverse zone" is marked. So the throttle levers send values between 0 and 16384 to the sim, meanwhile reverser levers send 0 to - 4096 to the sim. That works all fine. But after touchdown I can take the reverser levers immediately to the max position, because there is no mechanical blocking during reverser opening. When the reversers are ready to accept high power commands, there is no data change any more and therefore no commands for high engine power. But in fact, with your proposal I can solve the problem. The reverser axes work normally, but with the additional security, that in the end position of the levers the thrust is granted after some seconds. Perfect !! Thanks a lot and best regards Urs
  4. Well, I just learned some minutes ago, that the problem arises from my control stand, that does not offer the following function (found in the PMDG manual): "Reverse thrust lever is blocked at reverse idle position until related thrust reverser is more than 60% deployed." Unfortunately my control stand (and probably most of other users) does not have this blocking of the levers. Is there a solution all the same? Best regards Urs
  5. Hi Pete My homecockpit with FSUIPC is working very nice, but please let me ask you for a solution of the following problem concerning reversers in my PMDG737NGX. When I operate my reverser levers after touchdown in one move to the end position (max. thrust), the reversers start opening, which takes some seconds. Then engines should go to the commanded thrust. But since I am already in the lever end positions, nothing happens (no data change any more). I must move levers out of the end position and then back. Or move the levers very slowly so that there are data changes still after opening. Not really smart procedures. Is there a way to avoid this and get the thrust position corrected after opening? Thank you very much for any idea. Best regards Urs
  6. Hi Pete Thank you very much for answering. In general I can do very narrow taxiway turns , so I think, controls are correctly adjusted and work perfect. Then I tried the pushback with the internal FS function (shift P and 2). But the result is the same, so PMDG probably uses the basic function in P3D. I cannot check the standard B737 of FSX, because in P3D I don't have this airliner. I tried also another P3D plane with similar result. Then I switched off my Zurich scenery. Again a very big radius. I think there must be a fundamental problem in FSX/P3D. In 2011 there were already discussions about this problem. The only way out would be GSX (of course, not ASX). But to be sure I will ask P3D people. Thanks again for help and best regards Urs
  7. Hi all It seems to be a very old problem, but I could not find any solution up to now. In the NGX I can define a straight distance and the angle (left or right) for pushback. But the radius of the turn is extreme, so my pushbacks end in the grass or a building in general! This seems to be an old problem of FSX and the same for P3D I use. On the other hand additional programs as ASX are told to solve the problem, so it should be possible. Is there a way in FSUIPC to get this radius under control? Thanks for any help Urs
  8. Hi Pete Thank you very much for your infos. I just made a check down in my homecockpit (separate PC and installation). There I don't have a delay at closure. So I had a look into the log file. I have seen, it's an older FSUIPC: ********* FSUIPC4, Version 4.949h by Pete Dowson ********* Prepar3D.exe version = 3.4.22.19868 Reading options from "C:\Prepar3D v3\Modules\FSUIPC4.ini" Running inside Prepar3D v3 on Windows 8.0 Module base=597C0000 .... 35484 Starting everything now ... 36812 Advanced Weather Interface Enabled 61750 Sim stopped: average frame rate for last 33 secs = 27.1 fps 73984 === NOTE: not calling SimConnect_Close ... 74984 System time = 18/07/2017 19:14:33, Simulator time = 16:30:40 (14:30Z) 74984 *** FSUIPC log file being closed That looks different, in fact. Then, of course, I'm using Win10. I'm sure you have an explanation :-) Thanks again and best regards Urs
  9. Hi Pete I have a similar problem in P3D_V3. Meanwhile the PMDG737NGX starts straight away, at closing there is a strange delay of about 6 sec, until the closure window of P3D appears. In the log file I have the same lines as above: 30907 Starting everything now ... 32203 Advanced Weather Interface Enabled 42141 === Closing session: waiting for DLLStop to be called ... 52063 === DLLStop called ... 52063 === Closing external processes we started ... This waiting for DLLStop seems to be the problem, right? When FSUIPC is disabled, PMDG is closed without any delay. This is just to inform you that there is something wrong also with P3D_V3.4. Best regards Urs
  10. Hi Pete Thank you very much for your most informative answer. So the actual FSUIPC is even much more clever than I expected :-). I just wanted to be sure, that all cockpit interfacing SW is loading the PC as low as possible. My homecockpit works with a single high power PC unit, and you are right, there is no degradation by FSUIPC as far as I can see. So I will buy the new version with pleasure. Thanks once more for all your fantastic work. Urs
  11. Hi Pete Fantastic news, that you will provide FSUIPC for P3DV4. My B737 homecockpit needs FSUIPC for sure. But I have a question: Would it be an option to make FSUIPC5 an event driven system instead of polling simconnect and PMDG NGX data, i.e. update data only at start and on changes? IMHO this would reduce PC load significantly. Just my two cents... Urs
  12. Hi Thomas Thank you very much for answering. I'm using the FSInterrogate from beginning, a really valuable tool. And you are right: reading values repeatedly results in correct readings. So the problem must be inside scpascal or at least how I use it. I will try to find the solution there. Thanks again and all the best for the coming holidays. Urs
  13. Hi Pete Hope, you are still there :-). I need again your help to understand why I cannot read individual offset values from FSUIPC. I use a special pascal version, the sc-pascal from simio electronics. The following procedures resp. functions work well: - On any FSUIPC change the offset and the related variable are received - At program start (connecting with FSUIPC) all variables are received to update the cockpit But during program I cannot read individual offset values. There is a function - ReadFSUIPC(offset,bytes) but it returns always a NULL I have the impression that PMDG delivers only values at changes. In the meantime no values are available. Is this correct or does scpascal access FSUIPC probably in a wrong way? Your help is most estimated. Best regards and all the best for the new year Urs
  14. The displays of my MCP are driven by SC-Pascal, which is a derivate of original Pascal. There is a definition for real variables called "single", that could correspond to FLT32: "A real variable is the one that contains decimals. Depending on the range, it can be negative or not; Single 1,5E-45 to 3,4e38 bytes 4 " But when I try to send the flt32 value as single to the display, there is shown only some rubbish. Not very astonishing because there are different definitions for floating point variables. Then I had a look to 02BC, but this seems to be the actual air speed of the plane, not the preset one in the mode control panel that I need. Best regards Urs
  15. Hi Pete I should indicate IAS from PMDG737NGX offset $6524 (4) in my homecockpit. The value comes out in flt32 format. I should send it to my IAS/MACH display as an integer from 100 to 340. Up to now I did not find an easy way to do that, because I am not really familiar with floating point variables and its conversions. Can you recommend me some procedure? Thanks a lot for help. Urs
×
×
  • 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.