Pete Dowson

Do you mean -4096? If so, that sounds like a throttle assignment. The maximum reverse for a throttle is -4096 (25% power). Proper calibration in FSUIPC. For all axis controls EXCEPT throttles, the target of the calibration is to get you to -16384 to +16383 no matter what the input from your device. Apart from the proper positioning of the centre, that is all it does. That's its target! Pete

Interesting. but you'd think that would just stop FSUIPC4 from being loaded, not P3D itself. Was there any crash or error shown or recorded when you tried to start P3D? There was a similar thing discovered a long while back, with FSX. Same registry key, everything. The installer was changed to delete any entries found there which mentioned FSUIPC at all. If it does this it logs it. I've looked at the code and it should have done that in your case? Maybe that is why re-running the Installer after a P3D crash on exit fixes the loading P3D problems! YES!!! That MUST be the explanation. I'd clean forgotten about that Installer change. Thank you thank you. This explains a lot!!! Pete

It's on the unlisted device 0, which may be why!? Is anything on devices 0 and 1 working? Cowl fgalps and those 18 button assignments? Pete

3ABC is only used if something writes to it. But it does nothing unless assigned. In your case it is only assigned to Rudder, nothing else. Your ONLY rudder trim assignment is to device 0 which for some reason is not known to the INI file (it doesn't appear in the JoyNames section, which is extremely odd indeed) Incidentally I got it wrong in my long earlier message where I said: 2=0Z,R1,D,28,0,0,0 -{ DIRECT: Rudder Trim }- 3=2X,R1,D,21,0,0,0 -{ DIRECT: ElevatorTrim }- Your joystick devices are very few indeed: [JoyNames] AutoAssignLetters=No 2=Saitek Pro Flight Cessna Trim Wheel 2.GUID={CFC64FF0-6E1F-11E5-8005-444553540000} So the rudder trim is on your Cessna trim wheel It is obviously the elevator trim on your Cessna trim wheel! The rudder trim is on device 0. I'd like to know why the JoyNames section of the INI file doesn't list your devices 0 and 1. I assume they are working okay? The details for the JoyNames section are from the Registry. Could they be missing there? Can you check what devices are seen by the JoyIDs utility, please? (See the "Fixing joystick connections not seen by FSUIPC" thread in the FAQ subforum). Also, I could get more information on why, maybe, with more logging. Try adding: Debug=Please LogExtras=x200000 to the [general] section of the INI file, please, then show me the log. Thanks. Pete

Your choice. If you are going to calibrate then Direct is more efficient. The other way involves sending the control to FS first, then FSUIPC intercepts it for calibration just before it is applied. So for every change the first is one message to FS, the second involves two messages to and one message back. However, some add-on aircraft (notably Aerosoft Airbus and PMDG aircraft) don't like some axes being sent direct because they intercept them in the same way as FSUIPC does. Pete

3BAC is one of the "free" offsets which can be assigned to whatever you like inside FSUIPC's axis assignments. The allocations shown in that list are just those automatically assigned for the PFC driver when my PFCFSX.DLL is loaded. Otherwise you can use any of the 15 available for any axis, but they need assigning in FSUIPC or they will do nothing at all. I don't know why whatever it is you are using is writing to 3BAC. But if it's assigned to rudder trim, it will be rudder trim. These are your only assignments to the PFC axes offsets: 4=16X,R2,D,1,0,0,0,R3 -{ DIRECT: Aileron }-5=16Y,R2,D,2,0,0,0,R4 -{ DIRECT: Elevator }-6=16R,R1,D,3,0,0,0,R3 -{ DIRECT: Rudder }- So you have assigned 3BAC to the rudder, NOT the trim. Your rudder trim, like your elevator trim, is assigned to a normal joystick device: 2=0Z,R1,D,28,0,0,0 -{ DIRECT: Rudder Trim }-3=2X,R1,D,21,0,0,0 -{ DIRECT: ElevatorTrim }- Your joystick devices are very few indeed: [JoyNames]AutoAssignLetters=No2=Saitek Pro Flight Cessna Trim Wheel2.GUID={CFC64FF0-6E1F-11E5-8005-444553540000} So the rudder trim is on your Cessna trim wheel. Your other buttons and axes are assigned to devices 0 and 1, which don't appear to be connected according to the list!!! However: Not in the message I responded to -- it was a later message which i've only just seen. In that log there are three devices listed: 156 ---------------------- Joystick Device Scan ----------------------- 156 Product= Pro Flight Cessna Trim Wheel 156 Manufacturer= Saitek 156 Vendor=06A3, Product=0BD4 (Version 1.6) 156 Serial Number= RD001533 156 Product= USBAXES-PLUS 156 Manufacturer= Opencockpits 156 Vendor=0000, Product=00CC (Version 0.0) 156 Serial Number= 156 Product= 156 Manufacturer= 156 Vendor=0000, Product=0004 (Version 0.0) 156 Serial Number= so why only one in the INI? Is that an out of date INI? Er, you are assigning to FS controls. They are not offsets. In the offsets which can be READ to see the state of the controls you would be able to read those. Check the offsets list. The 3BAC area are just inputs, not outputs. You are just using control offsets, the ex-PFC ones, for the main three flight controls. I don't know why. The two trims and the cowflps controls are sent to FSUIPC calibration as normal controls, just as if you'd assigned in other ways, even in FS. Anyway, the log with the IPC write enabled is no use because it doesn't have the ERROR trap. The last few entries are innocuous. I don't think it is FSUIPC crashing FS. But whatever software you are running which is writing to FSUIPC offsets it putting quite a load on your system, with up to 30 or so writes every second. I just hope they are batched an in one transfer, not all separate calls. Pete

Was there an error report immediately after, like the previous one, i.e like this? 1370609 ***ERROR C0000005 at 6E2878A8 ExWriteStateData(Offset=0C04, Size=2) 1370609 *** Access violation trying to read address 00000008 1370609 *** EAX 00000000 EBX 00000001 ECX 42B3C048 EDX 00000000 EDI 0F43A5A8 ESI 227AEDF8 If not, was that last WRITEex the last line in the log? Not sure of the point of the partial log you also appended? Pete

There's nothing to "learn"! It's far easier that creating macro files and assigning them as you've already done. You only need to put the Display Vals.lua file into your FS Modules folder, go to the Keys or Button assignments tab in FS, press the "reload" button if your FS was running when you copied the file over (so it recognises it), then assign a key or button to "Lua display vals" in the drop down as you have for the macros. Then when you use that key or button the logging will start and it will display changes to LVars on screen too. If you want to stop it you'd need another key or button assigned to LuaKill display Vals, and use that. I now have a version of FSUIPC which can optionally log the L:Var aactions when you use those macros so we can see what happens. As I said, email me and I'll send it. Pete .

I can't do much with the others, but the last, the FSUIPC4 Log is useful. Your program or driver is evidently in error and trying to write to somewhere it shouldn't. Enable ipc Write logging in FSUIPC's Logging tab, which will show what you/it is trying to do. Pete

Sounds like SimConnect is overloaded. But I need to see the FSUIPC4.log file from such a session. Pete

Those offsets cause direct writes into P3D. To calibrate values sent to offsets you should use those in the range 3BA8-3BC4. What about the Windows crash data? That's more relevant! Please show me that. Only that if it is on you'll probably get conflicts in any case. Always use one or the otther. But you should never be able to cause a crash. Pete

If it occurs with P3D (then it is NOT the same thing. There will have been a crash and I'd need to see the Windows crash details and the FSUIPC4.LOG file, if one is produced. If it is the trust bug, there's no log made because FSUIPC never runs. If it is a crash then there will be crash details in Windows event viewer and maybe a log from FSUIPC4. Note there can be other, registry or FSX.CFG [Trust] section reasons for the trust bug window appearing. There are threads about the registry fix in the FAQ subforum, and you can delete any FSUIPC entries in the FSX.CFG [Trust section. Pete

It's a SimConnect trust bug, which was fixed in P3D but not FSX. It only happens on some systems, and sometimes fixes itself after one try (say "yes" for it to continue and run), but sometimes takes several attempts. Once is runs okay once it stays okay -- until, at least, the next update. Then it may or may not happen again. Microsoft knew about this but couldn't fix it -- but it was a lot worse before the SP2/Accel update. They said it was a Windows problem, and the Windows folks said it was an FSX problem. So, stalemate. Pete

Yes That makes no sense at all. Two more things to try: 1. Remove both T lines, and change AutoAssignLetters back to "Yes". Runthe sim, and it will probably assign letter A and that should show as A in the assignments tab. If so, change both A's to T's and see if that fixes it. If not: 2. Go to the Windows Device Manager, in the Control Panel, and sselecting the throttle and fully uninstalling it there. Both of them if it lists two. Then re-boot the system. Failing that I think it'll be a matter of searching the registry for any mention of "Rhino Throttle" and deleting the entries for it. Pete

That sounds exactly like the occasional SimConnect "trust" bug as covered by the FAQ subforum thread. It does seem to take a few retries sometimes (according to reports. I've never reproduced it on any on many PC systems). Luckily all that nonsense was removed in P3D. So, what is changing after those few revolutions? Certainly nothing in FSUIPC. I assume this, for COM1 for instance, is the total of what is being done in the Log above? If those L:Vars get written then presumably you should see an immediate effect? It might be a good idea to have the L:Vars displayed on screen in real time as they chhange, so we can see. You can do that by running the Lua plug-in "display vals" -- it's in the example plug-ins Zip file in your FSUIPC Documents folder. It may be that it is they aircraft which is responding incorrectly or late. Though I don't uinderstand why it would be different between different versions of FSUIPC as none of the code in any area to do with button interpretation has been changed, not for many many years. And the log certainly shows it responding to buttons okay. The L:Var requests are just that, requests via the FS PANELS.DLL interface. I'd add more logging if there was anywhere to add it, but all it does is call "get_named_variable" followed by "set_named_variable" -- and it does the same sequence no matter whether it's a Set, Toggle, Setbits, ClrBits, Inc, Dec, or Cyclic Inc. I could put a log message at the very point of sending those two commands to FS, but I'm not convinced that would help. Let me know what you think. If you want to try that send me an email on petedowson@btconnect.com. Pete

And what happens if you tell Windows to go ahead and let FSUIPC load? That message box is often only a warning because of a previous crash, not one in this session. Off to bed now. Pete

Not really. I'm only moving things around to see what changes. And I don't think the changes are relevant to your problems. And anyway, I'm up to 4.961b now. Pete

The crash on Exit you get may be the same as those crashes on exit which seem to somehow give rise to the crash on a subsequent startup, which is what we are primarily trying to solve, being the much more major problem. I would hope that one of the interim test versions I have now produced would get rid of your problem on exit, but I have no way of knowing. If you want to tr, see the pinned thread at the top of the Forum and send me an email. I'm having to try to get some sleep now, so there will be a delay I'm afraid. Pete

I can understand a corrupt DLL.XML file causing FSUIPC not to be loaded -- it would have no menu entry then -- but I still don't understand how a loaded FSUIPC doesn't respond when its menu entry is selected. In the log earlier where there was no menu, this sequence: 77000 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 80656 ### MENU: EV_MENU [15] received: dwMenuEvent=15, fInScanJoy=0, fInOptions=0 80922 ### MENU: Error: failed to receive DLGMODE notification! Aborting menu! shows that you clicked on the selection twice, presumably because it was slow to respond. the "=15 in the second is the 'memory' of the first, showing my code that it was already trying to get into dialog mode. the notification of the menu selection worked, but then SimConnect wouldn't go into dialog mode. The correct sequence is: 778305 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 778305 ### MENU: ST_DLGMODE received, stt->dwInteger=1, dwMenuEvent=15 778305 ### MENU: ST_DLGMODE: fInScanJoy=0, fInOptions=0 Then, on exit from the options screen: 784857 ### MENU: PropertySheet call returned 1 784981 ### MENU: ST_DLGMODE: ending dialog mode I also get this 'error', later: 785668 ### MENU: Error: failed to receive DLGMODE notification! Aborting menu! That's just a safety measure, to stop the "MenuEvent" memory I mentioned preventing further attempts to enter dialog mode. The last time I saw anything like this it was down to another add-on somehow preventing dialog mode from being used. I'm afraifd I don't remember which add-on. This must be about 6 or 7 years ago, at least! Pete

No, sorry, they were there. It was me. There's so many crash problems with P3D at present that I'm overloaded and rushing. Sorry. I also haven't slept properly for several days. So your problem isn't the GUID matching. I had assumed that because it was the mst recent change and I'm not aware of any other which could affect assignments. So, going back to the original problem reported, I need to get to the bottom of it. Is this the entire assignment list for device A or had you abbreviated it for me? [Buttons] PollInterval=25 ButtonRepeat=20,10 1=RA,0,C65588,0 -{BRAKES}- 2=RA,11,CM1:16,0 -{Macro 01 A2A 180: L:Com1FreqInnerKnob inc}- 3=RA,10,CM1:17,0 -{Macro 01 A2A 180: L:Com1FreqInnerKnob dec}- Does the brake assignment work? Does FSUIPC see joystick A properly -- does it respond to it in the Assignment tabs? Can you enable Button and Key logging in the FSUIPC Logging tab, please and use the above assigments and show me the results? Thanks, Pete

They are the standard flight control inputs, yes. They result in direct writes to SimConnect variables unless "WrIteAxesDirect=No" is set in the INI file. In the latter case they invoke controls ("events"). With rudder trim I assume you mean the rudder trim control. There is a rudder trim input offset, 0C04 which is direct and not affected by the INI file setting. Why such a mix? Why use offsets for control in any case? They are separate, no conflicts. A stackhash error where, in your program? Pete

Sorry, what have other addons got to do with it. Your report makes no mention of any problem other that the fact that the FSUIPC options screen won't appear. FSUIPC cannot affect any other add-on, except those which interface to it, of course. If that's happening you have a serious corrupted installation. Pete

Yes, and it showed no problems. Can you tell me EXACTLY what other add-ons or add-ins are running? Have you tried eliminating any? As a first step I need some more logging. Something seems to be stopping the message from SimConnect telling FSUIPC that the menu option has been clicked. Add Debug=Yes LogExtras=x8000 This just adds some logging to the menu process. Do that and then try to get the FSUIPC options showing. Do it just twice, with a minute or two between, then show me the log. I'll be back in a few hours. Pete

Well, there's nothing I can change in FSUIPC which will fix anything if it isn't even running. But see my previous message and drop me an email if you want to try some changed versions, which I'm making to try to solve the P3D problems. Pete

And is the crash data always the same, as above? Pete