John Dowson Posted May 28 Report Posted May 28 1 hour ago, EisernUnion said: - It stops working at some point within the msfs session .... msfs was running since 07:00 until shortly before i posted here ..... WASM Log stopped at 09:12z .... just silently died I have not heard a report yet of the WASM crashing. You also only showed a prev log for this - there must also have been a current log. And switching back to the beta version confuses things...Anyway, forget this for now as I don't think this is your issue - we can return to this if it happens again. 1 hour ago, EisernUnion said: -Autotune was active and had a value around 320 or sth. DetectToConnectDelayAuto=310 StartUpTuningDoneVersion=1 StartUpTuningActive=Yes DetectToConnectDelay=5 What to do to prevent lua from stop working at some point ??? Auto-tune did run and set quite a high value. It can do this if/when MSFS is updating, or maybe if using a complex aircraft on previous flight. If this is too high, this just means that it will take longer for FSUIPC to connect and be ready. What is happening now, is that auto-tune is running and detecting no issues, so it is reducing the detect-to-connect time by 10 seconds and will run on the next execution. This will repeat until it detects an error or gets to the minimum time set (30seconds). Once it gets an error, it will determine the times needed, set them and then finish. So, it reduces until an error is detected, then increases and finishes. As your current DetectToConnectDelayAuto is set to 300, this could take quite a while. This is why I asked you to set: InitialStallTime=15 DetectToConnectDelayAuto=60 which will most-likely give a connection error (or several), but then the times will be correctly set and the auto-tuning will finish. Looking at your latest logs, it seems that the WAPI was not started. This looks to be a strange timing issue, where the WAPI is not being started as the either the aircraft is still in the parking state or the sim is in a pause state when it is supposed to start. This will be due to the state of the MSFS and the aircraft being loaded at the time FSUIPC7 is starting things up. I need to know the state of a few things before I can correct this, so can you please try once with the attached version, which has additional logging added. Run MSFS with this installed and have FSUIPC7 auto-started. If the aircraft loads but your lua no longer load, try going back to the main menu and then start the flight again. Do they then load? Please show me your FSUIPC7.log from thjs test. Then (if luas still didn't load), exit FSUIPC7 and start it manually - do the luas then load? Please show me the log file from this test. Rename your FSUIPC7.exe (to FSUIPC.exe.7412) and use the attached version for this test: FSUIPC7.exe Then please try changing the settings to: InitialStallTime=20 DetectToConnectDelayAuto=60 StartUpTuningActive=Yes Then run MSFS again to get FSUIPC7 auto-started. Once MSFS arrives at the main menu, wait a short time before loading an aircraft. This should then set the parameters to good values for your system, which will take affect the next time you run MSFS. John
John Dowson Posted May 28 Report Posted May 28 1 hour ago, EisernUnion said: I restarted MSFS.... still nothing... i assume, some session hast not quit ...? Log Files attached But that log file you pasted shows the luas were loaded? 1 hour ago, EisernUnion said: Strange ... another try, started msfs again ... in the fsuipc window under "WASM" the only option was "Disable", all others were greyed out ... i klickt disable, enabled it and instantly lua loaded in .... just a coincidence ? No, not a coincidence. As I said in my previous post, the issue is that the WAPI isn't being started (it was enabled but not running). By disabling it and re-enabling it, it started running. If you can provide me with a log file showing the WAPI not being started (with the additional logging in that version I posted) then I can correct for this. It seems the root cause of this is a change in order of events from MSFS which I need to correct for. Maybe specific to the Fenix - have you tried other aircraft? It would also be useful if you could add logging for the pause state offset 0264 (Log->Offsets) as U8 in hex (with Display to 'Normal Log File' checked).
EisernUnion Posted May 28 Report Posted May 28 Will check this later, happy it runs now .(and flying a short leg)... will come back with the results later this evening... thx !!
Luigi Martinelli Posted May 28 Report Posted May 28 On 5/27/2024 at 12:13 PM, John Dowson said: Then read this post and show me the required files.... THERE IS NO POINT POSTING FOR THE SAME ISSUE IF YOU ARE NOT GOING TO ATTACH FILES SO THAT I CAN INVESTIGATE No - I need to see what your issue is with the latest and ONLY supported version. I can provide the previous version, 7.4.11, if absolutely needed, but I need to see what the issue is with the latest version first, and for this I need to see log and ini files as stated. Here I will file, I hope I haven't misunderstood, I apologize in advance. FSUIPC7.rar
John Dowson Posted May 28 Report Posted May 28 5 minutes ago, Luigi Martinelli said: Here I will file, I hope I haven't misunderstood, I apologize in advance. @Luigi Martinelli You are using a very old version of FSUIPC7, v7.3.20 from April last year. Please update to the latest and only supported version, 7.4.12. John
EisernUnion Posted May 28 Report Posted May 28 Lua silently died just when arrived at the gate and shutdown engines ... instantly no lua is working anymore .... it was still the release version. ... not the one you provided .... its really strange .... instantly on shutdown, at the same time i would say.... the lua logs stopped 20:06, fuuipc.log a moment before 19:59.... shutdown was exactly at 5/28/2024 8:04:52 PM * Engine control 1:cutoff the lua.logs are to big to attach... only the tiny lua file is possible to attach The "addon" -> WASM -> "disable" -> "enable" dont work ... after disabling not possible to enable it (the last few lines in the log ) FNX320_LIGHTS.log FSUIPC_WASM.log FSUIPC7.log
EisernUnion Posted May 28 Report Posted May 28 Here are the files with your testing exe..... included Autostart -> no Lua working & Back to main menu restarted flight -> no lua working will add the last use case "exit fsuipc" and restart manually -> no success .... the wasm at addons is still at "enable" set and not running logs_usecase 1,2.zip usecase 3.zip
John Dowson Posted May 28 Report Posted May 28 32 minutes ago, EisernUnion said: Lua silently died just when arrived at the gate and shutdown engines ... How do you know this? There is nothing in the logs. 33 minutes ago, EisernUnion said: the lua logs stopped 20:06, fuuipc.log a moment before 19:59.... shutdown was exactly at 5/28/2024 8:04:52 PM * Engine control 1:cutoff But the FSUIPC7 did not stop, did it? Did FSUIPC7 hang or was it still running? Please always exit FSUIPC before attaching logs. The logs just show you restarting the WAPI connection twice. This will not restart your luas as FSUIPC thinks they are already running. It is strange that there is no message stating the number of lvars loaded, but there may not be one if not starting luas. I need to see the lua file to make sense of the log, but it looks like it was still running to me. if the thread had crashed, this would have been reported in your FSUIPC7.log file. So I still don't understand why you think the lua has crashed. Also check that you don't have the MSFS option End Flight When Aircraft Shuts Down checked. I prefer to see lua logging in the main FSUIPC7.log file rather than separately as well - it is easier to make sense of things seeing everything in chronological order. I see you have posted more files while I was writing this - I will check them tomorrow. Finishing for the day now. John
EisernUnion Posted May 28 Report Posted May 28 i noticed it because on my streamdeck the gsx options went black .... no more access to gsx... other buttons also stopped working which are reliaing on lua scripts i commented 2 functions out in on of the lua scripts, afterwards it works .... but... whats the reason this error occurs when shuting down engines and not before.... strange i added some logs ... FSUIPC7_prev.log FSUIPC7.log FSUIPC_WASM.log FSUIPC_WASM_prev.log
EisernUnion Posted May 28 Report Posted May 28 So far, finished another flight, engine shutdown and still everything works (still).... maybe i re-enable both of the functions in the lua script and will check if the error occurs again.... but, all 3 scripts were running without issues for "years" until some days before... 😕 Computer ^^ (says no)^^ 🙂
John Dowson Posted May 29 Report Posted May 29 14 hours ago, EisernUnion said: included Autostart -> no Lua working & Back to main menu restarted flight -> no lua working Use case 1,2 shows lua WAS working. What wasn't working was the WAPI so the scripts were failing when trying to access lvars/hvars or execute calculator code. This was bacause the WAPI was disabled (in your ini file). So this behavior is expected. 14 hours ago, EisernUnion said: will add the last use case "exit fsuipc" and restart manually -> no success .... the wasm at addons is still at "enable" set and not running Again, this is because the WAPI has been disabled. Please enable this and do not disable again please (unless instructed) as this is confusing matters. 13 hours ago, EisernUnion said: i noticed it because on my streamdeck the gsx options went black .... no more access to gsx... other buttons also stopped working which are reliaing on lua scripts This doesn't necessarily imply that the lua scripts were not running. They were just not functioning correctly due to the WAPI being disabled. 13 hours ago, EisernUnion said: i commented 2 functions out in on of the lua scripts, afterwards it works .... but... whats the reason this error occurs when shuting down engines and not before.... strange Not sure, but will be something due to no access to the WAPI functions causing the script to mis-behave, 13 hours ago, EisernUnion said: i added some logs ... The prev log shows no access to the WAPI, again because this is disabled. The other log looks good, so you must have enabled the WAPI. However, looks like you attached this when FSUIPC7 was still running or had crashed. Can you please always exit FSUIPC7 before attaching logs. If it did crash, this is more serious and I will need further information. 11 hours ago, EisernUnion said: So far, finished another flight, engine shutdown and still everything works (still).... maybe i re-enable both of the functions in the lua script and will check if the error occurs again.... but, all 3 scripts were running without issues for "years" until some days before... 😕 I think the initial problems were due to using 7.4.12c after installing 7.4.12, which gave incompatibility issues in the WAPI preventing access to lvars/calc. code, etc. Then when you updated back to 7.4.12, the WAPI was disabled. Yes - re-enable those functions. May as well keep using the 7.4.13a version I gave you, with the extra logging, and post your files again if you get issues.
EisernUnion Posted May 29 Report Posted May 29 First thx for your support .... Second: Stopped working again... .... recognized it when i was about to switch off landing lights, TO lights and didnt respond after touchdown ... touchdown was at 20:06:48z ... last entry in wasm log 19:54:41z ... (nothing happend, nothing noticed while on final... just after landing as the buttons not responded anymore) FSUIPC7.log FSUIPC_WASM.log might be nothing, but dirty sounds not so good at all ?!
Ron Attwood Posted May 30 Report Posted May 30 Latest update doesn't recognise/find my Fulcrum yoke. The yoke is recognised in Windows and in MSFS and works. All my buttons and key presses are handled by FSUIPC since...forever. MSFS handles the axis. [JoyNames] 0=Joystick - HOTAS Warthog 0.GUID={D1794640-246D-11E6-8001-444553540000} 1=CH Throttle Quadrant USB 1.GUID={7DCB45F0-282A-11E6-8003-444553540000} 5=MFG Crosswind V2 5.GUID={E6A97680-25B6-11E6-8001-444553540000} 6=Pro Flight TPM System 6.GUID={C8DA6E60-25B7-11E6-8001-444553540000} 7=Pro Flight Cessna Trim Wheel 7.GUID={27DB16B0-2669-11E6-8001-444553540000} A=Joystick - HOTAS Warthog A.GUID={D1794640-246D-11E6-8001-444553540000} B=CH Throttle Quadrant USB B.GUID={7DCB45F0-282A-11E6-8003-444553540000} D=Throttle - HOTAS Warthog D.GUID={921BB790-2520-11E6-8001-444553540000} E=MFG Crosswind V2 E.GUID={E6A97680-25B6-11E6-8001-444553540000} F=Pro Flight TPM System F.GUID={C8DA6E60-25B7-11E6-8001-444553540000} G=Pro Flight Cessna Trim Wheel G.GUID={27DB16B0-2669-11E6-8001-444553540000} 3=Throttle - HOTAS Warthog 3.GUID={921BB790-2520-11E6-8001-444553540000} C=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> (Fulcrum yoke) I've uninstalled/reinstalled a couple of times, no joy. Ouch! Sorry. 😣 Attached log FSUIPC7.log
John Dowson Posted May 30 Report Posted May 30 6 hours ago, Ron Attwood said: Latest update doesn't recognise/find my Fulcrum yoke. The yoke is recognised in Windows and in MSFS and works. All my buttons and key presses are handled by FSUIPC since...forever. You posted in the wrong topic - there is a temporary fix for this issue as well as a patched version available in the following topic: John
EisernUnion Posted May 30 Report Posted May 30 Same as yesterday evening.... as i wanted to turn on landing lights at FL100 stopped working .... wasm debugger flagged it again as "dirty" and is not working anymore. FSUIPC7.log
John Dowson Posted May 30 Report Posted May 30 11 hours ago, EisernUnion said: Second: Stopped working again... .... recognized it when i was about to switch off landing lights, TO lights and didnt respond after touchdown ... touchdown was at 20:06:48z ... last entry in wasm log 19:54:41z ... (nothing happend, nothing noticed while on final... just after landing as the buttons not responded anymore) It looks like the WASM crashed at 21:54:21. I have no idea why, and I will need to be able to reproduce this to fix this issue. These errors are strange: Quote 352750 [ERROR]: Error: CDA with id=48 not found 352750 [ERROR]: Error: CDA with id=49 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found 352750 [ERROR]: Error: CDA with id=0 not found These are probably due to a timing issue. Could you please activate WAPI debug logging (Log->WAPI->Debug) and keep that active for now. As you are also getting a lot of lvar/hvar reloads after initial; connection., could you change the WASM LvarScanDelay parameter: LvarScanDelay=10 Best to change/set this in your FSUIPC_WASM.ini file in your persistent storage area (i.e, under your AppData folder and not on the WASM Community folder). See the Advanced User guide for details on this if needed. So it looks like your issue is with the WASM crashing, and this only happens later during a flight, e.g. in one log it was over an hour after starting, and in the other over 4 hours after starting. This is a memory reference error (C000005). This is very strange and I will look into this. John
EisernUnion Posted May 30 Report Posted May 30 Will make this changes and continue logging.... yes, it stops anytime later ... i have no idea when, today it was on the second leg after the first leg EDDH-LOWS at some point on the second flight from LOWS-EGNT. After arriving in EGNT i restarted MSFS and now im flying Touch and go's at EGNT, this msfs session is running for 1:16 min now and still everything is still working. Im thinking about how to monitor the status of the wasm module to notice the silent die of it and try to figure out if something else had i did at this time and might had an impact on it
John Dowson Posted May 30 Report Posted May 30 1 minute ago, EisernUnion said: Im thinking about how to monitor the status of the wasm module to notice the silent die of it and try to figure out if something else had i did at this time and might had an impact on it Yes, I need more information to track this down. Maybe you should enable TRACE logging in the WASM for now. I will also add some more logging information to the WASM and provide you with an updated module to try later today. John
John Dowson Posted May 30 Report Posted May 30 @EisernUnion Can you use this version of FSUIPC7 going forward - this just has an additional log message to log when the WAPI is acquired, or why not: FSUIPC7.exe And here is an updated WASM with additional logging - you will need to set the log-level of the WASM (not the WAPI!) to Trace, as explained earlier: FSUIPC7_WASM.wasm (that is also a debug-enabled version, and may allow you to get more information about the crash from the MSFS console) layout.json manifest.json Please use those files to replace the ones in your Community FSUIPC WASM folder (fsuipc-lvar-module) (i.e. under your MSFS Community folder) - the *.wasm goes in the fsuipc-lvar-module\modules folder, the others directly under fsuipc-lvar-module. The log file will be very large with Trace logging enabled, especially when running for hours. It will need compressing/zipping before attaching. Send me your updated files again when you next get the WASM crash and I will take a look. I will also test further here. John
EisernUnion Posted May 30 Report Posted May 30 ok... first flight done so far no error ... but.. will see....
John Dowson Posted May 30 Report Posted May 30 15 minutes ago, EisernUnion said: ok... first flight done so far no error ... but.. will see.... Just send the logs when you get the WASM crash again.
superrodrigues753 Posted May 31 Report Posted May 31 I'm having the same problem, I have buttons assigned to the PMDG and in the middle of the flight they stop responding, but the axes continue to respond. follows the LOG files FSUIPC LOG exceeds 20K FSUIPC_WASM_ini.zip FSUIPC_WASM_log.zip FSUIPC7_ini.zip
Luigi Martinelli Posted May 31 Report Posted May 31 On 5/28/2024 at 8:13 PM, John Dowson said: @Luigi Martinelli You are using a very old version of FSUIPC7, v7.3.20 from April last year. Please update to the latest and only supported version, 7.4.12. John Very strange, I'm sure I have installed the latest version. I try to reattach FSUIPC7_12.rar
John Dowson Posted May 31 Report Posted May 31 6 minutes ago, superrodrigues753 said: I'm having the same problem, I have buttons assigned to the PMDG and in the middle of the flight they stop responding, but the axes continue to respond. follows the LOG files Looks like you are experiencing a WASM crash, the same as @EisernUnion. Can you please download and use the updated version of FSUIPC7 + WASM posted above and set the log level to Trace in the WASM, and re-attach your files the next time you get an issue. Your log files will be very large and will probably be to big to attach even when compressed. If so, try using one of the free file transfer services, e.g. FileTransfer.io John
John Dowson Posted May 31 Report Posted May 31 1 hour ago, Luigi Martinelli said: Very strange, I'm sure I have installed the latest version. I try to reattach The files you are attaching don't make sense: From your prev.log file: Quote ********* FSUIPC7, Version 7.3.19 (22nd March 2023) by John Dowson ********* From your (latest) .log file: Quote ********* FSUIPC7, Version 7.3.20 (24th April 2023) by John Dowson ********* From your ini file: Quote UpdatedByVersion=7412 Are they all from the same folder? They should be, but I do not understand how your log files can show a different version than your ini file. Please run MSFS again with FSUIPC7, then open your installation folder (File->Open Installation Folder...). That will be the location of your log and ini files that I need to see. And PLEASE at least check your files before posting them - if they are not from 7.4.12 or later, don't post them as they are useless to me. John
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now