FSUIPC 7 - Issue reading some offsets, others work - No C#

[activex]

John,

As per Paul's suggestion, I used the Log => offsets option, entered my offset A000 (S32) - Display to FS title bar and I get a zero value display all the time regardless of me changing the heading and observing the Lvar "ASCRJ_VAR_AP_SELHDG" being changed (in the sim).

My ini file again:

1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000

This is not the only Lvar like this, "ASCRJ_VAR_AP_SELIAS" same problem.

On the other hand, these worked no problem (they are mostly flags, and toggles):

 

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

 

[John Dowson]

Please show me your FSUIPC7.ini and FSUIPC7.log file, showing me your issue, i.e. with the LvarOffset section populating offsets for the lvars you say are always 0, together with your monitoring. Also, please issue a Add-ons->WASM->Log Lvars command, so I can see what lvars are available.

I've just taken a look at the AS CRJ 550ER and I get 1752 lvars, and in the AS CRJ700ER I also get 1752 lvars, but I cannot see the lvars L:ASCRJ_VAR_AP_SELHDG or ASCRJ_VAR_AP_SELIAS in either aircraft. Are you sure they exist? If they don't exist, your FSUIPC7.log should show an error when trying to access them.

John

[activex]

Sure thing. I would not bother you if these Lvars did not exist. Here's the requested info. I did also mention that I can retrieve the value correctly using Paul's api which uses your WASM module "FSUIPCConnection.ReadLVar("ASCRJ_VAR_AP_SELHDG")" <= works, that proves it must exist.

I was using the CRJ700, but they are there also in CRJ550. See attached files.

FSUIPC7.log FSUIPC7.ini

[John Dowson]

Your log shows the lvars having the same values as the sim shows, except for ASCRJ_VAR_AP_SELHDG:

   113766   [INFO]:     ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000
   113766   [INFO]:     ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000
   113766   [INFO]:     ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000
   113766   [INFO]:     ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000
   113766   [INFO]:     ID=1557 ASCRJ_VAR_AP_SELHDG = 0.000000
   113766   [INFO]:     ID=1558 ASCRJ_VAR_AP_SPDTREND = 0.000000
 

On 8/14/2021 at 3:31 AM, activex said:

This is not the only Lvar like this, "ASCRJ_VAR_AP_SELIAS" same problem.

That looks to have the correct value in the log you showed.

I don't understand how the sim can be showing a different value for ASCRJ_VAR_AP_SELHDG (assuming the screenshot was taken at the same time you listed the lvars)- FSUIPC treats all lvars the same, it just receives the name and value from the WASM, so if the value is 0 that is what the FS is sending.  I also don't know why I don't see those lvars in the CRJ700 - I'll take another look next week.

 

[activex]

John, the screenshot was taken after the log, so I went back and did this test in the right order, and yes, the screenshot values match what's in the log.

I included also the ASCRJ_FCP_xxx_INFO offsets for HDG/SPEED (IAS) since they mirror the other offsets.

ID=1535 ASCRJ_FCP_SPEED_INFO = 40.000000
   174625   [INFO]:     ID=1536 ASCRJ_FCP_SPEED_MODE = 0.000000
   174625   [INFO]:     ID=1537 ASCRJ_FCP_HDG_INFO = 220.000000
   174625   [INFO]:     ID=1538 ASCRJ_FCP_ALT_INFO = 10000.000000
   174625   [INFO]:     ID=1539 ASCRJ_FCP_WHEEL_INFO = -2.116344
   174625   [INFO]:     ID=1540 ASCRJ_FCP_WHEEL_MODE = 0.000000
   174625   [INFO]:     ID=1541 ASCRJ_MCDU_KYBD_TOGGLE = 0.000000
   174625   [INFO]:     ID=1542 ASCRJ_MCDU2_KYBD_TOGGLE = 0.000000
   174625   [INFO]:     ID=1543 ASCRJ_VAR_AP_LAT_ACTIVE = 5.000000
   174625   [INFO]:     ID=1544 ASCRJ_VAR_AP_LAT_ARMED = 0.000000
   174625   [INFO]:     ID=1545 ASCRJ_VAR_AP_VERT_ACTIVE = 2.000000
   174625   [INFO]:     ID=1546 ASCRJ_VAR_AP_VERT_ARMED = 0.000000
   174625   [INFO]:     ID=1547 ASCRJ_VAR_AP_VERT_ARMED_2 = 0.000000
   174625   [INFO]:     ID=1548 ASCRJ_VAR_AP_LOC_CAPTURE = 0.000000
   174625   [INFO]:     ID=1549 ASCRJ_VAR_AP_GS_CAPTURE = 0.000000
   174625   [INFO]:     ID=1550 ASCRJ_VAR_AP_ALT_HOLD = 0.000000
   174625   [INFO]:     ID=1551 ASCRJ_VAR_AP_ALT_CAPTURE = 0.000000
   174625   [INFO]:     ID=1552 ASCRJ_VAR_AP_USE_MACH = 0.000000
   174625   [INFO]:     ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000
   174625   [INFO]:     ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000
   174625   [INFO]:     ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000
   174625   [INFO]:     ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000
   174625   [INFO]:     ID=1557 ASCRJ_VAR_AP_SELHDG = 220.000000

