FSUIPC5 - LINDA Interface Changes

[pcssundahl]

I'd be happy to do any testing you like Pete

[Scotfleiger]

Hi Pete

Thank you for your work on 5.101g. I have not been able to break it with offset writes using LINDA and the FSUIPC5_test.lua plugin I provided. However,

• The VRi LUA event.vriread(dev, "<function name>") is still failing in LUA and sometimes crashes P3Dv4. Commenting out the command allows LINDA to run but not with the VRi Combo Panel. FSUIPC5.log
• Doing offset write for Elev Trim (0x0BC0) is locking up LINDA. This was happening with earlier FSUIPC5 version so it could be my issue - fsuipc5.log. I will investigate further but did I hear you mention that others were experiencing similar problems.

I summary offsets are working but VRi Serial Interface is still failing.

 

[Pete Dowson]

1 hour ago, Scotfleiger said:

However,

I did say it was for testing. I can't test it here.

1 hour ago, Scotfleiger said:

The VRi LUA event.vriread(dev, "<function name>") is still failing in LUA and sometimes crashes P3Dv4. Commenting out the command allows LINDA to run but not with the VRi Combo Panel. FSUIPC5.log

Does that log show this somewhere? I see three exceptions:

   272391 Exception 20 "DATA_ERROR", Ref 3143, Index param 1 on write SetData for "NAV SOUND:1"
   272391 Exception 20 "DATA_ERROR", Ref 3144, Index param 1 on write SetData for "NAV SOUND:2"
   272391 Exception 20 "DATA_ERROR", Ref 3145, Index param 1 on write SetData for "ADF SOUND"

which I'll investigate. What offset(s) are you writing for those? I can't find any line with the VRIread error. What failure do you get?

That log finishes with FSUIPC waiting for DLLStop to be called. Did it then terminate normally, hang, or did you abort?

1 hour ago, Scotfleiger said:

Doing offset write for Elev Trim (0x0BC0) is locking up LINDA. This was happening with earlier FSUIPC5 version so it could be my issue - fsuipc5.log. I will investigate further but did I hear you mention that others were experiencing similar problems.

Not so much a lock up, no. By "locking up LINDA", do you mean P3D4 carries on okay? I didn't know the earlier version had any problem with Elev Trim (0xBC0). Did you mention that and I missed it?

I can't find anything relevant in the log.

It would help, when you supply a log, to provide a pointer to where anything relevant to what you are saying is logged. Mayve the elapsed trim value on the left, or a line number?

In this case, as before, enabling "ipcWrite" logging in FSUIPC would have helped.

That log finishes abruptly on the part where it has killed "init.lua". did P3D4 crash or hang there?

Sorry, I've got nothing to work with here. Did the test you sent me before do anything with 0xBC0?

Pete

 

 

 

 

[Pete Dowson]

BTW, this thread:

seems to confirm that 0BC0 for Elev Trim works now?

Pete

 

[Scotfleiger]

Hi Pete

 

Sorry I had to break off testing. I will do some more to localise the problem.

I have seen the 3 SOUND data errors for some time with FSUIPC4 using the Saitek Panel related functions. Until this week I did not realise that related to SimConnect. They occur with the various lights, battery, alternator and fuel pump settings are sent all together. I have not been able to isolate them and they have not caused problems. Ignore for the time being.

There is another thread referring to offset 0BC0 errors. I was referring to that. Again I will test further

 

 

[Pete Dowson]

35 minutes ago, Scotfleiger said:

Sorry I had to break off testing. I will do some more to localise the problem.

For the VRi comms stuff, I found a couple of silly errors I missed in visual checking. I can provide an update for that for you to test, so don't do any more on that till I provide it.

On the 0BC0 problem, can you suggest a way I can reproduce it here?

35 minutes ago, Scotfleiger said:

I have seen the 3 SOUND data errors for some time with FSUIPC4 using the Saitek Panel related functions. Until this week I did not realise that related to SimConnect.

I've checked FSUIPC's tables for these. 

NAV SOUND:1, NAV SOUND:2 and ADF SOUND are marked as being writeable! Maybe they aren't -- and, as you say, it was that way in FSUIPC4 too. (Offset 3122 includes those 3 and there they are marked as not writeable!!!)

I'll fix it in FSUIPC5 in any case.

I'm concerned about your 0BC0 problem.

Pete

 

[Scotfleiger]

