Jump to content
The simFlight Network Forums

Scotfleiger

Members
 View Profile  See their activity

  • Posts

    392

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Everything posted by Scotfleiger

  1. Scotfleiger
    Hi Pete Yes, the Throttle Arm offset x0810 triggered the fault and all the repeats occur when any other button is pressed and the associated offset write to. I have my throttle, prop and mixture and rudder axes assigned but not calibrated in FSUIPC5. I am about to test the plugin and with advise shortly.
  2. Scotfleiger
    Hi Pete, running LINDA 3.0.0 would only be useful if you have the Saitek Multi-Panel. It is the functions/defined switches/buttons on this panel and associated offsets that are causing the problem. I have just tried 5101e (you posted above) and have managed to break it, but not as bad as before on 0x0810 broken. Interestingly, it is only the offset or offsets that once broken, will keep reporting Exception 20 DATA ERROR when any offset is set there after. The linked was run without your debug lines: FSUIPC5.log I will look at providing you with a LUA plug-in to drive the offset writes.
  3. Scotfleiger
    Believe it or not I have never written a LUA plug-in. I work mainly with the Delphi Pascal code, Günter does the LUA.
  4. Scotfleiger
    I have been tidying my code to ensure writes only occur when a button is pushed. The Offset Writes are occurring only as I operate a button/knob and shows in the log as an offset command and interpreted as a control event. This works fine until, as you picked up, the log starts showing SimWrites and the Exception 20 Data Errors. It is happening independent of the timer events. I can not explain what may be going wrong. I am using the correct offset writes (address and length) and I am unable to trigger the fault with P3Dv3.4 and FSUIPC4. fsuipc5.log8
  5. Scotfleiger
    I ran the test with the params your gave with a modified test build of LINDA (differs from original logs). I see a large number of Exception 20s before LINDA was up and running. The changes I have been trying delayed the triggering of the fault at the end of the log. FSUIPC5.log
  6. Scotfleiger
    You spotted my typo. The still an issue over time with writing to these offer even when the rate is reduced.
  7. Scotfleiger
    I have isolated the trigger for the reported DATA ERROR report. I was updating the AP values one-after-the-other every 50ms. The offsets are AP 07BC, HDG 07C4, NAV 07DC, SPD 07DC, ALT 07D0, VS 07EC, APR 0800 & REV 0804. Commenting out the offsets writes eliminated the problem. I will look at reducing the number/frequency of calls and report back.
  8. Scotfleiger
    Thanks Pete. I would not like to lose the ability to write data to offsets. I thought I was write data too fast but in the test I sent I was turning the knob slowly one step at a time. Data is only written when the value changes. Would the speed of reading an offset cause the problem? The code is called at 20Hz (50ms).
  9. Scotfleiger
    I have been able to reproduce the fault condition. The fault condition can only be cleared by closing and reopening P3Dv4. Using offset 0x07CC (2 bytes) to change the Heading while monitoring the Offset value using LINDA Tracer, I was able to trigger the Exception 20 DATA ERROR after exactly 19 offset writes. The Pascal function used: function setHDGvalue(hdg: integer): boolean; var val: array [0 .. 1] of byte; dwResult: DWORD; v: single; begin v := round(hdg * 65536 / 360); val[1] := trunc(v / 256); val[0] := round(v - (val[1] * 256)); FSUIPC_Write($07CC, 2, @val, dwResult); FSUIPC_Process(dwResult); result := true; end; // setHDGvalue You can see the Offset values changing if you search for "[INIT] Ready to go, Captain!" in these log files. FSUIPC5.log2 FSUIPC5/log3 Sorry to add to you to-do list.
  10. Scotfleiger
    Yes. The buttons as programmed control the AP fine until the error occurs. The fault appears to be triggered when I turn the knob to change the alt/hdg/crs but not all the time. Perhaps I am calling too quickly. I am testing further to find the trigger.
  11. Scotfleiger
    Hi Pete Thank you for the steer on SimConnect SDK error reporting. I am using the normal offsets (writing 4 bytes with 1 or 0 in first byte) to control the default P3Dv4 B58 autopilot using the Saitek Multi Panel. These calls control the aircraft AP until the Exception 20 occurs. After that the AP fails to work and the sequence of 8 Data Error repeat on each button press/offset call. I have tested the same operations with P3Dv3.4, FSUIPC4 4.966 and my latest LINDA build and the errors do not occur. I will investigate what I am sending and report further.
  12. Scotfleiger
    Hi Pete I now have LINDA working with FSUIPC4 and FSUIPC5 as a 32-bit application. I take back my previous comment on timing issues. My problem lay with the renaming of the FSUIPC5 file (fsuipc5.ini, .log and .dll) as these are checked and/or accessed during LINDA operation. The SDK files are essential unchanged. I am getting a Exception 20 "DATA ERROR" writing or reading to some AP offsets (see linked log). All these offset are 4 bytes long (0804, 0810, 07C8, 07C4, 07DC, 07D0, 07EC & 0800). It is high highly a programming error on my part, but what is an Exception 20 "DATA ERROR"? Finally, my user community would like to see the VRi serial handling added back as soon as convenient. LINDA was written specifically to handle the VRi Combo MCP panels before it was expanded into a general HID device handler. Thank you for all your work in generating FSUIPC5. FSUIPC5.log
  13. Scotfleiger
    Pete I just got the SDK routines to communicate with FSUIPC5 late last night. I will spend time today investigating why. It appears that the interface is taking much longer to initially connect than previously. Unfortunately my development system runs on my Mac/Win10 emulator and my P3Dv4 on my Win10 PC so I can't use the debug tools. I will update you later.
  14. Scotfleiger
    As you rightly stated 32-bit apps will work fine. However, when I could not get LINDA to talk to FSUIPC5 due to the timing differences I did experiment (and stretched my knowledge) with a 64-bit build. I will send you the revised FPUser code when I have a working solution.
  15. Scotfleiger
    Hi Pete After a weekend of fighting with 32-bit and 64-bit pointer to allow LINDA to connect to and communicate with FSUIPC5 5.10, the light is beginning to appear at the end of the tunnel. There appears to be a timing difference between the SDK/Delphi FPUser.pas FSUIPC_Open() function with FSX and P3Dv3.4 (using FSUIPC4) compared to P3Dv4 and FSUIPC5. Using the demo form supplied in the FSUIPC SDK I can now access FSUIPC offsets (sim version, FSUIPC version and time) for P3Dv4/FSUIPC5 with a 32-bit LINDA application. Once I determine how to overcome the timing issues, I will let you know. For your ToDo list to update the Offsets PDF. The $3308 offset value for P3Dv4 is 12. P3Dv3.4 is 10. Do you know what happened to 11?
  16. Scotfleiger
    I have double checked and I concur. P3Dv4 is picking up both of my Throttle Quadrants, but FSUIPC5 is not.
  17. Scotfleiger
    I suggest that you also check P3Dv4 Controls. My second throttle (Saitek Throttle Quadrant) is not listed there to. Is it P3Dv4 or FSUIPC5 that is missing the second throttle device.
  18. Scotfleiger
    Just have a little patience.
  19. Scotfleiger
    Thank you Pete. If it is not necessary I would prefer to leave LINDA in 32-bit. I won't be able to test it until I can register my copy of FSUIPC5 and get the full functionality. Could you email me a test registration? You should have my email.
  20. Scotfleiger
    Hi Pete You will know that LINDA is built around FSUIPC4 and I have been doing some compile tests in 64-bit. The only issues/compile errors are in the code and data structures used to interface with FSUIPC. The main issue I have is with the DWORD usage - it does not appear to copy across to 64-bit in Delphi Pascal. 64-bit key types of concern are: Type FS6IPC_READSTATEDATA_HDR = packed record dwId : dword; dwOffset : dword; nBytes : dword; pDest : pointer; end; FS6IPC_WRITESTATEDATA_HDR = packed record dwId : dword; dwOffset : dword; nBytes : dword; end; Are there are changes to the FSUIPC5 external program interface data structure? LINDA will also need the full licenced version of FSUIPC5 once the ordering system is up and running.
  21. Scotfleiger
    I can confirm that the pop up message that fsuipc4.ini is in use and to Retry is a produced by LINDA. It occasionally when LINDA and FSUIPC4 are starting up. Please post any similar issues on the LINDA support Forum.
  22. Scotfleiger
    The DLL.XML had AS16 loading after FSUIPC4. I reordered them to place FSUIPC4 last but got the AS16 message: Simulator Module Configured - If you sim is already running you must restart it so that the module will load correctly. Afterwards, the AS16 entry was again placed after FSUIPC4. P3D still crashed even if I closed AS16 manually before P3D. I have the following DLLs running through DLL.XML: orbx object flow_p3d.dll, Aerosoft As-FlightRecorder.dll, VAInterface.dll, PMDG_HUD_interface.dll, PMDG_Interface.dll and RAASPR.dll.
  23. Scotfleiger
    Hi Pete I have been in contact with the P3D team. They point out that P3Dv3.4 is compiled using .NET framework v4.6 not v4.0.30319 as reported by Event Viewer. I have tracked down the LINDA problem to something in the loading of the LINDA libraries that is triggering the crash of P3D. I am debugging further. I found that AS16 for P3D started alone using FSUIPC4.ini [Programs] also triggers the crash. Therefore is not just LINDA that is the cause. I will report progress.
  24. Scotfleiger
    Hi Pete, Thanks for the reply. For your information, LINDA comprises 2 elements: the Linda.lua handles the majority of the configuration and device handling and Linda.exe provides the UI for device assignment programming, handles the VRI devices and communicates with FSUIPC4. There are no LUA errors being reported in the Event Viewer. The first fault indication is the .NET error on closing P3D and LINDA does not use this framework. I will delve further.
  25. Scotfleiger
    Hi Pete The issue appears to be associated with the running of Linda.lua. If I place ipcready.lua and Linda.lua in a temporary folder and remove the [LUAFILES] entries, I can run P3D v3.4.9 and auto start Linda.exe and as16.exe. On closing P3D, both programs shutdown correctly about 10-15 secs later. However, when ipcready.lua and Linda.lua are restored to the /modules folder, P3D crashes on exit. The crash sequence as reported by Event Viewer is .NET runtime error, followed by an application error in ntldll.dll and then APPCRASH for prepar3d.exe. I was seeing P3D v3.3 crashing on occasions but always got an on-screen crash report. I am not seeing this with P3D v3.4. LINDA is distributed with and uses LUA5.1. Could this the cause?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.