Alpin-Flier

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

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

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

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

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

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

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

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

Hi Pete Fantastic! You have already solved my problem. It works perfect, without any complex stuff. Thank you again and best regards Urs

Hi Pete I have read a lot of documentation about FSUIPC. I tried also to understand LUA, LINDA, IPC a.s.o. and my brain got quite hot. To be honest, I lost a little bit the overview. Perhaps you can bring me on the right way again. For MIP, MCP, EFIS and some pedestal of my PMDG737NGX homecockpit I want to use input/output boards from Simio Electronics. They use scpascal, offering a read from and a write to FSUIPC offsets. Reading data from PMDG should be no problem, because this works with FSUIPC offsets. But as I know writing to these offsets is of no use with PMDG. So I have to use customer control numbers to access PMDG events. But how can I transform a write to an FSUIPC offset from scpascal into a write to a PMDG customer control, with a parameter included? Is it necessary to go via LUA and/or LINDA, that I don't understand up to now? Or should I use dummy offsets in FSUIPC, that can be written from scpascal and then converted somehow to customer control events? It would be very helpful to get a practical exemple. Let me change the position of the AutobrakeSelector with its six positions. #define THIRD_PARTY_EVENT_ID_MIN 0x00011000 // equals to 69632 #define EVT_MPM_AUTOBRAKE_SELECTOR (THIRD_PARTY_EVENT_ID_MIN + 460) Therefore the customer control number is 70092, the parameter from 0 to 5. Thanks in advance for for your most estimated help. Urs

Hi Pete Thank you very much for your detailed answer. I think I have understood how to proceed. Have a nice weekend Urs

Hello Peter I'm a retired electronic engineer, living in Switzerland, since about 50 years a flight enthusiast, but new to this forum. Let me first thank you for all the fantastic work you do for the flight simmer community. Since about one year I'm building up a B737NG cockpit with material from Opencockpits (pedestal, FMCs, clocks), Hispapanels (MIP,MCP) and Cockpit-for-you (throttle). Everything fits nice mechanically but now I came to the software trying to understand what's going on there. I installed the new PMDG737NGX on Prepar3d_V2.4 working very well on my PC Win7 system. I went through a lot of descriptions of FSUIPC and made many tests to see if I understand it well. The external systems are IOPC-Server from Opencockpits and sc-pascal7 from Hispapanels. Sc-pascal7 can connect to IOPC-server, but also to FSUIPC directly. Some simple reading of data works nice on both systems. But writing seems to be quite a tricky thing (or impossible?). My actual task is to control the dimming of six DUs by the lower MIP potentiometers. As first test, I connected one axis (speedbrake) to the brightness control of the captains outer DU, using the axis assignment window of FSUIPC. After some struggles I succeeded. Important to know: when I put in the offset value 69961, it is stored wrong in the fsuipc.ini and I must correct it there (x01001149 to x00011149 resp. 69961). The axis must be put to raw to get values from 0 to 255 being transfered. Then I can control the brightness with the speedbrake lever. The fsuipc console window shows FS controls as soon as the lever is moved: FS control sent: Ctrl=69961, Param=117 Now to the external connection with sc-pascal7. At connection setup I can define offset parameters, that will be used. Then, on switch or pot or encoder changes sc-pascal will send a write to FSUIPC. This part works fine because I see the writes arriving in the console window of FSUIPC. But it is different from the FS control above: WRITE0[2028] 11149, 1 bytes: AD Values are ok, because they are in hex, but nothing happens to the DU dimming. Obviously I don't understand the relation between "WRITE0..." and "FS control sent...". Thank you very much for any help. Urs