Not reading VRI data

[Scotfleiger]

I have been testing FSUIPC7 with LINDA. I am able to output data to the VRInsight MCP panel without problem. However, receiving data (ie buttons) is problematic or intermittent. I was briefly able to read some data but this is inconsistent. Previously FSUIPC was able to log this data for testing purposes. Can you assist?

 

[Pete Dowson]

14 minutes ago, Scotfleiger said:

I have been testing FSUIPC7 with LINDA. I am able to output data to the VRInsight MCP panel without problem. However, receiving data (ie buttons) is problematic or intermittent. I was briefly able to read some data but this is inconsistent.

That code area is the same as before, so I can only think it is some timing problem (the SimConnection problem -- delays and stutters both sides). If so then like the rest of SimConnect users, we are at the mercy of ASOBO/MS updates.

16 minutes ago, Scotfleiger said:

Previously FSUIPC was able to log this data for testing purposes. Can you assist?

The logging should still be there. Try these lines in the [General] section of the FSUIPC7.INI file:

Debug=Please
LogExtras=4

There's also a COM data logger which can be enabled too with

LogExtras=x44 

 (or 68)

Pete

[Scotfleiger]

Thanks Pete. I suspect you are correct about the SimConnect delays. I have removed as much load as I can and am getting a high fps but I can see delays in processing of inputs/outputs.

[Scotfleiger]

Just for feedback. With the debug options you suggested and LogOptionProtect=no, I was able to see all read and write to Vri COMPORT and I can confirm that the MCP is working correctly for me.

[Pete Dowson]

27 minutes ago, Scotfleiger said:

Just for feedback. With the debug options you suggested and LogOptionProtect=no, I was able to see all read and write to Vri COMPORT and I can confirm that the MCP is working correctly for me.

Okay, thanks for letting me know. Seems to imply that the slight slowing down as a result of the logging actually stops something clogging up. You'd think it would make it worse wouldn't you? Ah well.

Pete

 

[Scotfleiger]

5 minutes ago, Pete Dowson said:

Okay, thanks for letting me know. Seems to imply that the slight slowing down as a result of the logging actually stops something clogging up. You'd think it would make it worse wouldn't you? Ah well.

I do not believe there is any additional slowing down when reading and writing to VRi Combo MCP panel comport. I found I had a coding error (bad reference) that was stopping me getting the read working. Your advice allowed me to track this down and fix it. Using LUA with ipc.control statements does not show any observable delay when changing data (like heading).

 

[Pete Dowson]

3 minutes ago, Scotfleiger said:

I found I had a coding error (bad reference) that was stopping me getting the read working. Your advice allowed me to track this down and fix it.

Ah, yes. That makes a lot more sense!

BTW do you know why a user with a VRI MCP panel using the SerialFP2, on P3D5HF2, should be having the problem of the process hanging when closing P3D down? I've suggested that he should try LINDA instead -- I assume that then does away with the need for SeriallFP2. Is that right?

This is the thread:

Thanks,

Pete

 

[Scotfleiger]

10 minutes ago, Pete Dowson said:

BTW do you know why a user with a VRI MCP panel using the SerialFP2, on P3D5HF2, should be having the problem of the process hanging when closing P3D down? I've suggested that he should try LINDA instead -- I assume that then does away with the need for SeriallFP2. Is that right?

An additional delay was added in FSUIPC6 when it closes to ensure that LINDA could correctly terminate before the VRI MCP connection was terminated. This was because a P3D background task was left hanging. LINDA does not use the SerialFP2. I will read and reply to the thread. 

Edited August 26, 2020 by Scotfleiger
Correction

[Pete Dowson]

1 hour ago, Scotfleiger said:

I will read and reply to the thread. 

Thank you!

Pete