Added Support for LVars/HVars Access in MSFS via John Dowson's WASM Module.

[John Dowson]

Maybe also check the WASM log file to see if there are any errors reported there...

[FlyingDutchman77]

Where can I find that log file? I have been looking for it. Is that even generated when you build your own C# application based on the MSFSVarServices example?

Edited April 5, 2022 by FlyingDutchman77

[FlyingDutchman77]

It is still very weird. In Debug mode it runs fine. In release mode with Visual Studio open it runs fine. Standalone I get within a short period of time (after a couple of minutes or so) this error. So the set error is preceded by an error getting the lvars:

\

What is the connection between the FSUIPC_WASM.ini parameters (especially the LvarUpdateFrequency now set at 6Hz), and the VS.LVARUpdateFrequency = 10  line in the MSFSVarServices C# code?

Still haven't found the log file, so any clues where that is would be much appreciated!

Just to add: when checking the messages after VS.Stop() it seems to be unable to clear a number of Lvar (ids 1-14). Could that be related? That in a stand alone release mode it crashes when it can't access all the Lvars anymore and somehow bypasses this when Visual studio is open? Just guessing here.

Edited April 6, 2022 by FlyingDutchman77

[John Dowson]

16 hours ago, FlyingDutchman77 said:

Where can I find that log file? I have been looking for it. Is that even generated when you build your own C# application based on the MSFSVarServices example?

Yes - it is part of the FSUIPC WASM. Thus us documented in the FSUIPC Advanced User guide only at the moment. U should provide a separate document for those using the WASM without FSUIPC really - I will look into this. For now, please find the document attached - details on the WASM can be found from page 46 onwards, with the location of the log and ini files described at the bottom of P48 (the WAPI ini is also described, which you will also be using):  FSUIPC7 for Advanced Users.pdf

4 hours ago, FlyingDutchman77 said:

What is the connection between the FSUIPC_WASM.ini parameters (especially the LvarUpdateFrequency now set at 6Hz), and the VS.LVARUpdateFrequency = 10  line in the MSFSVarServices C# code?

Presumably the VS.LVARUpdateFrequency in the  MSFSVarServices C# code sets the WAPI parameter LvarUpdateFrequency. You need to decide what update frequency you require and whether thus should be controlled by the WASM itself or by the WAPI client. If the lvars are being updated by the WASM itself, you should set the frequency in the client to be 0. Alternatively, if the client is requesting the lvar updates, you should set the update frequency in the WASM to be Off. 

4 hours ago, FlyingDutchman77 said:

Just to add: when checking the messages after VS.Stop() it seems to be unable to clear a number of Lvar (ids 1-14). Could that be related? That in a stand alone release mode it crashes when it can't access all the Lvars anymore and somehow bypasses this when Visual studio is open? Just guessing here.

If you mean the messages 'Error clearing lvar value data definition with id=...' then these are normal and can safely be ignored. The WAPI is trying to clean-up but the connection to the  FS is no longer available.

John

[Paul Henty]

Quote

It is still very weird. In Debug mode it runs fine. In release mode with Visual Studio open it runs fine. Standalone I get within a short period of time (after a couple of minutes or so) this error. 

You're probably running with the debugger attached in both cases. (F5). Try running the release version without the debugger (ctrl-F5). That should be the same behaviour as running outside of VS.

If it is (i,.e. it crashes when running via ctrl-f5) then it's very likely a timing issue. Your app is running slower with the VS debugger attached.

For John:

Quote

Presumably the VS.LVARUpdateFrequency in the  MSFSVarServices C# code sets the WAPI parameter LvarUpdateFrequency

That's correct.

Quote

If the lvars are being updated by the WASM itself, you should set the frequency in the client to be 0. Alternatively, if the client is requesting the lvar updates, you should set the update frequency in the WASM to be Off. 

I'm a bit confused about this bit. My DLL relies only on the call back registered with fsuipcw_registerLvarUpdateCallbackById to know when LVars have changed. (Parameter -1 for all Lvars). 

In this case, which setting is relevant: the wasm ini frequency or client frequency?

Paul

[John Dowson]

5 minutes ago, Paul Henty said:

I'm a bit confused about this bit. My DLL relies only on the call back registered with fsuipcw_registerLvarUpdateCallbackById to know when LVars have changed. (Parameter -1 for all Lvars). 

In this case, which setting is relevant: the wasm ini frequency or client frequency?

The callback will be called when the lvars have been updated regardless of what mechanism is being used to update the lvars. If the lvars are being updated internally by the WASM (which they will be doing if the WASM ini parameter LvarUpdateFrequency is set to anything but Off) then requests to update the lvars from the client (sent when the WAPI ini parameter LvarUpdateFrequency is anything but 0) will be ignored by the WASM, so the WASM ini parameter setting takes preference.

John
 

[Paul Henty]

Got it, thanks. So it sounds like the WASM ini should be set to off when using my dll. Is that the default?

