Alpin-Flier

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

Hi John I have the same problem as Ramon. SC-Pascal has a very limited function range and is not able by itself to convert Float64 to e.g. a 2-Byte word. In my case it is the heading at $02D0,4 I need it for my WetCompass. I read only the upper nibbles of this value to simplify conversion, but it is still very complicate. Is there a chance, that all Float values can be converted to reasonable Bytes/Words to be used in further script calculations resp. displays? Best regards Urs

Let me confirm it also here: John did a very good (and fast) job, thanks a lot. Since the 7.3.12 published today, PMDG events work perfectly, writing parameters to the known PMDG offsets like in the good old P3D times 😎. Existing scripts may be used again. Forget the "Rotorbrake" botch. John, you made my day. Urs

Hi John This is just to confirm to you, that the new FSUIPC7 v7.3.12 is working perfectly 😊. Finally I can send again events with parameters to the well known PMDG offsets. This allows me to reuse most of my scripts made for P3D. I think (and hope), we can forget now the strange and confusing "Rotorbrake" story 😁 Thank you very, very much for your effective and fast service. All the best Urs

Hi John Thank you very much for your answer. I have solved the problem with your most estimated help. You are right, controls (of course!) 1001 and 1002 cannot trigger the vPilot. First I did not realise that, because I triggered these controls with a yoke button and made then vPilot synchronise to the buttonpress. It worked, but not due to the controls, but to the button itself remembered by vPilot! So I created a new script snippet in SC-Pascal, very simple and working fine (input 59 is my PTT input): if input=59 then begin // *** PTT WriteFSUIPC($3114,4,84); // parameter "T" WriteFSUIPC($3110,4,1071+value); // push or release "T" end; First the parameter "T" is written. Then the control is sent, depending on the input value (0 or 1), to 1071 resp. 1072. By the way, 1070 does not work, because it holds the PTT active only for about 1 sec., independent from the input return. If we know how, life can be very simple, isn't it? Thank you again for your great help and all the best Urs

Hi John I have a similar problem like Paul. I use vPilot and can trigger its PTT function with any key or button programmed with FSUIPC ("PTT transmit on/off"). But I have an external mixed PTT switch circuitry (in total 8 switches in my B737 cockpit) and read the result with a separate program (SC-Pascal). This program allows me to change any offset in FSUIPC. But I don't know which offset I must change. How must I address the special 1001 and 1002 offsets, when I don't have buttons or keys? Or is it necessary to use a key inbetween? Many thanks for any help. Urs

Hi Pete All clear now, thank you very much. Unfortunately PMDG is not really responsive to such wishes. So I will use a separate value in my script, starting with 0, driven up and down by the trim switch and driving my indicator. Not really a synchronous behaviour therefore, but somehow acceptable. Have a good time. Urs

Hi Pete and John Happy new year to both and thank you so much for the excellent support you give always to the simmer community. I am still working on my homepit (P3D_4.5, B737NGXu from PMDG) to get some errors out. So I found a problem in the Rudder_Trim function. I can control the Rudder_Trim_Knob without problem, but I don't have a feedback for my indicator in the pedestal. Well, I know, that the required output is not available from the PMDG SDK. But I found the following in your "FSUIPC5 Offsets Status", marked with NEW!: 0C02 2 Aileron trim value/control: –16383 to +16383 [NEW!] Ok-SimC ?-SimC 0C04 2 Rudder trim value/control: –16383 to +16383 [NEW!] Ok-SimC ?-SimC I tried 0C04, but it outputs always a 0. Where does this value come from? Is it from SimConnect? If so, is it possible, that NGUx bypasses SimConnect in some way? Any suggestions how to solve this issue? Thank you for any help. Best regards Urs

Hi Jim Both platforms I use to connect my HW to the sim use the same procedure after start: They read HW switch states once after start (sim and FSUIPC already running). Then they send commands to the sim accordingly. If I need a synch later on, I must close the cockpit software (not the sim itself) and start it again. This is e.g. needed after you have loaded a new scenario with different resp. unknown switch settings. Urs

I am not familiar with LUA, but I think to have found the solution with SC-Pascal, one of my platforms for HW coupling. I just add the following code in the main routine: WriteFSUIPC($3114,4,-1); // Synchronisation of Flap levers case ReadFSUIPC($3414,2) of 0:begin WriteFSUIPC($3110,4,76773) end; // set Flaps lever to 0 2559:begin WriteFSUIPC($3110,4,76774) end; // 1 4606:begin WriteFSUIPC($3110,4,76775) end; // 2 6653:begin WriteFSUIPC($3110,4,76776) end; // 5 8700:begin WriteFSUIPC($3110,4,76777) end; // 10 10747:begin WriteFSUIPC($3110,4,76778) end; // 15 12794:begin WriteFSUIPC($3110,4,76779) end; // 25 14841:begin WriteFSUIPC($3110,4,76780) end; // 30 16383:begin WriteFSUIPC($3110,4,76781) end; // 40 end; That is quite compact code and works fine up to now with my NGXu. If you would like additional explanation, let me know. Well, I think more of doing a completely new flight the next day, not to continue. Otherwise I save the actual situation as scenario and load it again. But this is sometimes quite critical, I agree. Anyway, now my sim follows the HW and that's what I wanted 🙂. Sometimes it is good to describe a problem, then the solution comes by ... Urs

Hi Thomas and Pete Thank you very much for answers. Of course, defining a state with all things off and levers at idle does help. But I would really prefer a synch. I am sometimes a lazy pilot leaving the plane in some undefined state 😄. Just think about a long distance flight and then your wife is calling for dinner... at least my sim experience. All the switches and displays controlled by my scripts (SIOC, SC-Pascal) take over HW states and do a synch after start. But levers drive the sim bypassing the scripts. However I think, with a script snippet I can read the HW lever positions and send lever commands to the sim after start. Only after that lever changes send commands directly. What do you think about? Anyway, I will try this and tell you the result. Urs

Hi everybody I need advice concerning synchronisation between homecockpit HW and P3D. My flap lever controls the P3D / PMDG_737_NGXu via FSUIPC. When I start the sim, its flap lever is not synchronised to the HW lever, until I move the latter. I know, this is due to the fact, that only changes trigger commands. But this is not really useful and even dangerous. Is there a workaround with FSUIPC to force the synch at simulator start? Thanks for any advice. Urs

This is an error since longtime and was never corrected. The (dim) remark should be next to Open. During transit the lamp is highligted in the VC. By the way, I asked PMDG also to make the anti-ice-switches working the same way. But there was no success, unfortunately. I had to do it with script timers. Is's not really a problem. Thank you very much for the final version. I will install it tomorrow. Have a nice weekend Urs

I did now an extensive test on most NGXu vars from offset 6420 upwards. I had also a special look to multiposition switches and displays. Gentlemen, everything is working fine, offsets are at their correct positions, values represented correct. There is a small correction in your offset mapping file: offset 6469 is not a boolean, but 0 for off, 1 for dimmed and 2 for highlighted. So I think you can go on with the corrected version. I will be happy to use it as first. It was an honour to assist you 🙂. All the best Urs