"Error setting Client Data Calculator Code" when using execCalcCode

[John Dowson]

Looks like there may be a locking issue, which I will look at in a few days, when I get back home.

However, your log shows that lvars are still being created after the intial lvars have been received. For complex aircraft, you need to allow more time. I suggest you increase the value of the WASM ini parameter LvarScanDelay - from the Advanced User manual:

Quote

 

LvarScanDelay=5: the delay in seconds between when the Ready To Fly stage is reached and the initial scan for lvars is performed. It is recommended to increase this if using complex aircraft or airliners as it can take a while for some lvars to be created for such aircraft.

Note that lvars created after the initial scan will be found and pushed to clients if the LvarScanFrequency is non-zero.

 

I suggest you start with a value of 10-12 (seconds) and increase if you still get issues - or increase the current value by 5-7s if you have already changed this.

Also note that you should set this in the FSUIPC_WASM.ini file located in the WASM persistent storage location, not in the one under your Community folder as this will get overwritten (and therefore reset) the next time you update. See the WASM section in the Advanced User guide for details.

John

[Fragtality]

9 minutes ago, John Dowson said:

Also note that you should set this in the FSUIPC_WASM.ini file located in the WASM persistent storage location

You mean %appdata%\Microsoft Flight Simulator\Packages\fsuipc-lvar-module\work ?
I don't have a ini in there, only the two log files 🤔

[John Dowson]

Why don't you try reading the documentation....

Quote

Parameters found in location 2 (WASM persistent storage) will take president and overwrite any parameters found in the first location. A default ini file is installed with the WASM and can be found in location 1. It is recommended to leave this file as is, and copy to your persistent storage area and modify as and when needed from there.

 

[Fragtality]

Did you find a Chance to look into this? Still is an Issue, even with a LvarScanDelay of 10.

 

FSUIPC7.log

[John Dowson]

10 minutes ago, Fragtality said:

Did you find a Chance to look into this?

Not yet, but I will add another lock on sending calc code when lvar/hvar updates are being received in the next beta, which I am planning on releasing in a couple of days.

12 minutes ago, Fragtality said:

Still is an Issue, even with a LvarScanDelay of 10.

 Increase it further - your log still shows lvars are being discovered after this period, and you are getting the new lvars continually pushed. You want to set it to a value where most, if not all, lvars are found on the first scan. Try 15 seconds, and if you are then still getting new lvars pushed, increase further.

John

[John Dowson]

Did you try increasing the LvarScanDelay  further, and if so, did this prevent the CTD?

I have now added further locking in the WAPI to try and prevent this - please try the latest beta available in this thread: 

 

If you still get the same issue, can you show me a log file from a CTD when you have WAPI Trace logging as well as Lua Plugins logging (not separately!!) and Event logging activated. The file will be large and may need zipping.

John

[Fragtality]

Yep, even with 15 it happens.

Will try the .26 Beta the next Days, thanks! 🙂

[Fragtality]

It happened again - I think I found a way to reproduce: When I switch from another Plane (e.g. the Fenix) to the 787 (so the Lua-Scripts in Question get executed), FSUIPC will freeze.

The Logs attached have not the required Settings. I'll try to reproduce it with the required Settings in the next couple of Days.

 

Btw, is it normal for that Beta-Version that Applications from the [Progams] Section are started when the Session is Ready? Before they where started much earlier (during Sim-Startup)
(Note: configured with READY,KILL)

FSUIPC_WASM.log FSUIPC7.log

[John Dowson]

18 hours ago, Fragtality said:

Btw, is it normal for that Beta-Version that Applications from the [Progams] Section are started when the Session is Ready? Before they where started much earlier (during Sim-Startup)
(Note: configured with READY,KILL)

Yes - the READY parameter wasn't working correctly, and this has been corrected in the latest beta. It does list the other changes in the beta release note:

Quote

Other changes in this release (compared to 7.2.25) are:
  - corrected use of DELAY and READY parameters in [Programs] section
...

If you want it to start earlier, remove the READY.

The beta version you are using (7.3.26e) has some issues - please update to the latest beta, 7.3.26g, and test with that.

John

[Fragtality]

Wilco.