That out of the way, why is it that the FSUIPC software using the mapped offset doesn't display the correct value in the title bar, it is always zero (see attached images).

The title bar always displays zero. Maybe it is datatype issue, if yes, can you tell me what datatype to try (the short form of the datatype to use in ini file and monitor offset screen, which one to select)?

[LvarOffsets]
1=L:ASCRJ_VAR_AP_SELHDG=SD0xA000

 

[John Dowson]

Try FLT32. S32 is for a signed 32-bit integer. Please see P13 of Advanced User manual.

John

P.S. For future reference, please also check 'Normal log file' in the offsets monitoring log panel, so I can see what it is logging in the FSUIPC7.log files that you show me. Better and easier than a screenshot.

[activex]

Okay, not too familiar with FSUIPC options, FSUIPC is really new software that I started using. I will do that.

[activex]

Quote

Try FLT32. S32 is for a signed 32-bit integer. Please see P13 of Advanced User manual.

It doesn't work even using FLT32 but ...

I did get the following offset log below when I moved the dial initially (for the first time):

137953 Monitor IPC:A000 (FLT32) = 39780386527510528.00000000
   138110 Monitor IPC:A000 (FLT32) = 0.00000000

After that, moving the dial has no effect.

I also discovered this (when testing the offset as FLT32) (not sure if that was a fluke):

If you start your CRJ cold & dark, FSUIPC will be missing some of the Lvars (including the ones I reported). NOTE: Lvars are missing only in FSUIPC, they are still there in the sim (I can view them using Model Behaviors/Local Variables window). FSUIPC will not see Lvars even if you change the state of the aircraft from cold & dark => ready for taxi. To get the lvars in FSUIPC, your aircraft must start in state ready for taxi. (I did not bother testing the other aircraft states). That probably explains why you can't see the Lvars. Definitely something wrong with FSUIPC not being able to discover all CRJ.

 

[John Dowson]

7 hours ago, activex said:

If you start your CRJ cold & dark, FSUIPC will be missing some of the Lvars (including the ones I reported).

I was starting on a runway with engine running, and I still couldn't see those lvars.

7 hours ago, activex said:

NOTE: Lvars are missing only in FSUIPC, they are still there in the sim (I can view them using Model Behaviors/Local Variables window).

Did you try issuing a Reload command to rescan for lvars (from add-ons->WASM menu)? The scanning of lvars is done shortly after the aircraft is loaded, but the full set of lvars may not yey be available, especially in more complex aircraft. There is a WASM parameter that you can adjust (via the FSUIPC_WASM.ini) called LvarScanDelay, which adds a delay before the scanning of the lvars is performed. I suggest that you increase this. You can also manually issue a Reload to check if more lvars are available.

7 hours ago, activex said:

FSUIPC will not see Lvars even if you change the state of the aircraft from cold & dark => ready for taxi.

FSUIPC  only scans in aircraft load. As I said, issue a Reload to see if you get more.

7 hours ago, activex said:

It doesn't work even using FLT32 but ...

I did get the following offset log below when I moved the dial initially (for the first time):

137953 Monitor IPC:A000 (FLT32) = 39780386527510528.00000000
   138110 Monitor IPC:A000 (FLT32) = 0.00000000

After that, moving the dial has no effect.

