Alpin-Flier

Hi John First of all, after some throttle range adjustment following your advice the reverser#2 works again. I think I had in fact a problem with the 0 position of throttle#2. When there is no or little dead zone, it may send erraneous or repetitive positive signals to the throttle axys during reverse operation, resulting in a reset of the reverser. Unfortunately there is still this only throttle axys in MSFS, working as throttle in the positive range and as reverser in the negative range (FSX heritage). My problem is solved therefore 😊. But during my investigations I found some log problems I did not experience before MSFS. E.g. I cannot display log infos in a FS window (selection is grayed out). Is that normal? When I choose for infos in the window title line, I can see the first defined offset there but always with 0. The only way to see changes is the console resp. the log file. The Flaps control works fine again after a new calibration, even using just the axys and not the range method. Well, sometimes I loose survey. There are so many parameters in such a homecockpit... Specially the mixing of Tiller and Rudder resp. Throttle and Reverser resp. Brakes and Parkbrake_Reset tend to make problems 🤪. And correct function depends on where they are defined (FSUIPC or MSFS). Finally I have a comprehension question. IMHO PMDG still does not allow direct axys control, but only increase and decrease commands. But it returns the positions of the internal levers. Is it correct, that FSUIPC compares the hardware positions with those values and sends then increase or decrease commands, until they coincidence? Or am I completely wrong? Let me thank you very much for your fast and committed help. Without such help it would hardly be possible to realise such complex, but fantastic systems. All the best Urs

You are right, the version has no influence. So I made a new log including Events and Axes Controls. Strange for me: so many AXIS_FLAPS_SET lines. I did not touch the flaps lever. First I moved throttle 1 and 2, then reverser 1 and 2. FSUIPC7.log FSUIPC7.ini

Hi John Since my last update of FSUIPC I have a problem with my right reverser, meanwhile the left one works perfectly. When I move lever#2 to some amount, the reverser engages, first yellow, then green on the display. But after some seconds, without moving the lever any more, the display turns to yellow and then to off. Every time I move the lever a little bit, the same happens. Reversers 1 and 2 are programmed the same way. Any idea what I probably have done wrong? I enclose the last log-file. Best regards Urs FSUIPC7.log

Thank you very much for your fast and most informative answer. The conclusion therefore is: "You just need to move the hardware lever to its initial position before starting MSFS/FSUIPC. " and touch it again only after some delay. I can live with that. All the best Urs

Hi John Thanks to FSUIPC I could realise a really fine working homecockpit with MSFS and PMDG B737-800. But there is a small problem I could not find a solution for. I would like to synchronise the SW flaps lever at program start with the HW lever in my homecockpit. Lets assume that the SW lever is on any position, when FSUIPC starts. It goes always to 0 after about 14 sec. It then takes over the HW position only after the first HW lever move. During the 14 secs any HW lever move is not recognised. The HW lever is working on the flaps axis in FSUIPC (see FSUIPC.ini joined). I tried to find some info in the FSUIPC.log file (joined) and can see, that ca. 14 sec after PSUIPC start WAPI is started and Lvars/Hvars are received. I don't understand them really, but the solution could be there. How can I proceed? Of course, flaps lever should always be on 0 after leaving the cockpit. But under simulation conditions this may not be granted. Thanks for any help and best regards Urs FSUIPC7.ini FSUIPC7.log

Hi John Ok, no chance therefore. I agree, that there are several options to access events. I am using some (also presets) successfully. The problem arises, when there is a missing link to an event due to a bug in the airplane code. In such cases mouse macros where the only way to get around, because mouse operations worked always. Just to explain my request: My actual (of course small) problem is the TimeCompression control in the PMDG B737. The offset is there, but no way to influence it. Only the mouse is able to activate it, the rest not. I made a ticket to PMDG and was told to wait for a new update. All clear for now, thank you very much. BR Urs

Hi John Mouse macros were a very nice FSUIPC feature for otherwise unreachable functions in the past, but not available any more for MSFS. However, with the new interface capabilities of MSFS, is there a chance to get this functionality back in a near future? This would be really a highlight in the desert of missing MSFS functions ... Thanks for any infos. BR Urs

Hi John I am on final with my homecockpit conversion to MSFS. Actually one problem remains. I would like to synchronise my SW PMDG B737-800 at program start with the HW of my cockpit. Nearly everything is fine, switches are synchronised, but not the axes. So the flaps lever in the sim is only updated at the first move. With FSInterrogate I can see, that axes values are 0 after starting FSUIPC, independent from the real HW position. Is there a way to get the real values, so that the sim can follow these without the need for moving them? Thanks for any infos and best regards Urs

Hi John I have some issue with the "Key Press & Release" command. To select a customer view in MSFS, I use keys ALT-1 and ALT-2 as given in MSFS. To operate these keys from an external program I would like to use WriteFSUIPC($3114,4,4145); // Select Captain camera, ALT+1 WriteFSUIPC($3110,4,1070); // Push & Release key and WriteFSUIPC($3114,4,4146); // Select Copis camera, ALT+2 WriteFSUIPC($3110,4,1070); // Push & Release key Unfortunately this doesn't work reliable. Sometimes the command is recognised, sometimes not. Could this be a timing problem? Perhaps MSFS does not read the press command before it disappears by the release command. Can this time be influenced somewhere, i.e. make the time between press and release longer? By the way, as a workaround, when I separate press and release commands by using 1071 and 1072, it's ok. Thanks for info, all the best for the new year and best regards Urs

Hi John Ok, understood. And in fact, it works this way 😊. So I am confident, that I can adapt my script accordingly. Many thanks for your patience and best regards Urs Edit: Just saw your second answer. Thank you also for your testing. All fine now.