Hi Pete

The VRI bug in 5.101g appears to be an incorrect COM handle (dev) set with the com.open (port, speed, handshake) call (port=3, speed=115200, handshake=0). Previously, the handle is a large number (i.e. 1887698620356) but today I am seeing a handle of 1 (one) and the LUA Error Bad VRI com handle. There is no way to do LUA exception handling (that I know of) and LINDA crashes at this point.

FSUIPC5.log - see last line (98516)

The x0BC0 error occurs immediately I try to use offset write with low value of 310 (0x0136) as a 2 byte command. Following the command LINDA stops responding. I can operate the trim wheel in the sim and inject value directly to the offset using the LINDA Tracer tool. I need to do further work.

LINDA offsets are set using via the SDK code. Off all the offsets we have been investigating most of the others have been 4 bytes long but 0x0BC0 is 2 bytes:

      FSUIPC_Write($0BC0, 2, @val, dwResult);
      FSUIPC_Process(dwResult);

FSUIPC5.log - Offset 0BC0 - see last line (136281)

 

 

 

[Scotfleiger]

18 minutes ago, Pete Dowson said:

For the VRi comms stuff, I found a couple of silly errors I missed in visual checking. I can provide an update for that for you to test, so don't do any more on that till I provide it.

OK. Thank you. I will follow your suggestions on the offset 0BC0.

[Pete Dowson]

2 minutes ago, Scotfleiger said:

The VRI bug in 5.101g appears to be an incorrect COM handle (dev) set with the com.open (port, speed, handshake) call (port=3, speed=115200, handshake=0). Previously, the handle is a large number (i.e. 1887698620356) but today I am seeing a handle of 1 (one) and the LUA Error Bad VRI com handle.

Yes, this is what I've now fixed. There was one place I missed replacing the handle index by the indexed handle itself. Sorry. Should be fine in 5.101h. Do you want that now, for testing, or shall I check writing low values to 0BC0 first?

Pete

 

[Scotfleiger]

8 minutes ago, Pete Dowson said:

Yes, this is what I've now fixed. There was one place I missed replacing the handle index by the indexed handle itself. Sorry. Should be fine in 5.101h. Do you want that now, for testing, or shall I check writing low values to 0BC0 first?

Pete

 

Yes please as VRI is more important to my users. You should have my email. 

[Pete Dowson]

24 minutes ago, Scotfleiger said:

You should have my email. 

Is that the one called just "LINDA"

[Scotfleiger]

deleted

[Pete Dowson]

19 minutes ago, Scotfleiger said:

linda@awginfosys.net

I'll check. I think that's what "LINDA" translates into ...

... Yes.

5.101h on its way.

BTW I programmed buttons to send increments and decrements of 32 to 0BC0, and it all worked as it should. So your problems are a puzzle.  It sends axis events, "ELEVATOR_TRIM_SET", with the value as parameter.

Maybe P3D4 has some occasional problems with that? The normal axis assigment you might assign to is "AXIS_ELEVATOR_TRIM_SET".  It would be easy for me to change over -- the other one is more an historical remainder (originally the FS98 control). Do you want to try that or debug the issue further first?

Pete

 

[Scotfleiger]

Hi Pete

Well done. FSUIPC5 5.101h now connects to the VRi Combo Panel and display data is displayed correctly as far as I can see. However (as always) non of the button/knob inputs are being read from the serial interface. I will need to delve deeper to see if I can detect any input data. The input data is normally format in a 5-6 byte string defining the button/knob and operation (push/rotate) eg. BARO+.

FSUIPC5.log - VRI connection and display

I will look further at the Elev Trim offset issue. I may not be able to do much for the next few days as I have some 'real life' work to do. I have been enjoying myself too much this week.

[Pete Dowson]

18 minutes ago, Scotfleiger said:

However (as always) non of the button/knob inputs are being read from the serial interface. I will need to delve deeper to see if I can detect any input data. The input data is normally format in a 5-6 byte string defining the button/knob and operation (push/rotate) eg. BARO+.

But don't you get messages from it to confirm connection?

Are no "reads" working? I don't see any in your Log. No calls to your event.VRIread function? Is there still a problem with that event function? (Mind you, I don't think the FSUIPC VRI logging is dependent on that).

Looking at the code, the VRI read and write operations look to be perfectly symettrical. I can see no difference other than the direction of data travel.

Pete

 

 

 

 