Paul

[FlyingDutchman77]

Thx both for the assistance.

Considering the timing issue: I have implemented a Thread.Sleep command after each Lvar event setter, but this didn't help. So it doesn't seem the Simconnect thread is overloaded. Could you give an advice on how to fix this timing issue? Or where I should look for it in my code to improve it?

The issue that puzzles me is that I also use the same code to fire Simconnect axis events without any issue. I would assume that then the timing issue should also occur, but that isn't happening. It only happens with Lvar events run through the MSFSVarServices / FSUIPC wasm.

I am certainly not a professional dotner developer, but learning by doing (which is part of why I enjoy this flight simming hobby so much 😉) Your help is much appreciated!

[John Dowson]

16 minutes ago, Paul Henty said:

So it sounds like the WASM ini should be set to off when using my dll. Is that the default?

No - I think the default config is to update in the WASM at 6Hz. It is generally better to use that and set the WAPI ini parameter to 0. You should only let a WAPI client define the update frequency if you want a frequency not available in the WASM module. You also need to take care if using multiple WAPI clients as then you should only allow one to set the update frequency (if not letting the WASM update).

12 minutes ago, FlyingDutchman77 said:

Considering the timing issue: I have implemented a Thread.Sleep command after each Lvar event setter, but this didn't help. So it doesn't seem the Simconnect thread is overloaded. Could you give an advice on how to fix this timing issue? Or where I should look for it in my code to improve it?

I do not know if this is a timing issue - this was just to look into due to the description of your issue. How long are you sleeping for between each set request? Or, better, what is the frequency of your set requests? Do you get the same problem if you slow this down to say just 1 update per second?

Please activate debug logging on both the WASM and WAPI and show me both of the log files.

John

[John Dowson]

You can also try setting the lvar via the executeCalculator Code function rather than the setLvar functions. I'm not sure this will work - it may (should?) give the same error, but worth a try. To use this function, build a string of the form:
      "value (>L:lvarName)"
substituting value and lvarName with the correct values.

I would still like to see the WASM/WAPI logs if you could provide them. Depending upon what they say, I could write a small WAPI test application to see if I can duplicate this error, using the WAPI directly rather than Paul's C# wrapper.

John

[FlyingDutchman77]

I modified my code to generate a proper log file. I hope to be able to run it tonight, else it will be tomorrow morning. I will send the logfiles once I have both of them, and they can be properly correlated.

I'll also give the executeCalculator Code a try.

Really great to see your willingness to help!

[FlyingDutchman77]

So in the end I think I found the issue. It has to do with exactly this that John posted:  

Quote

I think the default config is to update in the WASM at 6Hz. It is generally better to use that and set the WAPI ini parameter to 0. 

When I did that, the issue was solved. If I select 10 for the VS.LVARUpdateFrequency in my C# app (and still having 6Hz in the WASM .ini file) it will crash after a while when in release mode (not in debug mode). I haven't tested the other way around, but can do if you are interested in that.

I might experience this issue where others do not, because I have various SimConnect tools talking to the sim simultanuously, and thereby reaching the stresspoint earlier. But it would be good to highlight this advice from John in the tutorial or example code for the MSFSVarService example.  

Again, both @Paul Henty and @John Dowson many thanks for (1) the great tools you are providing, and (2) the willingness to assist in issues like this. 

[John Dowson]

6 minutes ago, FlyingDutchman77 said:

When I did that, the issue was solved. If I select 10 for the VS.LVARUpdateFrequency in my C# app (and still having 6Hz in the WASM .ini file) it will crash after a while when in release mode (not in debug mode).

Ok, that is interesting... I don't understand how this  can cause your issue though, as requests to update lvars from a client are ignored if the WASM is configured to update itself. I may look into this further when time permits to find out exactly what is happening in this configuration.

Thanks for reporting back, and I am happy that you have now found the solution and cause.

John

[Fragtality]

Hey Paul!

I wanted to bring your attention to this thread: 

There is also the question if and where the UpdateFrequency should be set. Any advice?

[Paul Henty]

Quote

There is also the question if and where the UpdateFrequency should be set. Any advice?

I think this changed at some point. My understanding is that it's no longer needed if the interval is specified in the WASM configuration (which is the default now).

At some point I will change this in the DLL and the docs, but at the moment you should just set the the LVARUpdateFrequency property to 0, before you call Start().

Paul

[Fragtality]

Said and done - thanks! 🙂

So Events/Callbacks, Init, Config, Start - right? Like so:

WASM.OnLogEntryReceived += OnVariableServiceLogEvent;
WASM.OnVariableListChanged += OnVariableServiceListChanged;
WASM.Init(System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle);
WASM.LVARUpdateFrequency = 0;
WASM.LogLevel = LOGLEVEL.LOG_LEVEL_INFO;

WASM.Start();

 

[Paul Henty]

Yes, looks good to me,

Paul