Hi John Thank you so much for these infos. I can understand the mechanism much better now. For testing I use two buttons again, defined as follows (3 and 4 only for comparison): [Buttons] PollInterval=25 ButtonRepeat=20,10 1=PB,4,C65604,0 -{THROTTLE_CUT}- 2=RB,5,C65602,0 -{THROTTLE_DECR}- 3=PB,14,K49,24 -{Key press: lalt+1}- 4=PB,15,K50,24 -{Key press: lalt+2}- 5=PB,18,C78100,4145 -{Custom control: <78100>}- 6=PB,18,C78096,1070 -{Custom control: <78096>}- 7=PB,19,C78100,4146 -{Custom control: <78100>}- 8=PB,19,C78096,1070 -{Custom control: <78096>}- I tried with all three parameter pairs you proposed, but there is no reaction at all. Is my test arrangement faulty? Urs

Hi John Sorry to get back to you, but I am still in trouble. I tried a lot but without success. The only thing I get working is the control via buttons. The working button definitions in the .ini file are: 1=PB,14,K49,24 -{Key press: lalt+1}- 2=PB,15,K50,24 -{Key press: lalt+2}- When I look to the log-file I can see some actions, somehow cryptic: 1485500 Button changed: bRef=0, Joy=1 (B), Btn=14, Pressed 1485500 [Buttons] 10=PB,14,K49,24 1485500 SendKeyToFS(00010031=[lalt+1], KEYDOWN) ctr=0 1485516 Sending WM_KEYDOWN, Key=164 (LAlt) (Scan code 56), Ctr=4 1485531 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=3 1485547 Ignoring EV_KEYDOWN received as was sent to FS: 0x31 (1) 1485547 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=2 1485578 Sending WM_KEYUP, Key=164 (LAlt) (Scan code 56), Ctr=1 1485625 Button changed: bRef=0, Joy=1 (B), Btn=14, Released 1485625 [Buttons] 10=PB,14,K49,24 1486609 Button changed: bRef=0, Joy=1 (B), Btn=15, Pressed 1486609 [Buttons] 11=PB,15,K50,24 1486609 SendKeyToFS(00010032=[lalt+2], KEYDOWN) ctr=0 1486625 Sending WM_KEYDOWN, Key=164 (LAlt) (Scan code 56), Ctr=4 1486641 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=3 1486641 Ignoring EV_KEYDOWN received as was sent to FS: 0x32 (2) 1486656 Sending WM_KEYUP, Key=50 (Scan code 3), Ctr=2 1486672 Sending WM_KEYUP, Key=164 (LAlt) (Scan code 56), Ctr=1 1486734 Button changed: bRef=0, Joy=1 (B), Btn=15, Released 1486734 [Buttons] 11=PB,15,K50,24 But I still don't know how to achieve the same result by filling offsets with controls and parameters. I tried to fill x3200, x3204 and x3208 with 1070, 49 and 24 in different ways. Then I tried to write 1070 to x3110, but I didn't know how the parameters 49 and 24 should be filled in x3114. Please, please let me know the correct procedure. Many thanks in advance. Best regards Urs Meyer

Thank you very, very much for this incredibly fast and promising answer. Now I know where I have to look at. I feel good (again)... Have a nice evening and best regards Urs

Hi John I have nearly finished installing MSFS to my B737-800 homepit. Many issues could be solved thanks to FSUIPC7 😊. But since a day I am squeezing my brain to solve the following problem. Perhaps I don't see the wood for the trees any more... Tried to find the solution in the normal and the advanced user guide without success. I want to switch the visual between two modes: Captain and 1.Off view. They are defined with MSFS customer views on ALT-1 and ALT-2 and then selected via the keyboard. Then I have programmed two buttons in FSUIPC to send these key presses, all working fine. But now I should trigger the view selection from an external program, that can write to FSUIPC offsets. But how can I link two free offsets in FSUIPC, that will trigger the key commands at changes? Your help would be most welcome. Best regards Urs Meyer

Hi John Thank you very much for answering. I think I should be more precise. Some values are output from PMDG resp. Simconnect as Float32 resp. Float64. When you need the values for calculations and/or displays, it is very difficult to convert them to integers in a program like SC-Pascal. The following vars are concerned in the PMDG B737: Offset Mapping for PMDG 737-700 6474 4 FLT32 FUEL_FuelTempNeedle 64E8 4 FLT32 APU_EGTNeedle 6548 8 FLT32 x 2 AIR_DuctPress[2] PSI 6550 8 FLT32 x 2 AIR_DuctPressNeedle[2] Value - PSI 6558 4 FLT32 AIR_CabinAltNeedle Value - ft 655C 4 FLT32 AIR_CabinDPNeedle Value - PSI 6560 4 FLT32 AIR_CabinVSNeedle Value - ft/min 6564 4 FLT32 AIR_CabinValveNeedle Value - 0(closed) .. 1(open) 65C4 4 FLT32 MCP_IASMach Mach if < 10.0 660C 8 FLT32 x 2 MAIN_TEFlapsNeedle[2] 661C 4 FLT32 MAIN_BrakePressNeedle General offsets 02CC 8 FLT64 WISKEY COMPASS INDICATION Other interesting values as the AC/DC voltages and currents (see Ramons question) With the FSInterrogate tool I can see the correct values in the FLT32 resp. FLT64 columns. It would be very helpful, if these values could be duplicated to new offsets as integers. Let's take the Wiskey Compass as an exemple: Take the FLT64 from 02CC (0 to 359,xxxx..°)and multiply it by 100 => 0 to 35999 This value is then output with a 2-byte integer. The user can divide it by 100 (possible with every program) and display 0.00 to 359.99 . Similar with Flaps controlling servos. Just an idea, possibly helping also other users of FSUIPC. Thank you very much for attention and best regards Urs