Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Scotfleiger

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Scotland, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi John Those users with the VRi Combo problem who have got back to me confirm that the special build 515i provides a workable solution to their power spike issue. I recommend that the VRIDisableCMDRST switch be incorporated into the baseline. Thank you for your help.
  2. Hi John Thank you for the latest 5.15i. It works as expected with the expected VRI commands being sent (lines 265-672) and now reads all inputs from the panel. I will report back when my users have had a chance to test it. Many thanks. FSUIPC5.log
  3. Hi John The VRI Combo 2 panel normally receives a CMDRST to initialise the display. Testing using other tools (VRSIM.exe and an app I have been working on) have shown that for several users the reset and flashing of the lights is causing the disconnect of the comport. The panel does not respond to inputs or output button/knob inputs until it is connected using CMDCON. With 515h and 515i no CMDCON is logged (see FSUIPC5-515i-CMDRST-Yes.log). When everything is working, we see CMDRST (to be disabled) followed by CMDCON (up to 5 times). If the CMDCON is accepted, FSUIPC normally sends CMDFUN and CMDVER to get the panel type and firmware version (see FSUIPC5-515i-CMDRST-No.log lines 54657-54985). I agree that the panel PSU may be a cause. All the issues have been reported by new purchasers of the VRI Combo 2 panel. I still think it is related to Win10 updates but I cannot determine a common factor. Many thanks Andrew FSUIPC5-515i-CMDRST-Yes.log FSUIPC5-515i-CMDRST-No.log
  4. Thank you John for confirming the typo. The 5.15h build with the ability to prevent the CMDRST command has worked in isolating the power spike to the VRI Combo panels. However, the changes you did are stopping the subsequent CMDCON (sent up to 5 times) and the CMDFUN and CMDVER being sent. It is only the CMDRST command that needs to be switched off. Also FSUIPC may no longer be reading data from the comport when the Could you check your code and advise? UPDATE: with the switch set to yes, no inputs from the comport and panel are being received.
  5. Hi John/Pete The requested test build 5.150h is helping but the fsuipc5.ini switch keeps resetting itself negating its use. I have myself inserted the switch and set it only to find it he setting became reversed. Should it be =true or =yes?
  6. Thank you very much John. I will report back.
  7. Hi Pete Thanks for the comments. I have been in contact with FDTI Support regarding the drivers for their USB-serial com port. They confirm that dated 16 Aug 2017 is the correct. Further testing by users confirms that it is the extra power draw by the panel lights that is causing a power 'spike' that is disconnecting the comport. The lights are triggered by the reset command (CMDRST sent on FSUIPC initial connection and subsequently by LINDA) or manually. Is is possible to ask for a test build of FSUIPC5 that removes the CMDRST - just has Open Port and CMDCON to connect? Andrew
  8. Hi Pete Just to update you. Turning on the additional VRI logging has revealed more evidence of the problem. The log shows FSUIPC trying to connect to the VRI Combo panel. The comport is opened and a reset command (CMDRST) sent. The users report the panel flashing as expected. FSUIPC then tries to connect using CMDCON. This is failing and the command is sent a further 4 times in an attempt to gain a connection. This should be followed by a CMDFUN command which returns the panel type. This confirmation does not appear in the log. Users also report that pressing the panel lamp button causes the USB/Serial Port connection to interrupt. The lamp also flashes when the panel is reset. Although the panels are powered by a DC transformer, it appears that the additional power draw of the lights is causing the disconnection. Once disconnected FSUIPC does not try to reestablish a connection. The Flt Sim must be restarted. This has worked fine for me and many others. I suspect that the problem may lie with a recent update to Win10 USB power management. I will investigate further. FSUIPC5.log
  9. Hi Pete Thanks for the reply. Other users with the problem have been using 5.15 so I’m not sure that is the problem. By Device ID I mean the handle returned when you first connect to a comport (I can’t remember the actual command) this is then used for all read and write to the port. I will update you if I find a solution.
  10. Hi Pete I have had a number of reports from users that their VRInsight Combo MCP panels are failing to connect to FSUIPC and LINDA. I have been unable to find a common cause and have been unable to reproduce the problem on my own system. There is a possibility that the problem may be linked with a Win10 update (power management) or a change made to FSUIPC5 5.14-5.15. My system is fully up-to-date and I am using v5.15 without any issues. When FSUIPC connects to the VRI Panel using the comport defined in FSUIPC5.ini [VRInsight] block, it reports "VRI port 1 "com5" opened". This should be acknowledged by an entry identifying the panel model connected "VRI MCP2 ("MCP2 Boeing") detected on port com5". This is the information (CMDMCP2B) returned from the panel with the command CMDFUN. See attached FSUIPC5-VRIConnection.log line 344 = BAD and FSUIPC5-VRIGood.log lines 281 and 60500. The VRInsight software VRISIM.exe can be used to test this. In the reported cases, there is no panel model reported by FSUIPC but the Device ID is returned . LINDA uses the Device ID as confirmation that the panel has been successfully connected. However, commands to the panel (CMDCON and CMDFUN) do not work and the panel is unresponsive. Have you made any changes to the VRI logic? Any suggestions? FSUIPC5-VRIConnection.log FSUIPC5-VRIGood.log
  11. Scotfleiger

    LUA UTF-8 Encoding

    Thank you Pete. I would not encourage a rebuild for this issue. The error is only triggered on a Win10 Chinese system when a "beta" UTF-8 button is ticked. The lua file being loaded (via the require command) is identical to my own copy and both are reported to be encoded in UTF-8 format (using Textwangler on my Mac). I can't explain why an English Win10 system should work fine and the Chinese one not. This is the only report of this problem and I don't intend taking it further at this time.
  12. Hi Pete Is there a way of getting the FSUIPC embedded LUA to work in UTF-8 encoding? A Chinese LINDA user is experiencing errors when his system reads a LUA file on his system with UTF-8 set. When a UTF-8 .lua file is loaded he gets this error: [E] *** LUA Error: error loading module 'linda-cfg/system/config-sys' from file 'D:\Prepar3D v4\modules\linda-cfg/system/config-sys.lua':D:\Prepar3D v4\modules\linda-cfg/system/config-sys.lua:1: unexpected symbol near '�' I have had similar issues and have had to remove the additional bytes generated by UTF-8 using code.
  13. Many thanks Pete. I have fed this back to the user.
  14. Hi Pete Thank you for the feedback. Attached is a copy of the wxstationlist.bin as requested. Note: The wxstationlist.bin is in Prepar3d Folder under Weather\ and not located in the Appdata\Roaming\Prepar3d V4\ Andrew wxstationlist.bin

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.