To be honest, I never had any Problems with READY. In fact it also worked perfectly to start GSX/Couatl as a Workaround for a GSX Bug.
I use it for my own Tools (FenixQuartz, Fenix2GSX, WorkingTitle2GSX, DynamicLOD) and it was just perfect.
Is there any Chance to get that Behavior back?

[John Dowson]

2 minutes ago, Fragtality said:

I never had any Problems with READY.

From the Advanced User guide:

Quote

READY - delays loading and running the program until FS is up and ready to fly, and FSUIPC can supply valid data through its IPC interface. (This parameter may, of course, result in the programs being run in a different order to that specified by the Run number)

You said:

19 hours ago, Fragtality said:

Btw, is it normal for that Beta-Version that Applications from the [Progams] Section are started when the Session is Ready? Before they where started much earlier (during Sim-Startup)

So READY obviously wasn't working as it should, and is why it has been corrected. If you want the programs to be started earlier, remove the READY.

6 minutes ago, Fragtality said:

Is there any Chance to get that Behavior back?

No - remove the READY, you don't seem to want to use this, so just remove it.

John

[Fragtality]

Hmm. So either I did not found a reliable Way to reproduce the FSUIPC Freeze, or 26g had fixed that. Let's hope some long-term/normal flying Tests show it is the latter 🙂

Yes, you're right - I don't want READY anymore 😅
Even though my Tools don't have a Problem with that (they're designed to be even started before the Sim): Would it be possible to have an additional RunIf Option in the Future - maybe let's call it "PROC" or so. It would start the given Program when SimConnect is ready to process.

[Fragtality]

Of course the Freeze happened again when I decided to do a normal Flight -.-

 

FSUIPC_WASM.log FSUIPC7.log

[John Dowson]

16 minutes ago, Fragtality said:

Hmm. So either I did not found a reliable Way to reproduce the FSUIPC Freeze, or 26g had fixed that. Let's hope some long-term/normal flying Tests show it is the latter 🙂

If you get this issue again. post again, and try and catch it with appropriate logging...

17 minutes ago, Fragtality said:

Even though my Tools don't have a Problem with that (they're designed to be even started before the Sim): Would it be possible to have an additional RunIf Option in the Future - maybe let's call it "PROC" or so. It would start the given Program when SimConnect is ready to process.

If there is no problem, why add another option? Everything is already very complicated as FSYUPC can be started in carious sim states, I would rather not add additional functionality for no perceived benefit... And this functionality has been around for many years and this hasn't been requested before,  so I doubt it is that useful...

Would this be to delay the starting further (until simconnect is ready)? If so, why not just add a delay? 

[John Dowson]

12 minutes ago, Fragtality said:

Of course the Freeze happened again when I decided to do a normal Flight -.-

Ok, I will look into this next week...I will provide you another exe with additional logging to try and track this down,.,,

John

 

[Fragtality]

Here the Logs with Events and Lua Plugins in addition to Trace!

 

11 minutes ago, John Dowson said:

If there is no problem, why add another option? Everything is already very complicated as FSYUPC can be started in carious sim states, I would rather not add additional functionality for no perceived benefit... And this functionality has been around for many years and this hasn't been requested before,  so I doubt it is that useful...

Would this be to delay the starting further (until simconnect is ready)? If so, why not just add a delay? 

There is no Problem currently, that is right. But as I wrote, the "bugged READY" was a great Workaround to Auto-Start GSX when it had Issues. So that "PROC" Option could be a useful and general Tool for Applications which have Problems to be started when the Sim is non-read or semi-ready.
Also: starting Programs which can't do anything meaningful yet (because SimConnect won't be ready soon) is not exactly perfectly reasonable also 😉
Yes, there is Delay and I'm using it also. But what is the Value which would work in any Setup? In my Setup even 60 is too less. Maybe for others it would be too much. (Background: my new Installer for my Tools can setup Auto-Start via FSUIPC for the User. So I'm thinking about what Delay if any would be appropriate as a general-for-any-Setup-Value)

But yeah, there is no real Problem (currently). I just would find it more elegant to being able to auto-start a Program when SimConnect is ready to process. 🙂 

FSUIPC7.log FSUIPC_WASM.log

[John Dowson]

Can you show me a log when you get a hang using the following version, where more logging has been added: FSUIPC7.exe

Just use WAPI Debug level logging, not Trace.

I will consider adding the extra option to run programs, but I do not know when I will have time to look into this - it will go in the backlog/to-investigate list.

