FSUIPC5 - LINDA Interface Changes

[Pete Dowson]

1 hour ago, Scotfleiger said:

Is the another read command I could use?

Well, of course. Aren't you using com.write for writing? com.read is for reading. Logical? There's also a com.rreadlast. Check the La documents in your FSUIPC Documents folder.

Where are the "handles" in the Logs you show me? I'd like to see them, from the start of the session, because something doesn't seem right. You said "my debug code logs do list the handle used. ".

Pete

 

 

[Scotfleiger]

Hi Pete 

You know what it is like. Your brain switches on in the middle of the night and you just have to settle the matter.

I have created a 10Hz call in LUA to use the com.test(handle) and com.read(handle, 8) functions. I can now read data coming from the VRI Combo MCP panel. If I send the data read to my data handler it is processing it as expected. The handle does change when I restart my code but is working and consistent.

FSUIPC5.log - VRI com.test and com.read

While I can read the data it lags behind the input. The question therefore remains is why the event.vriread(handle, function) function is not working (still).

Back to bed.

[Pete Dowson]

3 hours ago, Scotfleiger said:

While I can read the data it lags behind the input.

Not sure why that is -- should be no different from doing that in FSUIPC4. The reading and writing are both done in separate threads, working into and out of cyclic buffers.

Is the "com.test" on time but the "com.read" lagging, or doesn't the test respond on time. And lagging by how long? More than your 100 mSecs cycle? Have you tried 50Hz (20 mSec) instead?

3 hours ago, Scotfleiger said:

The question therefore remains is why the event.vriread(handle, function) function is not working (still).

Okay. Thanks That narrows it down considerably I'll see if I can fake input to test it with. 

Pete

 

[Scotfleiger]

Morning Pete

Sorry for the confusion. It was the middle of the night. 

The lag I referred to was due to only processing one input with each 10Hz cycle. I would need to process all waiting inputs in one cycle. The event driven operation means that all inputs are processed sequentially when they occur. The lag is down to my limited test code. I am hesitant of driving the slower LUA code any faster to avoid timing errors  

I hope the information allows you to pinpoint the event.vriread fault. 

Edited June 9, 2017 by Scotfleiger
Rewording

[Scotfleiger]

Improving my test code has greatly improved handling of VRI MCP but needs further work (should I need to use it).

[Pete Dowson]

2 hours ago, Scotfleiger said:

I hope the information allows you to pinpoint the event.vriread fault. 

Found it! One of the entries in a table of "event" types was missing. The only event types which would work correctly were those preceding the missing one -- Key, Button, Offset, and Control!

I'm just checking a couple of other things then I'll upload FSUIPC 5.101j to the Download Links subforum. Have a look in about 30 minutes or so.

Pete

 

[Scotfleiger]

Great news Pete

[Scotfleiger]

Hi Pete

I am delighted to confirm that 5.101j works with the VRi Combo MCP panel as expected. Well done. I will do some more testing but I think you have a workable release for LINDA users.

[Pete Dowson]

11 minutes ago, Scotfleiger said:

I am delighted to confirm that 5.101j works with the VRi Combo MCP panel as expected. Well done. I will do some more testing but I think you have a workable release for LINDA users.

Good. Thanks for the confirmation.

I'll probably put together a proper Installer release for version 5.102 over the weekend. there a just a few little things for me to see to first. So expect one by Monday.

I am away from next Wednesday till the following Tuesday. This is why I've been nearly killing myself working to solve the asorted problems as more and more FSUIPC users do more and more things with it. Next Tuesday was my last "deadline" to resolve serious problems, including receiving confirmation.

I have still got MakeRunways to sort out. That's complex when folks add sceneries from folks like DreamTeam and FlightBeam. Makes things much more complicated.

AND there's a "ModuleUser" interface, used for FSUIPC offset reads/writes by DLLs and GAUges within the 64-bit process. The change from 32- to 64-bit pointers makes that a bit messy too.

Pete

 

[Scotfleiger]

That's perfect.I will update my beta release later today to work with 5.101j. Thank you for all the hard work. I must get back to the day job tomorrow.

I have changed my method and no longer need to use offset 0BC0 for Elev Trim. I am using the FSX control instead.

[jaxx]

