Scotfleiger

Further information. The same issue affects P3Dv.5 running with FSUIPC6 6.0.1. The fsuipc6.logs (attached) show that all processes are being closed but P3D background task remains running. Only by ending the hanging task am I able to get LINDA (my supported app) to run correctly (ie. interacting with FSUIPC6) on next P3D start. EDIT: One further indication that FSUIPC6 is still running is that I was unable to rename the fsuipc6.log files until I closed the hanging background task. FSUIPC6 P3Dv5.log FSUIPC6 P3Dv4_5.log

I have been experiencing problems running FSUIPC6 6.0.1 with P3Dv5. On exiting P3Dv5 a background task of size 323KB remains running. It is labeled variously as Prepar3d, Prepar3d Scenario Startup and Lockhead Martin Prepar3D v5. This is causing issues running P3Dv5/FSUIPC6 subsequently. The background task has to stopped manually in Task Manager to restore correct operation. I used the P3Dv5 options to disable FSUIPC6. The problem does not occur and all P3D tasks stop on exiting. I conclude that the hanging background task relates to FSUIPC6 not closing properly.

I am aware that LINDA 3.1.x will not work with FSUIPC6 due to changes in file location and naming. This is being addressed as reported on the LINDA Support Forum. It is not an issue that can be answered here. I ask for some patience as some extensive changes will be required. LINDA Support/Developer

Pete The Exception 25 errors only appear when a Aerosoft Airbus A3XX Pro series aircraft is being loaded. Once loaded in P3D the errors no longer appear. The Aerosoft CRJ does not and I will need to check other aircraft. As stated by aua668 it has no effect on operations - there is no action required. I am using 5.153.

Thank you Peter. I am also using P3Dv4.5, Aerosoft A320 Pro and, obviously, LINDA. I am seeing similar Exception 25 errors from 2 other of my users.

What debug setting causes multiple Exception 25 "ILLEGAL_OPERATION to be logged in FSUIPC5.LOG? 118375 Exception 25 "ILLEGAL_OPERATION", Ref 305, Index param -1 on read AddData for "BLEED AIR SOURCE CONTROL" 118375 Exception 25 "ILLEGAL_OPERATION", Ref 306, Index param -1 on read AddData for "APU GENERATOR SWITCH" 118406 Exception 25 "ILLEGAL_OPERATION", Ref 319, Index param -1 on read AddData for "GENERAL ENG FAILED:1" 118406 Exception 25 "ILLEGAL_OPERATION", Ref 320, Index param -1 on read AddData for "GENERAL ENG FAILED:2" 118438 Exception 25 "ILLEGAL_OPERATION", Ref 333, Index param -1 on read AddData for "FUEL TANK LEFT MAIN LEVEL" 118438 Exception 25 "ILLEGAL_OPERATION", Ref 334, Index param -1 on read AddData for "FUEL TANK LEFT MAIN CAPACITY"

Thank you the size clarification. This has solved the issue I was having.

One more question. Is the a size/length limit for the .MCRO filename or the macro tags?

Sorry John. Will send files later.

Thanks Pete. I have checked for the correct file and macro names. For example, with the same macro in 2 different files, I changed the ipc.macro call to refer to each file. One works the other doesn't.

I have been working with mouse macros with FSUIPC 5.152. It appears that only one .MCRO file can be used using LUA ipc.macro("test: button1"). Any reference to another .MCRO file is ignored (ie. ipc.macro("other: button2")). Thisappears wrong as why would be able to refer to other macro files. It also appears that .MCRO file(s) are only loaded when FSUIPC is restarted with P3D. Is there a way of forcing a .MCRO reload without restarting P3D.

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.

Noted

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

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

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.

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?

Thank you very much John. I will report back.

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 2.12.28.0 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

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

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.

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

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.

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.

Many thanks Pete. I have fed this back to the user.