Pete Dowson

Is this whilst in the Calibration? Sorry, i think the general axis logging only takes place when in normal flight mode. I really at this stage only wanted to see the value of each axis being sent to FS as you moved the two levers together from idle to max using the Sync line as it is at present. Then maybe a separate log with the same but with the Sync line removed or "commented out" (precede it with a ;) so i can see the good or bad effects of the sync that you say you get. There is a debugging option i can get you to enable which logs a lot more stuff -- including raw input values -- even whilst in Calibration, but that log will be hige. You'd need to ZIP it up and either attach it or send it to me by Email. However, I'm unlikely to be able to do much more for you now until Thursday, so if you can manage okay without the sync line for now, maybe we can continue then? I note that earlier you said this: In view of such a small discrepancy I do wonder why you want to use sync. Real throttle levers in real aircraft are rarely level for the same thrust setting. They vary for several reasons -- age, connection streccting/linkage differences, minor difference in hydraulic pressures in the different systems, age and wear and performance of engines, fuel flow differences, etc. Take a look at some real life cockpit videos. Pete

The numbers in the sync are proportions (128 = 100%). I am puzzled at the 23 not changing, but that is why I need to see the logged axis values. And with the log i can see if I can reproduce the problem here. Pete

Well, what is the point of moving only one throttle? You are effectively telling FSUIPC to equate your meiddle Thr2 position to the idl Throttle1 position. "Sync" is trying to match the output values for both of the two Throttles. What do you expect it to do if you move only one?! And what are the values actually arriving IN and going OUT? Where are you reading the 12/23 etc, only in the INI? Are you reloading the INI file all the time? To view the IN values all the time, in real time, go to FSUIPC Logging tab, enable Axis logging, and Console Log, then run P3d in Windowed mode so you can see both it and the Log output both at the same time. Really, without knowing how your throttle inputs are behaving I can't comment, apart from my comment that it is really nonsense to move only one throttle and trying to sync multiple positions on Thr2 with just one postion on Thr1. Pete