I think I have the problem described in this thread as well wit my VRInsight M-Panel, or at least a very similar one.

The autopilot buttons (only the on/off buttons) stop working after a while (not really reproducible for me), everything else continues to work just fine. I get the same "DATA_ERROR" messages in the log.

After reading this thread I've noticed in the log that by default it sends the controls with 4 byte writes, whereas if I manually map e.g. <FSUIPC_CTL:66103/0> & <FSUIPC_CTL:66104/0> for AP ALT ON & OFF in the VRI Keymapper to the buttons it sends 8 byte writes:

Error:
  1373344 WRITE repeated 1 times
  1373344 WRITE0[848]  07D0,   4 bytes: 01 00 00 00                                      ....
  1373344 Exception 20 "DATA_ERROR", Ref 4079, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK"
  1373844 Exception 20 "DATA_ERROR", Ref 4081, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK"

Default write:
   767000 WRITE0[3332]  07D0,   4 bytes: 01 00 00 00                                      ....
   767000 *** EVENT: Cntrl= 66103 (0x00010237), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_ON
   767516 WRITE0[3332]  07D0,   4 bytes: 00 00 00 00                                      ....
   767516 *** EVENT: Cntrl= 66104 (0x00010238), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_OFF
   
Manually mapped write:
   948203 WRITE0[4480]  3110,   8 bytes: 37 02 01 00 00 00 00 00                          7.......
   948203 *** EVENT: Cntrl= 66103 (0x00010237), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_ON
   951750 WRITE0[4480]  3110,   8 bytes: 38 02 01 00 00 00 00 00                          8.......
   951750 *** EVENT: Cntrl= 66104 (0x00010238), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_OFF

If I understand this thread correctly the problem should be solved if I don't use the default but map every button manually so they are using 8 byte writes?
Or is the new version you are working on supposed to fix this exact issue?

[Scotfleiger]

Hi Pete

I have managed to break it again.