John

 

[Fragtality]

9 hours ago, John Dowson said:

Can you show me a log when you get a hang using the following version, where more logging has been added: FSUIPC7.exe

Just use WAPI Debug level logging, not Trace.

Here'ya go 🙂

 

9 hours ago, John Dowson said:

I will consider adding the extra option to run programs, but I do not know when I will have time to look into this - it will go in the backlog/to-investigate list.

Sounds fair, thanks! 😄

FSUIPC7.log FSUIPC_WASM.log

[John Dowson]

Well, that last log has thrown a spanner in the works...

What was the issue - did FSUIPC hang? Could you access the UI?

In all your previous logs, the last line logged has always been:

Quote

   187140  [DEBUG]: Calling Lvar CDAs loaded callback function...

However, this time this is the last line logged, out of the blue:

Quote

   216265   [INFO]: SimConnect_Close done

And I can't see how that can be logged with no other log message indicating why it was closed....

This is all very strange and I am at a loss as to what could cause this....

It would be useful if I could see a SimConnect log file. Could you configure to generate one - see 

Also please switch back to WAPI Trace level logging, and show me the files again, including the simconnec.log (it will be quite large and will need zipping/compressing, and still may be too large to attach....).

I have also noticed an issue in the WASM from your WASM log. However, this does not cause any actual problems, but I will correct this in the next release.

John

[John Dowson]

I have just re-read this thread and it seems the issue has changed since the initial report. Can you confirm that the issue now is that FSUIPC7 seems to hang, and that there  is no  response from the UI?  If you kill and restart, does it then work? Do you only get this issue when GSX is running? How frequent is this issue, both when GSX running and when not? Do you see any events (warning or error) related to this issue in the windows event viewer?

I am going to run some extended tests in the debugger to see if I can catch anything with this...

John

 

[Fragtality]

56 minutes ago, John Dowson said:

Can you confirm that the issue now is that FSUIPC7 seems to hang, and that there  is no  response from the UI?

Yes, the Issue is now that FSUIPC7 hangs. It not just the UI, also Applications connecting to FSUIPC loose their Connection.

 

58 minutes ago, John Dowson said:

If you kill and restart, does it then work?

Yes.

 

58 minutes ago, John Dowson said:

Do you only get this issue when GSX is running?

Since both FSUIPC and GSX are started via EXE.xml, both always run together.

 

59 minutes ago, John Dowson said:

How frequent is this issue, both when GSX running and when not?

Well, everytime I want to start a normal/real Flight-Session with a 787 Aircraft (respectively when FSUIPC runs the WT787 Scripts). Like stated, GSX runs always.
But when attempting such a Flight, I start other Addons too (like STKP, FlightTrackers, AI/ATC Tools)

 

1 hour ago, John Dowson said:

Do you see any events (warning or error) related to this issue in the windows event viewer?

Nope.

[Fragtality]

3 hours ago, John Dowson said:

Also please switch back to WAPI Trace level logging, and show me the files again, including the simconnec.log (it will be quite large and will need zipping/compressing, and still may be too large to attach....).

Here the new Log Files

Logs.zip

[John Dowson]

The more I look at your log files, the more confused I am...
Can you explain exactly what happens please, and what you do....

The WASM log file indicates that you went back to the main menu:

Quote

Mon Nov 27 13:27:05 2023    [INFO]: Flight loaded: 'flights\other\MainMenu.FLT'
Mon Nov 27 13:27:05 2023   [DEBUG]: In main menu - de-activated and config data area cleared
Mon Nov 27 13:27:05 2023   [TRACE]: EV_FLTLOADED done

But there is no indication of this in your FSUIPC log file, it just loses the WASM config and is waiting for new data:

Quote

   196766  [TRACE]: Values received event completed
   209297  [TRACE]: SIMCONNECT_RECV_ID_CLIENT_DATA received: Empty EVENT_CONFIG_RECEIVED - requesting again
   209312  [TRACE]: Config data requested...
   209312  [TRACE]: SIMCONNECT_RECV_ID_CLIENT_DATA received: Empty EVENT_CONFIG_RECEIVED - requesting again
   209328  [TRACE]: Config data requested...
 