When you manage to get the DLL.XML to show me (t to attach it I think, it won't format well otherwise), I certainly need to see it as it appears, from the above entry in the Install log, to be corrupt. Didn't you get a message from the Installer asking you to delete the DLL.XML file and re-running the Installer? Pete

There certainly is an "AppData"! You have Windows Explorer set to hide files. Go to folder options and change that option! Pete

Well, FSUIPC is only recording the values your throttle is providing each time you press the sync button. I don't know why it needs to be different in the A320 compared to the 777 in any case, though I know Airbus systems are completely different to Boeing. Just unassigning in P3D, like FSX before it, is precarious. If P3D ever decides the controls are newly connected (maybe a USB hiccough, or a temporary disconnection beforehand) it will automatically re-assign. This then causes conflicts and they puzzle users as they can't understand why it is suddenly different. That is why I always tell users to disable the controllers completely, not simply try to de-assign (which then isn't necessary in any case). Pete

And what changed in the last two days? Do the assignments work in other aircraft, eg default ones? Please find the P3D modules folder, files FSUIPC5.LOG and FSUIPC5.INI, and either paste their contents in a messge or attach them for me to look at. Pete

Does this work in the PMDG aircraft. most previous users have told me that they get serious diverse movements of the throttles if they calibrate in FSUIPC, never mind use sync, I thought PMDg read the axis values at a higher priority level than where FSUIPC feeds them to the sim engine, so the two diverging values cause conflict. Generally, for PMDG aircraft (and some other advanced ones, possibly including the FSL ones), advise only assigning to FS controls "Axis throttleN set" and not calibrating. But maybe that only applies to the way PMDG did things on P3Dv3, not P3Dv4. Sounds like FSL do what PMDG used to do. Is the throttle control erratic with FSUIPC calibration in any case? Also, since the sync points are merely relating values coming in from your axes to each other, and scaling the changing values to achieve those points via the Throttle 1 calibration, the sync should be the same for ALL aircraft. After all, they ALL have Full thrust at +16383 and the Idle in the same place (0 or -16384 depending on which FS control method you set FSUIPC to use), so the throttle syncing should be identical too. BTW the INI file tells me you are still on 5.103, a very early version of FSUIPC5. Could you update, please? The current version is 5.122. It also shows me that you have a default calibration section and just the one Profile, for the A320. The default one is therefore being used for the 777, and that still has "UseAxiscontrolsForNRZ=No". It is rather different therefore. And ... you have no yoke (aileron . elevator) assigned. Or rudder or toe brakes. Do you fly on keyboard only, or are you still using assignments in P3D? If you assign ANY joystick button or axis in FSUIPC you MUST disable controllers completely in P3D or you will get conflicts occurring. There's a check box in the P3D control assignments "other" section where you can disable controllers. You need to do that, or not use FSUIPC for assignment. You can still calibrate in FSUIPC even without assignment. Pete

Yes, the install shows everything worked fine. Was that after re-downloading the Installer? But I need to see your DLL.XML file, and i need you to check the Modules folder for an FSUIPC5.LOG, and if there is one, show it to me. The DLL.XML file will be here: C:\Users\Paul\AppData\Roaming\Lockheed Martin\Prepar3D v4\ and the FSUIPC5.LOG may or may not be here: C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\ Pete

I havewn't hacked into the Window.DLL code in P3D4. Both of those functions work, BUT they both use the one SimConnect text window facility. In other words the "owndisplay" one does the same as the display one. I'm using the ipc.display option redularly, and it works fine. In the latest version of FSUIPC5 95.122) I've made the "advdisplay" toggle hotkey work again, too. That switches the display on or off, and does it via a flag, so once off it stays off till switched on It also operates on the single line displays shown via offset 3380. But that switch is certainly "on" by default. Here is my main ipc.display using Lua plug-in: -- Update the display at 500 msec intervals (see event at end) function mytimer(time) fr = ipc.readUW(0x0274) if fr ~= 0 then fr = 32768/fr end fr = math.floor((fr * 10) + 0.5)/10 traff = ipc.readUD(0x025C) fstime = string.format("%02d:%02d:%02d", ipc.readUB(0x0238), ipc.readUB(0x0239), ipc.readUB(0x023A)) ipc.display("Frame Rate " .. fr .. " fps\nTraffic " .. traff .. "\nFS Time " .. fstime) end -- Adjust timing to taste: 500 = 1/2 second event.timer(500, "mytimer") I'm not really sure what you mean by this: There hasn't really been much "past" for P3D4 yet. Nevertheless I suggest you advise your friend to keep his FSUIPC5 up to date. Pete

Oh, of course. Why is that, BTW? My Arduino is definitely connected via a serial port. There's no provsion for events on sockets, so you'd need to read the incoming message using a function called by event.timer. I notice your infinite loop has no ipc.sleep() in it with a time, so you are trying to get it excuted as fast as possible, though i assume it may "sleep" in the receive function -- or can that return immediately with no data? Just select a suitable time ot "poll" the socket reception. Something which relates to how often you expect something to arrive. Pete

And not even specific to event.offset, but to a misunderstanding aof what infonite loops mean! ;-) Pete

And how is that called? You should only ask for each specific event the once. They get registered, then the function gets called every time the offset or whatever changes. Do NOT keep calling event facilities for the same events unless you cancel them first (as per documentation). Of course! Events can only trigger when your program exits! Your infinite while loop never exits. Events might pile up, but can never execute becuse the thread you have is continually sitting in your loop, piling more and more events up! You should only use events or loops. To do it the way you are doing it, with a loop, you'd just use the ipc.read... functions for the offsets to see if they'd changed since last time you looked. Generally event requests are the last thing you do before the end of the program. You thread will simply then be suspended until one of those eventstriggers. So, make up your mind which method to use. You can use events for your Arduino inputs as well, either via event.com, or a simply timer (event.timer) to call the arduino reading function at reguilar intervals. If you look at the provided exampls you'll see they are all of one tpe or the other. Most of the looping ones would be better re-written using events, but they pre-date the event system which was added later. Pete

What PFC console is this? Does it use my PFC modules 9PFCFSX.DLL or PFCcom64.DLL for serial port, PFCHid.DLL or PFCHid64.dll for USB HID devices? Or is it a true joystick device, recognised as such by Windows and by FSX or P3D? How is it assigned then, if you can't use FSUIPC? Sorry, but you aren't providing much information. Really? Not one I know then. Mine all use plain potentiometers and most certainly need calibration. Pete

No, not exactly. The DLL.XML file is now good. But, yes, the ACL error is still present. No INI file is made until you run P3D in any case of course. There are no settings to save, after all. Did you run P3D after the Install? If so and there's no "AddOns" menu containing FSUIPC, then either it is not loading or it is getting stuck somewhere. In the latter case there should be an FSUIPC5.LOG file. In the former case something is stopping the loading. For that I'd need to see a SimConnect log file. Please see the thread in the FAQ subforum about how to do that. It might also be useful to try running P3D4 "as administrator" also, in case the ACL errors you are getting affect it's accesses. Pete