Could you please show me your full log file, together with your .ini. Also, please also list the lvars again if/when the monitor log shows 0.

I'll take another look at the CRJ700 later to see if I can get that lvar...

[John Dowson]

Just taken a look and I can now see those lvars. For ASCRJ_VAR_AP_SELHDG, you need to treat it as an 8-byte double, so use

On 8/15/2021 at 5:09 PM, activex said:

[LvarOffsets]
1=L:ASCRJ_VAR_AP_SELHDG=0xA000

 

and monitor as a FLT64.

 

[John Dowson]

Found an issue when adding lvars to offsets when the lvar id > 1023. I've corrected this and will post an update shortly.
There also seems to be an issue when using the SD size specifier for lvar offsets. The lvar has the correct value but the monitoring if the lvar doesn't show the correct value or value change. I am looking into it.

John

[activex]

Quote

Just taken a look and I can now see those lvars. For ASCRJ_VAR_AP_SELHDG, you need to treat it as an 8-byte double, so use

Still doesn't work, Lvar is discovered in FSUIPC, but doesn't see changes in the offset. Attached logs, and model behavior window screenshot. I did try reload function and tried again, doesn't make a difference.

[LvarOffsets]
1=L:ASCRJ_VAR_AP_SELHDG=0xA000

Quote

FSUIPC  only scans in aircraft load. As I said, issue a Reload to see if you get more.

I used the reload function when making changes to the ini file, does the reload function reload just the Lvars or also settings in the ini file (for example, when I change data type on my mapped offset and would like to use it without restarting the sim)?

FSUIPC7.ini FSUIPC7.log

[John Dowson]

Did you not read my last comment:

4 hours ago, John Dowson said:

Found an issue when adding lvars to offsets when the lvar id > 1023. I've corrected this and will post an update shortly.

?

Corrected in the attached version - please try this: FSUIPC7.exe

[activex]

Quote

Did you not read my last comment:

I did, I simply reported trying using FLT64 and my results.

Quote

Corrected in the attached version - please try this: 

Is this executable infected (it has trojan, is your computer infected)? See attachment

 

 

[John Dowson]

No, just ignore.

[activex]

Sorry, I am cautious ... This is my work machine. Did you scan the executable on your system? If yes, what software did you use. Cleary, if Windows Defender flags it as a severe thread (trojan),- it has reason for it. It found virus signature in that executable, and I don't think that's by chance. 

Maybe rebuild the executable again?

[John Dowson]

I can download that and run it without windows defender causing any issues.
If I rebuild, its exactly the same.
I don't know why you are getting a false positive. If you don't want to try it, thats up to you, but there is nothing more i can do.

John

[activex]

Quote

I can download that and run it without windows defender causing any issues.

Are you doing this on a windows box? Is it Windows 10 updated with recent updates? 

Quote

I don't know why you are getting a false positive. If you don't want to try it, thats up to you, but there is nothing more i can do.

I want to try it, but this should be more concerning to you, if I am getting it, so will other Windows users. 

I am going to retry the system and try to download it again. Re-started my system, same problem, please advise on your environment.

Can you post it  zipped, I want to see what happens if I try downloading the archive. If same thing happens, it might be good to confirm with Microsoft that is false positive for your customers. Also, interestingly, your current version of FSUIPC doesn't trigger windows defender.

 

[John Dowson]

11 hours ago, activex said:

Are you doing this on a windows box? Is it Windows 10 updated with recent updates?

Yes and yes (21H1). Here are the exe details:
    size: 625 KB (640,000 bytes)
    size on disk: 628 KB (643,072 bytes)
    created: 17 ‎August ‎2021, ‏‎19:27:50
    modified: ‎17 ‎August ‎2021, ‏‎19:26:31

Check the file properties are the same.

I occasionally get support requests saying that the installer contains a trojan or virus (again, false positives, and usually due to the installer using NSIS) but this is the first time someone has complained about the standalone exe.

zip attached.

 FSUIPC7.zip

[John Dowson]

There is an issue using the SD size specifier. That should really be used for an int (or signed int), not a 32-bit floating point value.
I've updated to use signed int for SD in the attached version, and also added a new size specifier F, which can be used to convert the lvar value (double) to a 32-bit floating point number before being stored in the offset (4-bytes).