[timestamp 209297 is approx 14:23:35 + 3m29s = 14:27:04, and the 1 hour difference is due to different time zones being used]
Did you go back to the main menu, and if so when? Before or after FSUIPC stopped responding or was killed?

It looks like it just stays like this until it is killed. Are you sure there is no response from the UI? What is the message in the FSUIPC7 main window when this happens? If you keep the logging console window open, is this still logging messages, and if not what is the last message logged?

And the WASM log looks like it has been uploaded AFTER MSFS has exited. When your issue occurs again. can you attach all files before you do anything else, so I can see the contents when the issue occurred.

You also have a lot of stuff running using simconnect connections:

Quote

> 52.14517 [320, 1]Open: Version=0x00000005  Name="fs2crew-data-proc"
> 52.14709 [321, 1]Open: Version=0x00000005  Name="fsdt-msfs-bridge"
> 52.15186 [322, 1]Open: Version=0x00000005  Name="FSUIPC.LVAR.WASM"
> 52.15323 [323, 1]Open: Version=0x00000005  Name="noolaero-vdgs-cyul"
> 52.15589 [324, 1]Open: Version=0x00000005  Name="noolaero-vdgs-lirf"
> 52.16012 [325, 1]Open: Version=0x00000005  Name="MobiFlightWasmModule"
> 52.20987 [326, 0]Open: Version=0x00000004  Name="FenixBootstrapper"
> 52.24447 [327, 1]Open: Version=0x00000005  Name="Couatl"
> 52.24586 [328, 1]Open: Version=0x00000005  Name="FSHud"
> 52.24926 [329, 1]Open: Version=0x00000005  Name="Request Data"
> 52.25470 [331, 1]Open: Version=0x00000005  Name="FS2Crew Command Center"
> 52.25790 [332, 1]Open: Version=0x00000005  Name="FS2Crew - RAASPRO for MSFS"
> 52.26360 [333, 1]Open: Version=0x00000005  Name="FSUIPC7"
> 52.26700 [334, 1]Open: Version=0x00000005  Name="FSUIPC7_AItraffic"
> 52.26877 [335, 0]Open: Version=0x00000004  Name="FenixBootstrapper"
> 52.27133 [336, 0]Open: Version=0x00000004  Name="FenixBootstrapper"
> 52.27438 [337, 0]Open: Version=0x00000004  Name="FenixBootstrapper"
> 52.28036 [338, 1]Open: Version=0x00000005  Name="PilotsDeck"
> 52.28088 [339, 0]Open: Version=0x00000004  Name="FenixBootstrapper"
> 52.28565 [340, 0]Open: Version=0x00000004  Name="FenixBootstrapper"
> 54.53205 [341, 1]Open: Version=0x00000005  Name="WASMClient"
> 63.67479 [342, 1]Open: Version=0x00000005  Name="DynamicLOD"
> 63.71766 [343, 1]Open: Version=0x00000005  Name="FenixQuartz"
> 63.82159 [344, 1]Open: Version=0x00000005  Name="Fenix2GSX"
> 139.24870 [345, 1]Open: Version=0x00000005  Name="FSUIPC-WASM-IF"
> 209.93584 [346, 1]Open: Version=0x00000005  Name="Couatl"
> 210.61520 [347, 1]Open: Version=0x00000005  Name="DynamicLOD"
> 211.15578 [348, 1]Open: Version=0x00000005  Name="WASMClient"

Not sure why you are running so much Fenix stuff when you are not even using that aircraft - have you considered moving this out of your Community folder if not being used, and not running any additional software for that aircraft if not being used? Easy to do with the MSFS Add-on manager.

Note sure why you are using/running the WASMClient either - twice! You really don't need this - everything that does can be done in FSUIPC.
And you seem to be running 'Couatl' twice...

I have cleaned-up a couple of things, but nothing that could be related to your issue. I will provide you with a new version to try, including WASM, probably tomorrow now.

John
    

[Fragtality]

43 minutes ago, John Dowson said:

Can you explain exactly what happens please, and what you do....

- Starting the Addons: STKP, vAmSys, FsHud, SimLink.
- Starting MSFS
- Starting a Session
- Wait some Seconds (I wait for the little "bump" that happens when WorkingTitle2GSX resets the Fuel of the Plane, so at that Point FSUIPC still must have been running)
- Activating FsHud (you need to hit "Continue" in its GUI after Ready-to-Fly was pressed for it to really start doing something)
- Apps like PilotsDeck or WorkingTitle2GSX loose the Connection to FSUIPC and its UI does not react (it happens nothing when I click on the SysTray Icon)

 

