Jump to content
The simFlight Network Forums

Scotfleiger

Members
  • Posts

    392
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Scotfleiger

  1. I don't think there is any sequence I can determine. I am restarting repeatedly to run a test for Elev Trim. The latest handle for the Vri is 35. I think you can ignore what actual value is returned for the handle. It is the event.vriread that is not being triggered. Is the another read command I could use?
  2. No. These were individual examples of the handle obtained. The handle 5 seems to be the most prominent. The latest run gave a handle of 23. My debug code logs do list the handle used. The same handle is used consistently for output and for the event.vriread within a session.
  3. Device Number is my name for Handle obtained when I connect to the device. The handle comes from the com.open function and used to write to the VRi device. Don't over do it. Users can wait.
  4. The event.vriread is not triggering the defined LUA function in LINDA. The instruction line is: event.vriread(dev, "MCPcontrols"). The docs state: event.vriread(handle, "functionname") Your processing function: function-name(handle, "data") This is an extension to the com library, described earlier, specifically for use with VRInsight devices. It executes the named function whenever an apparently valid VRInsight input arrives on the identified VRInsight device. The latter is identified by the "handle" to the device returned by a com.open call made previously. The "data" provided to the function will be the 1 to 8 character string supplied by the device. Please see the document "Lua plugins for VRInsight devices". There is a difference in the documentation as to whether the function should be event.vriread or event.VRIread. LUA is case sensitive. I have tried both formats without success.
  5. The event.VRIread is being actioned without error but I don't know if it is working. I am not seeing any received data and there is no logging. The VRi device number in testing 5.101h is for example 5 and 59. I can control the display output. I will delve deeper.
  6. We only added it due to the OOM problems with P3Dv3.4. I agree there is no point in having it now.
  7. The offset 024C is defined returning available FS memory. With FSUIPC5 5.101h this value is permanently zero (0). Is this correct?
  8. Hi Pete Well done. FSUIPC5 5.101h now connects to the VRi Combo Panel and display data is displayed correctly as far as I can see. However (as always) non of the button/knob inputs are being read from the serial interface. I will need to delve deeper to see if I can detect any input data. The input data is normally format in a 5-6 byte string defining the button/knob and operation (push/rotate) eg. BARO+. FSUIPC5.log - VRI connection and display I will look further at the Elev Trim offset issue. I may not be able to do much for the next few days as I have some 'real life' work to do. I have been enjoying myself too much this week.
  9. Yes please as VRI is more important to my users. You should have my email.
  10. OK. Thank you. I will follow your suggestions on the offset 0BC0.
  11. Hi Pete The VRI bug in 5.101g appears to be an incorrect COM handle (dev) set with the com.open (port, speed, handshake) call (port=3, speed=115200, handshake=0). Previously, the handle is a large number (i.e. 1887698620356) but today I am seeing a handle of 1 (one) and the LUA Error Bad VRI com handle. There is no way to do LUA exception handling (that I know of) and LINDA crashes at this point. FSUIPC5.log - see last line (98516) The x0BC0 error occurs immediately I try to use offset write with low value of 310 (0x0136) as a 2 byte command. Following the command LINDA stops responding. I can operate the trim wheel in the sim and inject value directly to the offset using the LINDA Tracer tool. I need to do further work. LINDA offsets are set using via the SDK code. Off all the offsets we have been investigating most of the others have been 4 bytes long but 0x0BC0 is 2 bytes: FSUIPC_Write($0BC0, 2, @val, dwResult); FSUIPC_Process(dwResult); FSUIPC5.log - Offset 0BC0 - see last line (136281)
  12. Hi Pete Sorry I had to break off testing. I will do some more to localise the problem. I have seen the 3 SOUND data errors for some time with FSUIPC4 using the Saitek Panel related functions. Until this week I did not realise that related to SimConnect. They occur with the various lights, battery, alternator and fuel pump settings are sent all together. I have not been able to isolate them and they have not caused problems. Ignore for the time being. There is another thread referring to offset 0BC0 errors. I was referring to that. Again I will test further
  13. Hi Pete Thank you for your work on 5.101g. I have not been able to break it with offset writes using LINDA and the FSUIPC5_test.lua plugin I provided. However, The VRi LUA event.vriread(dev, "<function name>") is still failing in LUA and sometimes crashes P3Dv4. Commenting out the command allows LINDA to run but not with the VRi Combo Panel. FSUIPC5.log Doing offset write for Elev Trim (0x0BC0) is locking up LINDA. This was happening with earlier FSUIPC5 version so it could be my issue - fsuipc5.log. I will investigate further but did I hear you mention that others were experiencing similar problems. I summary offsets are working but VRi Serial Interface is still failing.
  14. Hi Jacob Please monitor the LINDA Community forum on AvSim for updates to LINDA. There is a 64-bit-compatible beta for LINDA 3.0.0 under Support but it will be updated when I have test with the FSUIPC5 update. LINDA 2.8.7 will not work with FSUIPC5 and P3Dv4.
  15. All FSUIPC4 or 5 files are located in the \modules folder of your Flt Sim installation (c:\program files\Lockheed Martin\Prepar3d\modules or c:\p4dv4\modules). If you wish copy your old FSUIPC4 configuration files from FSX or P3Dv3 to P3Dv4 you need to locate the fsuipc4.ini and any files ending with .MRCO or .LUA. Copy and paste these into the \modules where FSUIPC5 has been installed. You will need to rename the file fsuipc4.ini to fsuipc5.ini to use your old settings. I strongly recommend you read the FSUIPC5 User Guide (located in \modules\FSUIPC Documents\) fully before asking such basic questions on the forum. They are written for that very purpose.
  16. You only need to copy MCRO and LUA file from your old Flt Sim \modules folder if they exist. As you are asking the question and are only using FSUIP5 for your devices I assume you have none.
  17. Well done Pete. I check again tomorrow.
  18. Reproduction of a fault is the essential starting point. I was having the same problem over the weekend with I first reported I could not connect to FSUIPC5 on my working system as P3Dv4 won't run on my development system (no DirectX11). Good luck.
  19. Strange. With Win10 and no LINDA running or present the error exception appears in less than a minute. FSUIPC5.log
  20. The axis movements were me moving the yoke out of view so I could see various switches on the instrument panel. I also probably had my feet on the rudder pedals - my footrests.
  21. Hi Pete That would suggest that is an interaction between FSUIPC5 and LINDA (and other Addons) combined with the offset writes that is causing the problem. I will do a 'bare' installation test. You may like to try my latest beta build 633 (see link). Installation is to drill down to the modules folder and copy the folder contents into your modules folder. I have modified the ipcReady.lua file to start LINDA and the FSUIPC5_test.lua plugin. LINDA 3.0.0 beta build 633 - For testing purposes only.
  22. Hi Pete I ran FSUIPC5 5101e and it found both throttle quadrants. Log linked below. FSUIPC5.log
  23. Hi Pete, sorry I missed your question while working on the test plugin. My axes are 'send direct to FSUIPC calibration'. Also only one of my Saitek Throttle Quadrants is being recognised by FSUIPC5 - today the throttle detected has changed. You may have thought you had fixed this. Unfortunately not.
  24. Hi Pete As promised please find linked below the test plugin you wanted. Unzip and place the 2 files (ipcready.lua and fsuipc5_test.lua) in the \modules folder. The plugin displays a message and an ALT count. Monitoring the AP display you will see the ALT/SPD/HDG/VS/CRS change (as selected) and the buttons flash. The plugin triggers the fault within 20 secs. FSCUIP5_test_plugin
×
×
  • 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.