[Scotfleiger]

The event.VRIread is being actioned without error but I don't know if it is working. I am not seeing any received data and there is no logging. The VRi device number in testing 5.101h is for example 5 and 59. I can control the display output. I will delve deeper.

[Scotfleiger]

The event.vriread is not triggering the defined LUA function in LINDA.

The instruction line is: event.vriread(dev, "MCPcontrols"). The docs state:

event.vriread(handle, "functionname")          

Your processing function: function-name(handle, "data")  

This is an extension to the com library, described earlier, specifically for use with VRInsight devices. It  executes the named function whenever an apparently valid VRInsight input arrives on the identified VRInsight device. The latter is identified by the "handle" to the device returned by a com.open call made previously. The "data" provided to the function will be the 1 to 8 character string supplied by the device. Please see the document "Lua plugins for VRInsight devices". 

There is a difference in the documentation as to whether the function should be event.vriread or event.VRIread. LUA is case sensitive. I have tried both formats without success.

[Pete Dowson]

11 minutes ago, Scotfleiger said:

The VRi device number in testing 5.101h is for example 5 and 59

What is the "device number"? Sorry, you've lost me there. Do you mean the handle returned? The first handle should be 1. they are allocated in turn as they are requested, from 1 to 1024, but when a port is closed it is free for reassignment. so if you do mean handles, i don't know how it can get to 5 let alone 59 (though 5 is feasible if you are trying to open several things).

14 minutes ago, Scotfleiger said:

I can control the display output.

Yes, that puzzles me. As I said, read / write is perfectly symmetrical except for the data flow, and that's just a matter of which direction it travels to and from a buffer.

I'll see if i can dig out some serial port COM device which I can connect via USB adapter. Then I can at least test the Comms side here. The VRI code uses that. Won't be till tomorrow though, now. I'm afraid I am nearly falling off my office chair through tiredness. I've barely slept these last two weeks (max 5 hours most nights -- not enough for a 74 year old! :-( ). Almost every day has been a long 12-15 hour stint. An hour of so off for dinner (I don't eat lunch).

We had a power cut yesterday evening which gave me a bit of rest, but it only lasted an hour! I'm going to flake out now and fall asleep in front of the TV. ;-)

Pete

 

[Pete Dowson]

7 minutes ago, Scotfleiger said:

There is a difference in the documentation as to whether the function should be event.vriread or event.VRIread. LUA is case sensitive. I have tried both formats without success.

If it didn't recognise the name you'd get a LUA error reported in the Log. I know it is case sensitive, but I've added alternatives where they seemed obvious. They link to the same function, it's just a table entry.

Pete

 

[Scotfleiger]

Device Number is my name for Handle obtained when I connect to the device. The handle comes from the com.open function and used to write to the VRi device.

Don't over do it. Users can wait.

[Pete Dowson]

2 minutes ago, Scotfleiger said:

Device Number is my name for Handle obtained when I connect to the device. The handle comes from the com.open function and used to write to the VRi device.

And you get device nubers like 5 and 59? Really? They are sequentially assigned!

That is perplexing. Are you perhaps terminating and restarting many times without ports being closed?

What is the significance of "5 and 59". Are they two opened simultaneously?

Perhpas your Lua code could log the handle being provided/ used?

Pete

 

[Scotfleiger]

No. These were individual examples of the handle obtained. The handle 5 seems to be the most prominent. The latest run gave a handle of 23. My debug code logs do list the handle used. The same handle is used consistently for output and for the event.vriread within a session.

[Pete Dowson]

7 minutes ago, Scotfleiger said:

No. These were individual examples of the handle obtained. The handle 5 seems to be the most prominent. The latest run gave a handle of 23. My debug code logs do list the handle used. The same handle is used consistently for output and for the event.vriread within a session.

So, does the 5 occur after 4 previous Open requests, do you think?

The same handle sequence is also used for the EXT window handles. I don't suppose you use that Lua library as well do you?

Pete

 

[Scotfleiger]

I don't think there is any sequence I can determine. I am restarting repeatedly to run a test for Elev Trim. The latest handle for the Vri is 35. I think you can ignore what actual value is returned for the handle. It is the event.vriread that is not being triggered. Is the another read command I could use?

[pcssundahl]

FYI I have done a couple tests with 5101g. All seems good. No Errors in the log. Excellent!!!!

 

Thank you very much Pete.