Jump to content
The simFlight Network Forums

Scotfleiger

Members
 View Profile  See their activity

  • Posts

    392

  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Scotfleiger

  1. Scotfleiger
    Hi Pete Thank you for all your hard and long hours getting FSUIPC5 5.102 out. I have just installed this formal release and note that there are a number of PDFs in FSUIPC Documents with zero length. These include: History, Plugins and PDMG 737 & 777 offsets.
  2. Scotfleiger
    Pete I have decided not to attempt to close any device (VRI/HID) using com.close. I will leave it FSUIPC5 to manage. It works for LINDA. I do not have time this week to do any more work as I am far, far behind with my other work. Do not let me stop you formally releasing 1.102. Andrew
  3. Scotfleiger
    I am hitting problems trying to close the HID handles. P3Dv4 is locking up. This is probably down to the different way 5.101p now manages the VRI and HID handles. The 1023 handles limit is only ever a problem for us developers who need to restart regularly to test new LUA code. So it is not a problem. The LUA error is my coding error and can be ignored. I am happy for 5.102 to be released.
  4. Scotfleiger
    Morning Pete The management of the VRI handle is fixed in 5.101p. After multiple restart of the 'original' LUA code the same handle (5) is assigned by the com.open() and used by event.vriread(). LINDA retains full control of the VRI MCP panel. FSUIPC5.log - original LUA code - same handle used. When I repeat the test with the 'modified' LUA code which closes the VRI handle before restarting with com.close() (see line [COMM] Closing VRI port Dev=), FSUIPC5 allocates a new handle to the VRI device. LINDA correctly uses the new handle and LINDA retains full control of the VRI MCP panel. FSUIPC5.log - with VRI com closed before restart The same behaviour occurs in both cases with the HID device handles. New handles are assigned to each device on restart leading to the long list of handles. This does not affect LINDA operations. My code in both cases does not attend to close the HID com handles. Should I will look further at closing the HID handles on my side? Thank you for burning the late night candle.
  5. Scotfleiger
    Good news and thanks for all the effort you are putting in. I'm afraid I must finish for today.
  6. Scotfleiger
    Hi Pete I took your comments on using com.close with the handle for the VRI MCP panel (5 as allocated originally). It would appear that if it is closed then the same handle will be reused for the VRI device on restarting. With this the event.vriread(handle) is correctly assigned and working. The various HID com handles still increase as I have not disposed of them. The above situation will not occur when the ipcReady is called to restart the LUA code without any killLUA calls. Therefore, the handles still need to managed within FSUIPC5. FSUIPC5.log
  7. Scotfleiger
    LauKill commands are sent to FSUIPC for the 2 running LINDA LUA processes when the user forces a restart. I am not sure what happens when ipcReady.lua restarts the LINDA LUA processes by calling LINDA.LUA which in turn loads INIT.LUA.
  8. Scotfleiger
    There are no close statements and never have been. LINDA in most cases is restarted when ipcReady.lua is triggered by the Flt Sim/FSUIPC. I will have a look at the Restart sequence.
  9. Scotfleiger
    Hi Pete I did wonder about the 0 handles. This is repeated on each restart. Only the last HID is identified as the Saitek Switch Panel. Of the 7 HID devices I have attached, 2 are disabled and not used within LUA. That would account for the 5 allocated handles plus the sixth VRI device.
  10. Scotfleiger
    Correct debug fsuipc5.log with added logging data.
  11. Scotfleiger
    The log does not have the correct logging. The .ini changes did not save.
  12. Scotfleiger
    Hi Pete Thank you for your attention to the reported VRI event problem. I have run the test of starting P3Dv4 and LINDA 3.0.0 beta together using fsuipc5.dll 1.101n. Initially I had full VRI Combo MCP functionality using handle=5. Of note is that I had the same set up running continuously for over 3 hours this morning without any issues. On restarting the LUA code several times, I got the same handle sequence on each restart - 5, 11, 17, 23, 29. With each the event.vriread failed to use the new handle but the com.write had no problems. I have 6 HID devices attached to my system. see post below for correct FSUIPC5.log.
  13. Scotfleiger
    Thank you Thomas. Setting Run as Admin has solved the problem.
  14. Scotfleiger
    I am getting an error starting Active Sky for P3Dv4 beta using the [Programs] block in FSUIPC5.ini. It is reporting error 740 even through 2 other programs are starting correctly. I have double checked the path including cutting and pasting from the program's shortcut properties. The ASforP3Dv4 program can be started manually via the shortcut. FSUIPC5 FSUIPC5.log Screenshot of shortcut properties
  15. Scotfleiger
    You need to monitor the page for the latest formal and test builds. You need the 5.101m test DLL to address the missing throttle.
  16. Scotfleiger
    Are you using the latest FSUIPC5.DLL 5.101m test build?
  17. Scotfleiger
    We can wait. I'm away 19-22 Jun anyway.
  18. Scotfleiger
    If you search for "Dev=" you will see the ConnectMCP (com.open), InitMCP (com.write) and event started (event.vriread) lines in the log. The first 3 will have the Dev=5, the second 3 Dev=11, etc. I can also confirm that the com.write calls using the revised handle correctly write data to the VRI MCP. I double check with P3Dv3 and FSUIPC4 and found handle to start at 5 but then on restart uses a varying/random large integer. Having spent most of today isolating the problem, I have a repeatable workaround of restarting P3Dv4/FSUIPC5. There is no rush.
  19. Scotfleiger
    Hi Pete I have managed to break it again. Using FSUIPC5 5.101j or k I am able to connect to (dev = com.open(port, speed, handshake) and set up to the VRI read event (event.VRIread(dev, function)) when P3Dv4 initially starts up. The handle (my variable dev) is invariably 5. However, if I restart the LUA code and reconnect to the VRI serial channel the event.VRIread does not appear to accept the new handle and I am not receiving data from the device. The handle is initially 5 and increments by 6 on each call to com.open() producing the sequence 5, 11, 17, 23, etc. It would appear that the new event.VRIread is not correctly registering the revised handle. As shown before the com.open and com.write calls do recognise the revised handle. FSUIPC5.log - 2 restarts FSUIPC5.log - 2 restarts FSUIPC5.log - 3 restarts - handle 5,11,17,23,etc Note: The problem is also present in your latest 5.101m test release.
  20. Scotfleiger
    That's perfect.I will update my beta release later today to work with 5.101j. Thank you for all the hard work. I must get back to the day job tomorrow. I have changed my method and no longer need to use offset 0BC0 for Elev Trim. I am using the FSX control instead.
  21. Scotfleiger
    Hi Pete I am delighted to confirm that 5.101j works with the VRi Combo MCP panel as expected. Well done. I will do some more testing but I think you have a workable release for LINDA users.
  22. Scotfleiger
    Great news Pete
  23. Scotfleiger
    Improving my test code has greatly improved handling of VRI MCP but needs further work (should I need to use it).
  24. Scotfleiger
    Morning Pete Sorry for the confusion. It was the middle of the night. The lag I referred to was due to only processing one input with each 10Hz cycle. I would need to process all waiting inputs in one cycle. The event driven operation means that all inputs are processed sequentially when they occur. The lag is down to my limited test code. I am hesitant of driving the slower LUA code any faster to avoid timing errors I hope the information allows you to pinpoint the event.vriread fault.
  25. Scotfleiger
    Hi Pete You know what it is like. Your brain switches on in the middle of the night and you just have to settle the matter. I have created a 10Hz call in LUA to use the com.test(handle) and com.read(handle, 8) functions. I can now read data coming from the VRI Combo MCP panel. If I send the data read to my data handler it is processing it as expected. The handle does change when I restart my code but is working and consistent. FSUIPC5.log - VRI com.test and com.read While I can read the data it lags behind the input. The question therefore remains is why the event.vriread(handle, function) function is not working (still). Back to bed.
×
×
  • 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.