Need help with setting an Lvar Hdg value on Aerosoft CRJ - Need clarification if I am even doing this right

[activex]

All,

Goal: To control toggle hdg mode "on/off" on the CRJ released by Aerosoft using Lvar support in FSUIPC. Currently, I cannot get it to work, and I am not sure why.

I did read the SDK docs on using Lvar support before trying this.

NOTE: I am using FSUIPCClient for writing/reading the value and the language I am using is C# (on .net framework). This client library and my app works perfectly fine using (read/wriate) standard FSUIPC offsets in MSFS, tested and working. Now, I am trying to use a mapped offset to a dedicated Lvar and it doesn't work.

Here's what I have:

FSUIPC7.ini entry:

[LvarOffsets.crj]
1=L:ASCRJ_FCP_HDG=SD0xA000

To set the hdg mode on, I write a single byte to offset "0xA000" with value 0x01. <= Is this correct, or should I write 0xFF.

When I do this, the memory area is changed because I can read the value back with the value I set it to but it has no effect on the CRJ. So far, I tried singed byte and signed integer (in C# that's 4 bytes, DWORD in C++), both did not work.

I did do a test by using the Set Lvar WASM function in the FSUIPC and it works. I selected the "ASCRJ_FCP_HDG" Lvar and set it to 1. This toggles the hdg mode on/off.

 

Other questions for anyone:

- Is there documentation of the CRJ Lvars, looking for datatypes, whether they are read or write and the values they accept. I know the Lvars but I don't know the rest of information about these and troubleshooting my problem is really difficult.

 

Any help would be helpful. I am sure there's something I am doing wrong or the Lvar support maybe only for C++? But then again, things work in my setup (FSUIPCClient/my c# app) on standard offsets.

[John Dowson]

11 minutes ago, activex said:

FSUIPC7.ini entry:

[LvarOffsets.crj]
1=L:ASCRJ_FCP_HDG=SD0xA000

To set the hdg mode on, I write a single byte to offset "0xA000" with value 0x01. <= Is this correct, or should I write 0xFF.

You have defined the offset to hold SD, a signed double-word of 4 bytes, so you should write it as 4 bytes.
But, the size/type of the offset should match that of the lvar, which is a flag (ie. 1 or 0), so define it as UB, an unsigned byte.
And write either 0 or 1 to it for off/on.

[John Dowson]

18 minutes ago, activex said:

- Is there documentation of the CRJ Lvars, looking for datatypes, whether they are read or write and the values they accept. I know the Lvars but I don't know the rest of information about these and troubleshooting my problem is really difficult.

Your best bet for this is the MobiFlight spreadsheet - see https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=11806850

 

[activex]

Quote

You have defined the offset to hold SD, a signed double-word of 4 bytes, so you should write it as 4 bytes.
But, the size/type of the offset should match that of the lvar, which is a flag (ie. 1 or 0), so define it as UB, an unsigned byte.
And write either 0 or 1 to it for off/on.

I tried UB, in C# that's byte (unsigned byte) and I always make sure that type definition  of lvar in the ini file matches the type I use to read/write it (in memory). It did not work - it doesn't toggle the CRJ hdg mode.

Interestingly, when using the "set Lvar" option in FSUIPC for the Lvar "ASCRJ_FCP_HDG", when you set it to "1", it toggles the function (on/off) but when you set it to "0" it does nothing, neither it turns it "off" when the hdg mode is "on". 

I am not sure what else I can do test this. I am pretty seasoned programmer, I write software professionally and checked everything, and then doubled checked. 

Any other suggestions, or logs I can consult?. I was thinking to point my finger at the FSUIPCClient C# library but I don't think that's the case since it works with standard offsets perfectly.

[John Dowson]

I am slightly confused as you keep going on about c# - are you writing a program to do this or using FSUIPC assignments?
 

10 minutes ago, activex said:

Interestingly, when using the "set Lvar" option in FSUIPC for the Lvar "ASCRJ_FCP_HDG", when you set it to "1", it toggles the function (on/off) but when you set it to "0" it does nothing, neither it turns it "off" when the hdg mode is "on". 

This seems to contradict what you said earlier:

1 hour ago, activex said:

I did do a test by using the Set Lvar WASM function in the FSUIPC and it works. I selected the "ASCRJ_FCP_HDG" Lvar and set it to 1. This toggles the hdg mode on/off.

?

To test its working, use UB, as suggested, in your LvarOffsets section and try setting/clearing the offset A000 using the Offset Byte ToggleBits control, as in the given example in the Advanced User Guide, P43.

 

[activex]

Quote

I am slightly confused as you keep going on about c# - are you writing a program to do this or using FSUIPC assignments?

My app is C#, therefore, I have to ensure that datatypes in C# must match datatypes FSUIPC documentation (basically C++ types). In a nutshell, the way I communicate from my C# app to MSFS is using FSUIPCClient C# library written by someone else. So to answer your question, everything goes through the FSUIPCClient C# layer via 2 constructs:

You create an object "Offset" of C# datatype (which should match the FSUIPC data type from documentation).

You set the objects value and call FSUIPCConnection.Process(). This will take the offsets you have created and do either read or write depending if the value of the offset has changed.

I still use the ini file to create the mapping between offset and Lvar but I send the value using my C# app. FSUIPCClient uses FSUIPC to talk to MSFS. I don't use any FSUIPC UI for configuration.

Quote

This seems to contradict what you said earlier:

I did do a test by using the Set Lvar WASM function in the FSUIPC and it works. I selected the "ASCRJ_FCP_HDG" Lvar and set it to 1. This toggles the hdg mode on/off.

Not necessarily, notice that the statement I made talks only about setting the lvar to value="1", ... I just discovered right now, recently, that setting the value to "0" does nothing as I am constantly troubleshooting.

Quote

To test its working, use UB, as suggested, in your LvarOffsets section and try setting/clearing the offset A000 using the Offset Byte ToggleBits control, as in the given example in the Advanced User Guide, P43.

Can you explain more what you mean by "Offset Byte ToggleBits control", I just don't understand the part from the documentation. Are you referring to setting specific bits? If yes, why would that matter if a flag is only either 0 or 1. So the bit pattern for byte would be: 0000 0000, 0000 0001.

Currently what I am doing in my C#, I have a variable (offset) of type byte and I assign a value of 1 to it. Then I pass that to FSUIPCConnection.Process().

EX:

Offset<byte> offset = new Offset<byte>(0xA000); // this is still mapped in the ini file as 1=L:ASCRJ_FCP_HDG=UB0xA000

offset.value =1;

FSUIPCConnection.Process();

[John Dowson]

13 hours ago, activex said:

Can you explain more what you mean by "Offset Byte ToggleBits control", I just don't understand the part from the documentation. Are you referring to setting specific bits? If yes, why would that matter if a flag is only either 0 or 1. So the bit pattern for byte would be: 0000 0000, 0000 0001.

I just suggested this as a test - it toggles between 0 and 1 (if just toggling the first bit), which would toggle the lvar value, and so also toggle the heading mode (if that worked, but you now say it only works off-> on, not on->off). If it works on->off but not off-on, and the lvar is actually changing value, then its an issue with the aircraft/lvar. If its not working at all from C#, there must be a problem in the code somewhere if the offset isn't being updated.

But if you are writing a c# app, especially using Paul Henty's dll, I don't know why you want to use this functionality. Best just to update the lvar directly using the API. See 

 

For any support for c#, please use Paul's sub-forum: FSUIPC Client DLL for .NET

John

Edited August 10, 2021 by John Dowson
Further info added

[activex]

Quote

But if you are writing a c# app, especially using Paul Henty's dll, I don't know why you want to use this functionality. Best just to update the lvar directly using the API

He did not really support Lvars/Rvars out of the box, I had to write extra code + setup to do it (passing windows handles, etc). But, as of latest version, after trying to read/write Lvars looks like it is now supported using his standard api calls. He updated his code so that the Lvar Read/Write functions now work without extra setup and coding (the do use your WASM module under the hood). I am switching to his API.

I was under the impression when you added WASM module and the setup for Lvars in the ini file it would work automatically work with his api just writing an offset. But looks like that wasn't the case. He's implementation took a different path but now everything seems to be working with his existing api from the FSX days.

 

Quote

I just suggested this as a test - it toggles between 0 and 1 (if just toggling the first bit), which would toggle the lvar value, and so also toggle the heading mode (if that worked, but you now say it only works off-> on, not on->off). If it works on->off but not off-on, and the lvar is actually changing value, then its an issue with the aircraft/lvar. If its not working at all from C#, there must be a problem in the code somewhere if the offset isn't being updated.

I have tried this and it did not work ... I can't really make a raw test because I am going through 3rd party library and the FSUIPClient functions Process an offset may do things certain way. Yes it is a object oriented wrapper around the C++ calls but again, without looking at the source code, I can't confirm why it doesn't work. Nevertheless, I'll use his api since it seems to work right now (v3.2.8). I posted on his thread so he can confirm Lvar support is fully supported by his api.

[John Dowson]

2 minutes ago, activex said:

I was under the impression when you added WASM module and the setup for Lvars in the ini file it would work automatically work with his api just writing an offset.

It should just work writing to offsets, if you have populated the offsets with the FSUIPC lvar-to-offsets functionality (registered versions of FSUIPC only). I don't know why it wasn't working for you this way.
However, with the WASM I also provide an API (WAPI), which has been integrated into Paul's .net client library.
You can also use the WAPI standalone, but if using the .net client dll already you may as well use the interface that that provides as its a proper c# interface, whereas the WAPI (dll) just provides an external C style interface.

Anyway, glad you now have it working.

[activex]

Quote

It should just work writing to offsets, if you have populated the offsets with the FSUIPC lvar-to-offsets functionality (registered versions of FSUIPC only). I don't know why it wasn't working for you this way.

Oh, my version of FSUIPC is NOT registered. Is this a requirement?? Please confirm. To obtain a registered version, is that by making a purchase of FSUIPC7?

 

Quote

However, with the WASM I also provide an API (WAPI), which has been integrated into Paul's .net client library.

Paul is using this under the hood and provides and object oriented interface. I did see the WAPI because he requires you to d/l the dll and place it along side his dll for run-time loading.

John, 1 more thing:

When using Paul's api, which uses your FSUIPC_WAPID dll (obtained from FSUIPC-WASMv0.5.2) I get "sometimes" the following exception:

Exception thrown at 0x00007FFA8FD7722C (FSUIPC_WAPID.dll) in GoFlightClientApp.exe: 0xC0000005: Access violation reading location 0x00000274C9CC3C78.

This is clearly memory read or write violation, a bad ptr? I would like to tell you also, that for window handle passed to WASM I use:

var hWindow = System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle;

Does WASM really need a window handle or can I just pass some random integer??? Reason why I am asking is because I don't have the luxury to get the window handle inside my dll, in C# forms application that is only available in the running app and that's why I use the call above to get it.

[John Dowson]

2 hours ago, activex said:

Oh, my version of FSUIPC is NOT registered. Is this a requirement??

Yes, for the lvars to offsets functionality is for registered versions only.

2 hours ago, activex said:

When using Paul's api, which uses your FSUIPC_WAPID dll (obtained from FSUIPC-WASMv0.5.2) I get "sometimes" the following exception:

Exception thrown at 0x00007FFA8FD7722C (FSUIPC_WAPID.dll) in GoFlightClientApp.exe: 0xC0000005: Access violation reading location 0x00000274C9CC3C78.

This is clearly memory read or write violation

Yes, but that is for the GoFlightClientApp.exe - I have no idea what that is, best to contact GF support for that.

2 hours ago, activex said:

I would like to tell you also, that for window handle passed to WASM I use:

var hWindow = System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle;

Does WASM really need a window handle or can I just pass some random integer??? Reason why I am asking is because I don't have the luxury to get the window handle inside my dll, in C# forms application that is only available in the running app and that's why I use the call above to get it.

Just pass NULL (or 0), bit a random integer. The windows handle is only used to set windows timers. I am thinking of removing this parameter, but its not that big of an issue.

 

[activex]

Quote

Yes, but that is for the GoFlightClientApp.exe - I have no idea what that is, best to contact GF support for that

Sorry, should of been more clear: "GoFlightClientApp" is my C# application, I named it that way. Your dll runs within the process named "GoFlightClientApp". I can comment on this exception here that it is Goflight unrelated.

My app "GoFlightClientApp" calls api inside FSUIPCClient.dll (by Paul) which in turns uses your "FSUIPC_WAPID dll" to call into your WASM module. If you also look at the exception it says the read violation occurred inside "FSUIPC_WAPID" which runs inside my application's Process address space.

Quote

Yes, for the lvars to offsets functionality is for registered versions only

Registered means I have to purchase FSUIPC7, correct? If yes, do you have trial license before I make a purchase to try out the lvar functionality. I know you guarantee it to work but I would like to make sure it works with my setup.

[John Dowson]

12 hours ago, activex said:

Sorry, should of been more clear: "GoFlightClientApp" is my C# application, I named it that way. Your dll runs within the process named "GoFlightClientApp". I can comment on this exception here that it is Goflight unrelated.

My app "GoFlightClientApp" calls api inside FSUIPCClient.dll (by Paul) which in turns uses your "FSUIPC_WAPID dll" to call into your WASM module. If you also look at the exception it says the read violation occurred inside "FSUIPC_WAPID" which runs inside my application's Process address space.

Then you need to debug your application and get a stack trace to determine where the error is. You can use the debug versions of the WAPI and WAPID - both are open source and available in github. I cannot debug your application for you. Of course, if there were any issues in the WAPI/WAPID I would fix them, and if its an issue in Paul's client dll then he would look into that. But I do not support C# development - you are really in the wrong forum and should use Paul's .net client forum. If it turns out to be an issue in the WAPI (which I doubt as its been used quote heavily in FSUIPC now for quite a while) then I would take a look. But I can do nothing with an exception report from an app that I don't know.

12 hours ago, activex said:

Registered means I have to purchase FSUIPC7, correct? If yes, do you have trial license before I make a purchase to try out the lvar functionality. I know you guarantee it to work but I would like to make sure it works with my setup.

Yes. Trial license available from 

However, I really don't think its worth purchasing a license just for the lvars-to-offsets functionality. it would be vetter to resolve your issue.

 

[Paul Henty]

2 hours ago, John Dowson said:

 if its an issue in Paul's client dll then he would look into that.

It could be, but since the error was from the WAPI dll I said to ask you.

There are 2 users experiencing this exception intermittently but I can't reproduce it. I was hoping you might be able to shed some light on it with a line number of something.

I'll take another look at my code and see if there's anything I've missed.

Paul

[John Dowson]

8 minutes ago, Paul Henty said:

There are 2 users experiencing this exception intermittently but I can't reproduce it. I was hoping you might be able to shed some light on it with a line number of something.

With a line number or something, yes, I could look into it. But I can't do  anything with an access violation location in an app that I don't have.
As the users that are getting this are developers, they should try with the debug-enabled versions of the WAPI/WAPID (and also your .net client dll) to see if they can get a stack trace, which would be more useful. I can provide the .pdb files if needed (or the WAPI/WAPID repos can be cloned to recompile to generate).

I just don't think there is anything I can do at the moment with the info provided.

John

[Paul Henty]

Quote

I just don't think there is anything I can do at the moment with the info provided.

Understood. It's most likely a problem on my end.

I think I've found a mistake with the way I'm marshalling the strings into the managed code so hopefully that will sort it.

@activexI'll update the thread in my sub-forum later today when I have a new version for you to test.

Paul

[John Dowson]

Thanks @Paul Henty!

[activex]

Quote

I'll update the thread in my sub-forum later today when I have a new version for you to test.

Thanks Paul. I will test the new version for ya and report back 🙂

Update:

It appears Paul's fix, fixed the crashes. I did few quick tests and could not get it to crash. Thanks for looking after this.

 

Quote

However, I really don't think its worth purchasing a license just for the lvars-to-offsets functionality. it would be vetter to resolve your issue.

Thanks for the temp licence. 

This would be a really convenience thing if I use the registered version since everything is already setup on my end,... All I have to do is map an offset to an Lvar and this setup would literally require 0 coding on my end. 

[activex]

John,

I got the code to work, the problem was that my lvar section in the ini file was named "[LvarOffsets.crj]", when I changed it to "[LvarOffsets]" it works. So I guess the question is when I suffix the name with a profile name, how or where do I have to create the profile? I am new to this.

I would also make a correction about the CRJ hdg toggle. By looking at it in "model behavior" window, in the sim, you need to always clear it to 0 before setting it back to 1 to have the toggle behavior. This was not apparent from just using the WASM set lvar option.

[John Dowson]

3 hours ago, activex said:

So I guess the question is when I suffix the name with a profile name, how or where do I have to create the profile? I am new to this.

You need to create the profile for the aircraft BEFORE you create the LvarOffsets section for that profile. Please see the User Guide for information on profiles.

3 hours ago, activex said:

I would also make a correction about the CRJ hdg toggle. By looking at it in "model behavior" window, in the sim, you need to always clear it to 0 before setting it back to 1 to have the toggle behavior. This was not apparent from just using the WASM set lvar option.

Not sure what this means. If its 0, you toggle it and it changes to 1. You toggle it again, and it changes back to 0.
What affect this has on the aircraft is up to the aircraft model, which is outside the scope of FSUIPC.

[activex]

Quote

Not sure what this means. If its 0, you toggle it and it changes to 1. You toggle it again, and it changes back to 0.

True but the hdg mode in CRJ doesn't work that way. When you push the button on the MCP of the CRJ aircraft (inside the sim) it sets the Lvar to 1 and resets it back to 0 (happens very fast, it is difficult to spot this visually in the model behavior window). It is programmed this way so that the lvar always starts with "0" value regardless if the hdg mode is on or off. At least this is my observation and it works this way when manipulating the mapped offset programmatically (set the offset to "1" to trigger the toggle and then set the offset back to 0 - ready state).

I'll check out the user guide, Thanks for pointing me the right direction.

Just one thing I spotted (see ERROR entries) in the log file when FSUIPC was shutting down, excerpt from FSUIPC7.log. I had no errors using FSUIPC or interfacing with my mapped lvars to offsets. Should I be concerned?

 

 149610  [ERROR]: Error clearing lvar value data definition with id=16
   149610  [ERROR]: Error clearing lvar value data definition with id=17
   149610  [ERROR]: Error clearing lvar data definition with id=4
   149610  [ERROR]: Error clearing lvar data definition with id=5
   149610  [ERROR]: Error clearing lvar data definition with id=6
   149610  [ERROR]: Error clearing lvar data definition with id=7
   149610  [ERROR]: Error clearing lvar data definition with id=8
   149610  [ERROR]: Error clearing lvar data definition with id=9
   149610  [ERROR]: Error clearing lvar data definition with id=10
   149610  [ERROR]: Error clearing lvar data definition with id=11
   149610  [ERROR]: Error clearing lvar data definition with id=12
   149610  [ERROR]: Error clearing lvar data definition with id=13
   149610  [ERROR]: Error clearing lvar data definition with id=14
   149610  [ERROR]: Error clearing lvar data definition with id=15
   149719   [INFO]: SimConnect_Close done
   153250 MSFS no longer running - exiting
   153250 === Hot key unregistered
   153250 === Stop called ...
   153250 === Closing external processes we started ...
   153766 === About to kill any Lua plug-ins still running ...
   153922 === Closing global Lua thread
   154703 === About to kill my timers ...
   154907 === Restoring window procs ...
   154907 === Unloading libraries ...
   154907 === stopping other threads ...
   154907 === ... Button scanning ...
   155016 === ... Axis scanning ...
   155125 === Releasing joystick devices ...
   155125 === Freeing macro memory
   155125 === Removing any offset overrides
   155125 === Clearing any displays left
   155125 === Calling SimConnect_Close ...
   155344 === SimConnect_Close done!
   155344 === AI slots deleted!
   155344 === Freeing button memory ...
   155344 === Closing my Windows ...
   155344 === Freeing FS libraries ...
   156360 === Closing devices ...
   156360 === Closing the Log ... Bye Bye! ...
   156360 System time = 12/08/2021 22:11:06
   156360 *** FSUIPC log file being closed
Minimum frame rate was 46.2 fps, Maximum was 109.4 fps
Average frame rate for running time of 136 secs = 64.6 fps
Maximum AI traffic for session was 14 aircraft
Traffic deletions 0 aircraft
Memory managed: 5 Allocs, 4 Freed
********* FSUIPC Log file closed ***********

 

[John Dowson]

6 hours ago, activex said:

Just one thing I spotted (see ERROR entries) in the log file when FSUIPC was shutting down, excerpt from FSUIPC7.log. I had no errors using FSUIPC or interfacing with my mapped lvars to offsets. Should I be concerned?

No, they are normal and can be ignored. They are messages from the WASM interface (WAPI) produced when trying to close down the connection to the FS gracefully by clearing the simconnect client data areas (CDAs), but the FS (and simconnect connection) is already closed/killed.

[activex]

John,  ... 1 more question:

When mapping multiple lvars to multiple offsets, when I select the free offset value, do I space the offset value based on mapped data type?

For example:

[LvarOffsets]
1=L:ASCRJ_FCP_HDG=UB0xA000
2=L:ASCRJ_FCP_HDG_LED=UB0xA001

First offset is at A000

2nd offset is next byte over A000, therefore A001

But, if 

[LvarOffsets]
1=L:ASCRJ_FCP_HDG=SD0xA000
2=L:ASCRJ_FCP_HDG_LED=SD0xA004

First offset again starts at A000 but

2nd offset should be at A004, next 4 bytes over A000 (since first offset occupies 4 bytes in size)

So, does the datatype matter on the offset selected or no?

[John Dowson]

3 minutes ago, activex said:

2nd offset should be at A004, next 4 bytes over A000 (since first offset occupies 4 bytes in size)

Yes, of course. You have to do this for 2 reasons:
   - if you used A001, for example, then you would be overwriting the 4bytes set in A000
   - 4-byte values must be aligned to a 4-byte boundary

5 minutes ago, activex said:

So, does the datatype matter on the offset selected or no?

Yes, it matters. If it didn't, you wouldn't have to specify (and everything would be 8-byte doubles). You don't need to specify if its an 8-byte double, as that is the default.

John

[activex]

Thanks John.  I  needed to verify with you that the offsets defined in the ini are not just purely logical HEX representation but instead represent and are mapped in physical address space.