FSUIPC7.exeFSUIPC7.zip

 

[John Dowson]

On 8/17/2021 at 3:27 AM, activex said:

Definitely something wrong with FSUIPC not being able to discover all CRJ.

The current build/release of the FSUIPC WASM module is limited to 1752 lvars per aircraft - any with an index of 1752 or higher will not be discovered by FSUIPC7.
This is due to the number of CDAs used to transmit the lvar values, currently fixed to 12 (and allowing 146 lvars per CDA).
It seems there are more than 1752 lvars for the CRJ, which is why some are missing. I could increase the number of CDAs to 14, to allow for up to 2044 lvars to be discovered, if that helps. Let me know.

John

[John Dowson]

Quote

It seems there are more than 1752 lvars for the CRJ, which is why some are missing. I could increase the number of CDAs to 14, to allow for up to 2044 lvars to be discovered

I've increased this locally and now get 1903 lvars for the CRJ700.  I will release this update in the next WASM/FSUIPC7 full release. I can post and advanced copy here if you need access to any of the lvars not currently discovered.

[activex]

I tested the new FSUIPC executable, and works now as expected. I also used the new "F" specifier and it works correctly. All the CRJ lvars I am interacting with now work.

Just one question: I noticed that reading of the lvars (via mapped offsets) is quite slow, like 5 times (or more) slower than using standard offsets (which are read instantaneously). Is this something that has to do with WASM? I know WASM technology, and the byte code should execute quite fast, but is there maybe marshalling or IPC involved? Can I do something about it, to increase speed?

Btw, the attached zipped file of the FSUIPC and the executable inside it did not trigger windows defender. Not sure what changed but it just works.

 

 

[John Dowson]

49 minutes ago, activex said:

Btw, the attached zipped file of the FSUIPC and the executable inside it did not trigger windows defender. Not sure what changed but it just works.

Hmm, strange.

49 minutes ago, activex said:

I noticed that reading of the lvars (via mapped offsets) is quite slow, like 5 times (or more) slower than using standard offsets (which are read instantaneously).

How are you reading them?
Reading an offset should be the same whatever the offset holds - an lvar, a simvar or anything else, as the code is the same. Its only the way the offset is populated that is different.

Or are you talking about when monitoring them? If so, the monitoring logging will only be performed when the lvar value changes, which depends on the defined update frequency. The lvar update frequency can be controlled by the WASM ini parameter LvarUpdateFrequency, which is set to 6Hz by default, i/e/ 6 times per second. This can be changed to one of the following values: Off, Second, 6Hz, VisualFrame, Frame (with Frame being the fastest).
Alternatively, if you turn off lvar updates in the WASM, you can set the update frequency in the client (FSUIPC7) by setting the same ini parameter in the [WAPI] section of your FSUIPC7.ini. Please see the WASM Module section in the Advanced User Guide, P 43.

59 minutes ago, activex said:

I tested the new FSUIPC executable, and works now as expected. I also used the new "F" specifier and it works correctly. All the CRJ lvars I am interacting with now work.

Ok, good. Thanks for letting me know.

[activex]

Quote

How are you reading them?

I am using a polling timer (every 500ms) and I am reading the lvar mapped offsets + standard offsets (using the same timer, the offsets are sitting in the same collection). The mapped offsets seem to take longer to get populated or it could be a side-effect if writing of the offsets is slow. I do observe when I write the offsets (lvar mapped + standard offsets) that the changes in the CRJ aircraft (like displayed hdg) appear slightly slower when changing an lvar mapped offset compared to standard offset.

In summary:

Same code, same polling timer that iterates over 2 different types of offsets (standard, vs lvar mapped) sitting in the same collection, lvar mapped offsets are slower to read/write. Maybe it is the CRJ code that's slow receiving/updating itself or something else..., I would decrease my polling timer interval but I don't think I will see the difference since the standard offsets respond fast, so I am thinking the problem is somewhere else.

UPDATE

There's 1 major difference that I do differently when writing standard offset vs lvar mapped offset:

Since the CRJ lvars are mostly read-only, I have to use the encoder (knob) on the mcp to trigger the change and then I read the changed value back (in the lvar offset) and update the display on my MCP.

For the standard offsets, I write them directly with the actual value. That's probably why it works faster.