That simple? Thanks! Pete

64-bit sockets all working? Have you any details of how to use the 64 bit download so i can document them for others? Have you tested with more obviously changing offsets, such as the time seconds value in offset 023A (a "UB"). Which "simple offset"? If you only tested with PMDG offsets, have you enabled these in the PMDG file? Where does this get the parameters offset and oft from? Is it only called the once, and if so how -- from another event? Er ... what error was that? "SB" is a valid data type. Types are not checked against offsets -- any offset can be read as anything. So i'm puzzled -- just setting it to "SB" will NOT generate an error. You can call it a FLT32 or even as ASCIIZ. It isn't checked. Nothing knows what types any offsets are. They are what you treat them as. Pete

What "final popup"? That error is strange. According to Microsoft references it means: ERROR_NONE_MAPPED 1332 (0x534) No mapping between account names and security IDs was done. As noted in another thread here, there's a bug introduced by a recent Win10 update, and that's in the "ACL" functions, so I wonder if this is another symptom (the other thread one was that the Installer crashed) This line, however: is most likely just notifying you. This, from earlier: Checking if there's already a version of FSUIPC5 installed as: D:\P3Dv4\Modules\FSUIPC5.DLL ... No previous valid version found. Prepar3D v4 Modules Modules folder already exists. Okay -- installed FSUIPC5 into "D:\P3Dv4\Modules\FSUIPC5.DLL" shows that you HAVE run the Installer before. did you delete the contents of the Modules folder before re-running the Installer? The DLL.XML is corrupt. There are other threads about this. Please re-download the Installer package and run the installer again. It was a corrupt install upload. You might need to clear your cache first (F5 I think). And don't forget to run the Installer "as administrator" (a right-click option). Pete

TO ALL POSTERS IN THESE THREADS: Looks like the uploaded Installer was corrupted somehow. I downloaded it myself and got the same result. I've re-uploaded it now, so please clear your cache (F5 I think0 and re-download it. I've added a DLL.XML file corruption check, which, if you run it now without first deleting your old corrupted DLL.XML, will prompt you to delete it and re-run the installer. Pete

TO ALL POSTERS IN THESE THREADS: Looks like the uploaded Installer was corrupted somehow. I downloaded it myself and got the same result. I've re-uploaded it now, so please clear your cache (F5 I think) and re-download it. I've added a DLL.XML file corruption check, which, if you run it now without first deleting your old corrupted DLL.XML, will prompt you to delete it and re-run the installer. Pete

The first format is fine. Your replacement is trying to tell P3D to load a program called "modules", which is a folder not a program! I need to see the FSUIPC5.LOG file with the KEY properly present. FSUIPC5 is obviously being loaded okay or else whether the KEY file is there or not would make no difference. NOTE that your posts are essentially on a different subject to the main subject of this thread, which was a corrupt installer problem. Pete

TO ALL POSTERS IN THESE THREADS: Looks like the uploaded Installer was corrupted somehow. I downloaded it myself and got the same result. I've re-uploaded it now, so please clear your cache (F5 I think0 and re-download it. I've added a DLL.XML file corruption check, which, if you run it now without first deleting your old corrupted DLL.XML, will prompt you to delete it and re-run the installer. Pete

Please see the last message I just posted in the other thread. There's a replacement DLL.XML file there you can try. Something is going on with the recent Windows updates causing the pre-defined file I save to be corrupted. I'm doing some tests here to see what i can find ... Pete

Interestingly, the DLL.XML is corrupted in exactly the same way as the one posted earlier by Alexander. I'll see if I can work out how that can happen. Meanwhile, I've made a replacement which you can save to replace that one and try. (Just right-click on the text below and select Save As. Replace the DLL.XML you sent me. Pete <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>FSUIPC 5</Name> <Disabled>False</Disabled> <Path>\Modules\FSUIPC5.DLL</Path> </Launch.Addon> </SimBase.Document>

Because you spelled the read function name correctly. Compare it to your write one. you have too many capital letters. Luke did suggest you check! You could also compare it to the one in the manual. "nil" is "no value" (basic Lua) , meaning in this case, as it says, writeLVar (a nil value) cannot be executed (because it doesn't exist). No, the code fails. That is why an error is reported. And the error report is quite specific, it tells you exactly what is wrong Unfortunately, like C/C++ (but unlike some languages), Lua is very case sensitive. I have tried to include some cases of different capitalisations, but i couldn't add them all without making the lookup tables very long! Pete