51 minutes ago, John Dowson said:

The WASM log file indicates that you went back to the main menu:

Uhm, yeah, sure? I mean when I'm told to collect Logs of FSUIPC freezing, I surely won't quit the Sim with Alt+F4 after I reproduced the Error 😉

 

53 minutes ago, John Dowson said:

Did you go back to the main menu, and if so when? Before or after FSUIPC stopped responding or was killed?

I did go back to the Main Menu and exited the Sim first, and after that killed FSUIPC via Task-Manager.

 

54 minutes ago, John Dowson said:

It looks like it just stays like this until it is killed. Are you sure there is no response from the UI? What is the message in the FSUIPC7 main window when this happens? If you keep the logging console window open, is this still logging messages, and if not what is the last message logged?

Well, fits to the Issue I'm seeing, I'd say. It freezes and does not mind to unfreeze again 😅

When I click on the SysTray and the normal Menu does not show up / the Window does not open, I'd say I'm sure ^^

Why the FSUIPC Main Window? Should I have had it open or what? It does not open when FSUIPC starts and I have no Need to have that.

What "logging console window"?!

 

58 minutes ago, John Dowson said:

And the WASM log looks like it has been uploaded AFTER MSFS has exited. When your issue occurs again. can you attach all files before you do anything else, so I can see the contents when the issue occurred.

Wilco. To clarify: I reproduce the Error, and as soon as it is triggered collecting the Logs without doing anything more in or to the Sim, right?

 

1 hour ago, John Dowson said:

You also have a lot of stuff running using simconnect connections:

Others see a lot, I see a reasonable Amount of Addons for a Power-User 😜

 

1 hour ago, John Dowson said:

Not sure why you are running so much Fenix stuff when you are not even using that aircraft - have you considered moving this out of your Community folder if not being used, and not running any additional software for that aircraft if not being used? Easy to do with the MSFS Add-on manager.

No, did not consider and will not consider. I don't see a Problem in that Ressource-wise. Flying the Fenix represents the most-demanding Workload, and the Sim and my PC don't have a Problem with that.
My Fenix Tools are only two: Fenix2GSX and FenixQuartz. They don't do anything actively after Connection until the Fenix Binaries are actually loaded. The FenixBootstrapper comes from the Fenix it self. I can't tell you why it spawns so many Sessions.

 

1 hour ago, John Dowson said:

Note sure why you are using/running the WASMClient either - twice! You really don't need this - everything that does can be done in FSUIPC.
And you seem to be running 'Couatl' twice...

I'm not sure either. It's not that I command that somewhere deliberately. I have two Tools opening an FSUIPC / WASM Connection through the C# Client (PilotsDeck and WorkingTitle2GSX) - maybe that's why? What these Programs do can not be done in FSUIPC.

I can't tell you why GSX/Couatl is listed twice there. Maybe that is just part of the normal Behavior. As far as I can tell it restarts itself when returning to the Main Menu. Maybe the two Instances we see are a Symptom of that?

[John Dowson]

1 hour ago, Fragtality said:

Why the FSUIPC Main Window? Should I have had it open or what?

Can you test with the main window open - I would like to know if the UI responds when you get this hang/freeze.

1 hour ago, Fragtality said:

What "logging console window"?!

You access the logging console via Log->Open Console. This shows a real-time view of the FSUIPC7.log file. I would like to know if messages are till logged after the freeze, so keep that open.

1 hour ago, Fragtality said:

Wilco. To clarify: I reproduce the Error, and as soon as it is triggered collecting the Logs without doing anything more in or to the Sim, right?

Yes please - I would like to see the state of the logs when you get the freeze.

I suspect there may be a lock contention issue, and certain threads (not all!) are paused waiting for a lock that is never released.
Could you try with the attached version. Also activate logging for extras (Log->Extras), as this will also log thread information.

I have also attached an updated WASM - save the WASM to your Community/fsuipc-lvar-module/modules/ folder, and the layout.json and manifest.json to Community/fsuipc-lvar-module/

FSUIPC7.exe

FSUIPC7_WASM.wasm

layout.json

layout.json

manifest.json