Using FSUIPC5 5.101j or k I am able to connect to (dev = com.open(port, speed, handshake) and set up to the VRI read event (event.VRIread(dev, function)) when P3Dv4 initially starts up. The handle (my variable dev) is invariably 5. However, if I restart the LUA code and reconnect to the VRI serial channel the event.VRIread does not appear to accept the new handle and I am not receiving data from the device. The handle is initially 5 and increments by 6 on each call to com.open() producing the sequence 5, 11, 17, 23, etc.

It would appear that the new event.VRIread is not correctly registering the revised handle. As shown before the com.open and com.write calls do recognise the revised handle.

FSUIPC5.log - 2 restarts

FSUIPC5.log - 2 restarts

FSUIPC5.log - 3 restarts - handle 5,11,17,23,etc

Note: The problem is also present in your latest 5.101m test release.

[Pete Dowson]

47 minutes ago, Scotfleiger said:

The handle is initially 5 and increments by 6 on each call to com.open() producing the sequence 5, 11, 17, 23, etc.

That is extremely odd. It implies other handles are occupying the intervening 5 slots,

I'll look to see what logging already exists for this, or else I will add something.

The code for the slot allocation is really very simple.

49 minutes ago, Scotfleiger said:

It would appear that the new event.VRIread is not correctly registering the revised handle. As shown before the com.open and com.write calls do recognise the revised handle.

"event.VRIread" does NOT register any handles. The handle you use there is the one from the com.open. I think you must mean that the VRIread call is somehow getting a different handle internally to the one you acually supply.

Bwfore I look at your logs can you please tell me where I see the handle for each log entry? I did look before, because you said you included it, but I didn't recognise anything as being a handle.

I'm afraid I am tied up this evening so it will be Sunday morning before I investigate this.

Pete

 

[Scotfleiger]

6 minutes ago, Pete Dowson said:

"event.VRIread" does NOT register any handles. The handle you use there is the one from the com.open. I think you must mean that the VRIread call is somehow getting a different handle internally to the one you acually supply.

Bwfore I look at your logs can you please tell me where I see the handle for each log entry? I did look before, because you said you included it, but I didn't recognise anything as being a handle.

If you search for "Dev=" you will see the ConnectMCP (com.open), InitMCP (com.write) and event started (event.vriread) lines in the log. The first 3 will have the Dev=5, the second 3 Dev=11, etc. I can also confirm that the com.write calls using the revised handle correctly write data to the VRI MCP.

I double check with P3Dv3 and FSUIPC4 and found handle to start at 5 but then on restart uses a varying/random large integer.

Having spent most of today isolating the problem, I have a repeatable workaround of restarting P3Dv4/FSUIPC5. There is no rush.

[Pete Dowson]

37 minutes ago, Scotfleiger said:

I double check with P3Dv3 and FSUIPC4 and found handle to start at 5 but then on restart uses a varying/random large integer.

I'm surprised the Real handles start at 5. That is weirdly coincident, and might be a clue ...

Varying large values are what I would expect.

39 minutes ago, Scotfleiger said:

There is no rush.

So leaving it till I return on Tueday 20th June is okay?

Pete

 

[Scotfleiger]

4 minutes ago, Pete Dowson said:

So leaving it till I return on Tueday 20th June is okay?

We can wait. I'm away 19-22 Jun anyway.

[Pete Dowson]

23 hours ago, Scotfleiger said:

We can wait. I'm away 19-22 Jun anyway.

I've studied the code. How the handles are increasing by 6 each time is puzzling. It's as if you have three devices with both ports of the VRI=COMx,COMy pair being open each time. Though only Lua uses the short (32bit) handles, 1-1023.

Could that be the case, in Lua? And then the first use of the VRI event is on the fifth opened port?

I've added logging to show the complete allocation tables each time Open is called and each time event.VRIread is called.  lease try this:

FSUIPC5101n_TEST.zip

Add

Debug=Please
LogExtras=x2004

to the [General] section of the FSUIPC5.INI file.

This is a first step. I might need to add more logging depending on the results of that.

Pete

 

[Scotfleiger]

Hi Pete

 

Thank you for your attention to the reported VRI event problem. I have run the test of starting P3Dv4 and LINDA 3.0.0 beta together using fsuipc5.dll 1.101n. Initially I had full VRI Combo MCP functionality using handle=5. Of note is that I had the same set up running continuously for over 3 hours this morning without any issues.

 

On restarting the LUA code several times, I got the same handle sequence on each restart - 5, 11, 17, 23, 29. With each the event.vriread failed to use the new handle but the com.write had no problems.

 

I have 6 HID devices attached to my system.

 

see post below for correct FSUIPC5.log. 

[Scotfleiger]

The log does not have the correct logging. The .ini changes did not save.

[Scotfleiger]

Correct debug fsuipc5.log with added logging data. 

[Pete Dowson]

1 hour ago, Scotfleiger said:

Correct debug fsuipc5.log with added logging data. 

Okay. So now the start at 5 is explained. It is because of 4 previous com.openhid's by your INITHID!

    91390 LUA.0: LINDA:: [INIT] Initialising HID devices...
    91390 LUA.0: LINDA:: [EVNT] InitHID...
    91422 ### DEBUG_COM: AddHandle Called, Assigned 1, Real handle=17BB36F84A4
    91422 ###    Used handle table entries now are:
    91422 ###    1, 17BB36F84A4
    91453 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0
    91453 ###    Used handle table entries now are:
    91453 ###    1, 17BB36F84A4
    91500 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0
    91500 ###    Used handle table entries now are:
    91500 ###    1, 17BB36F84A4
    91515 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=17BB358E8B4
    91515 ###    Used handle table entries now are:
    91515 ###    1, 17BB36F84A4
    91515 ###    2, 17BB358E8B4
    91562 ### DEBUG_COM: AddHandle Called, Assigned 3, Real handle=17BB37D2024
    91562 ###    Used handle table entries now are:
    91562 ###    1, 17BB36F84A4
    91562 ###    2, 17BB358E8B4
    91562 ###    3, 17BB37D2024
    91609 ### DEBUG_COM: AddHandle Called, Assigned 4, Real handle=17BB34FB734
    91609 ###    Used handle table entries now are:
    91609 ###    1, 17BB36F84A4
    91609 ###    2, 17BB358E8B4
    91609 ###    3, 17BB37D2024
    91609 ###    4, 17BB34FB734
    91640 ### DEBUG_COM: AddHandle Called, Assigned 5, Real handle=0
    91640 ###    Used handle table entries now are:
    91640 ###    1, 17BB36F84A4
    91640 ###    2, 17BB358E8B4
    91640 ###    3, 17BB37D2024
    91640 ###    4, 17BB34FB734
    91640 LUA.0: LINDA:: [hHID] OnRepeats cleared for nil....
    91656 LUA.0: LINDA:: [COMM] Check File Exists "linda-cfg/aircrafts/FSX Default/config-hid.lua"
    91656 LUA.0: LINDA:: [INIT] Default HID config loaded...
    91656 LUA.0: LINDA:: [COMM] Check File Exists "linda-cfg/aircrafts/FSX Default/config-hid.lua"
    91672 LUA.0: LINDA:: [INIT] Current aircraft (FSX Default) HID config loaded...
    91672 LUA.0: LINDA:: [COMM] Checking VRI
    91687 LUA.0: LINDA:: [COMM] Enabling VRI
    91687 LUA.0: LINDA:: [COMM] Check File Exists "linda-cfg/aircrafts/FSX Default/config-mcp2a.lua"
    91687 LUA.0: LINDA:: [COMM] ConnectMCP - Connecting to MCP Panel...
    91703 ### DEBUG_COM: AddHandle Called, Assigned 5, Real handle=17281E24BF4
    91703 ###    Used handle table entries now are:
    91703 ###    1, 17BB36F84A4
    91703 ###    2, 17BB358E8B4
    91703 ###    3, 17BB37D2024
    91703 ###    4, 17BB34FB734
    91703 ###    5, 17281E24BF4

I'll look more, for the event.vriRead problem, later tonight. Called away just now by by good wife. I think it may need additional logging in any case. Note sure what's going on here either, with apparently three calls but the first two with 0 real handles.  Could your InitHID be calling com.openhid and possibly getting a zero answer the first two times? Does it "try" for devices? (I ought to tidy my code to detect that BEFORE trying to assign a local integer as handle).

    91453 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0
    91453 ###    Used handle table entries now are:
    91453 ###    1, 17BB36F84A4
    91500 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0
    91500 ###    Used handle table entries now are:
    91500 ###    1, 17BB36F84A4
    91515 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=17BB358E8B4
    91515 ###    Used handle table entries now are:
    91515 ###    1, 17BB36F84A4
    91515 ###    2, 17BB358E8B4

Pete

 

[Scotfleiger]

Hi Pete

I did wonder about the 0 handles. This is repeated on each restart. Only the last HID is identified as the Saitek Switch Panel. Of the 7 HID devices I have attached, 2 are disabled and not used within LUA. That would account for the 5 allocated handles plus the sixth VRI device.

[Pete Dowson]

On the event.VRIread calls, the handles are certainly valid ones:

   128953 ### DEBUG_COM: event.VRIread Called, Assigned handle 11, Real handle=17281E24BF4
   159109 ### DEBUG_COM: event.VRIread Called, Assigned handle 17, Real handle=17281E24BF4
   196281 ### DEBUG_COM: event.VRIread Called, Assigned handle 23, Real handle=17281E24BF4

Each time it is referring to the handle for the device you opened two back -- refer backwards from the last mentioned above, for example. However, each "real" handle is a duplicate of the previous ones.  So when the real COM device indicates a read, it finds the first such entry every time.

Are you not closing devices at all? The assigned handle is only cleared when the com device is closed.

I should, in any case, check for the existence of the handle already in the table, and assign the same integer. That would solve the reading problem. But I'm a little worried about why previous entries aren't cleared.

Pete

 

 

[Scotfleiger]

There are no close statements and never have been. LINDA in most cases is restarted when ipcReady.lua is triggered by the Flt Sim/FSUIPC. I will have a look at the Restart sequence. 

[Pete Dowson]

58 minutes ago, Scotfleiger said:

There are no close statements and never have been. LINDA in most cases is restarted when ipcReady.lua is triggered by the Flt Sim/FSUIPC.

Ah, in that case FSUIPC would have automatically closed them on its termination in any case. 

Actually, it should be when it has to Kill your Lua threads in order to start them again.  I shall have a look at checking the Handles table then.  That might explain it. I don't think it does at present. Though it seems odd that the system provides the same handle again, because those are coming from a genuine Open.

Pete