FSUIPC 4.792 not connecting to VRI Combo

[Scotfleiger]

Hi Pete

One of my users has a problem connecting to his VRi Combo panel. I have tried all I know but have not solved the problem. Perhaps you can help.

He has the correct FDTI USB Serial drivers installed. FSUIPC4.ini has the correct [VRInsight] block with the correct comport com7 set. The FSUIPC4.log reports that: VRI port 1 "com7" opened (line 500) but it not showing VRI MCP2A ("MCP2a Airbus") detected on port com7 as I am getting. LINDA can use com.open(com7, 115200, 0) to obtain a device number but the panel fails to respond to com.write commands to reset and initialise.

The panel is working with VRi's software (VriSim.exe) so it is working. What would cause FSUIPC4 not to detect the panel?

FSUIPC4.ini

FSUIPC4-com7.log

[Pete Dowson]

14 hours ago, Scotfleiger said:

He has the correct FDTI USB Serial drivers installed. FSUIPC4.ini has the correct [VRInsight] block with the correct comport com7 set. The FSUIPC4.log reports that: VRI port 1 "com7" opened (line 500) but it not showing VRI MCP2A ("MCP2a Airbus") detected on port com7 as I am getting. LINDA can use com.open(com7, 115200, 0) to obtain a device number but the panel fails to respond to com.write commands to reset and initialise.

So with the exact same VRI device and ftdi driver, and exactly the same parameters in FSUIPC and the same direct access com.opn and com.write sequence, it responds on your system, but not on his? That seems to be what you are saying, right?

14 hours ago, Scotfleiger said:

The panel is working with VRi's software (VriSim.exe) so it is working. What would cause FSUIPC4 not to detect the panel?

Well, if everything else is the same, surely it must just be that com7 is the wrong port? Or the speed is set wrongly. Are VRi devices 115,200?

BTW I don't know what I'm supposed to look at in the attached log. It's a LINDA logging, which doesn't mean much to me I'm afraid.

Pete

 

[Scotfleiger]

Hi Pete

I have changed my comport to a high number (7) but I am not seeing the same problem - both my Combo Boeing and Airbus work. I will try a slower connection speed.

The point behind sending you the log is that FSUIPC is reporting the VRI port 1 "com7" opened (line 500) in the FSUIPC only section (before LINDA starts). On my system FSUIPC then reports VRI MCP2a detected on the port com7. My user does not get this message. Can you confirm what FSUIPC is checking to detect the VRi panel? Is there a non-detected message or action?  

Any help would be gratefully received as I have exhausted all the possible fault diagnosis routes.

[Pete Dowson]

12 minutes ago, Scotfleiger said:

The point behind sending you the log is that FSUIPC is reporting the VRI port 1 "com7" opened (line 500) in the FSUIPC only section (before LINDA starts).

That simply means that COM7 exists. You'd need to check the Windows Device Manager "COM" list to see all the COM ports and what drivers they are using.

14 minutes ago, Scotfleiger said:

On my system FSUIPC then reports VRI MCP2a detected on the port com7. My user does not get this message. Can you confirm what FSUIPC is checking to detect the VRi panel?

Well, I doubt it'll help identify the difference between yours and his, but here goes:

Immediately after Opening, it sends a "CMDRST" to reset it.

Then, after 1.2 seconds, it sends a "CMDCON".and reads whatever is sent back. If it gets nothing back within 500 mSecs, it tries again, with the 1.2 secs delay and sending a "CMDCON".  It limits it to 5 tries altogether.

It doesn't check or use whatever comes back, but immediately sends a "CMDFUN" and waits up to 1000 mSecs for a response. If not, for up to 5 times total, it restarts at the CMDCON stage as before.

If the response is recognised, it forms part of the log message "VRI xxxx (yyyy) detected on port z". The xxxx is what it received (after the first 3 bytes) and the yyyy is the FSUIPC name for it. The response it needs from an MCP2a is "???MCP2A". (Sorry, I don't remember what's in the first three positions: It is CMD for outputs, I just don't recall what it is for responses).

All this info is just by me looking at the code. Please don't ask me to explain it. It is what I figured out by experiment, mostly, and using COM port monitor programs to see the sequence VRI's own drivers use. Maybe that's the best thing to do, unless you want to write a Lua plug in to follow the sequence and see what you get. Possibly his is a different version and returns something different?

Pete

 

 

 

 

 

[Pete Dowson]

I just thought, before going to the trouble of writing a special Lua, or getting and using a COM port monitor, there is COM port logging in FSUIPC. Just add these lines to the [General] section of the INI:

Debug=Please
LogExtras=x40

Pete

[Scotfleiger]

Thank you Pete. That gives me some ideas. LINDA too sends the CMDRST and CMDCON in its initialisation. If FSUIPC is not getting a response then LINDA won’t. I will try the additional debug settings. Many thanks. 

[Pete Dowson]

15 hours ago, Scotfleiger said:

If FSUIPC is not getting a response ...

It might be getting a response, just not one it recognises. 

Pete

 

[Scotfleiger]

Thanks Pete

I have received the attached log with the COM logging on. I have yet to sit down and work out what the HEX means. I will do this this evening.

FSUIPC4.log

[Pete Dowson]

1 hour ago, Scotfleiger said:

I have received the attached log with the COM logging on. I have yet to sit down and work out what the HEX means. I will do this this evening.

The data is binary gibberish. It is either the wrong speed (but FSUIPC also uses 115200 for VRI devices), or more likely the wrong device.

Is all those COM operations from LINDA?  They only start after LINDA has started and the Lua error at time 105687 suggests so.

Was the VRI section in the FSUIPC INI file removed? I'd rather see what FSUIPC initialisation tried and received.

I only just saw that COM writes aren't logged, which is a pain. I don't know why that is (historical?). Would you like a version with Write logging added?

Pete

 

[Pete Dowson]

4 minutes ago, Pete Dowson said:

I only just saw that COM writes aren't logged, which is a pain. I don't know why that is (historical?). Would you like a version with Write logging added?

Ah, I noe see that more VRI COMs are logged by a separate option:

LogExtras=x4

So set 

LogExtras=x44

for read and write and proper VRI labelling.

(That's with FSUIPC VRI handling, of course, not direct accecc via Lua).

Pete

 

[Scotfleiger]

Hi Pete

Just to conclude. My user and I have carried out tests without LINDA and they prove that his VRi MCP Combo 2 (Airbus) is faulty - see relevant portions of the logs below. It fails to respond to the 5 CMDCON requests sent by FSUIPC4. I have advised him to contact his supplier. Thank you again for your help.

His Test (using faulty MCP2a Airbus Panel)

      500 SimConnect_Open succeeded: waiting to check version okay
      500 Trying to use SimConnect Acc/SP2 Oct07
      500 Opened separate AI Traffic client okay
      516 VRI port 1 "com3" opened
      532 VRI com3 <--- CMDRST [from FSUIPC init]
     1610 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N
     2438 VRI com3 <--- CMDCON [from FSUIPC init]
     2516 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0)
     2516 Initialising SimConnect data requests now
     2516 FSUIPC Menu entry added
     2547 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y
     2547 C:\Users\Erwin\Documents\Flight Simulator X-Dateien\standard.FLT
     2547 C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\C172\Cessna172SP.AIR
     2547 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=N
     2563 Memory in use: 612Mb, Avail=3484Mb, MaxFreeBlock=2043Mb
     3703 VRI com3 <--- CMDCON [from FSUIPC init]
     3844 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y
     4969 VRI com3 <--- CMDCON [from FSUIPC init]
     6203 VRI com3 <--- CMDCON [from FSUIPC init]
     7422 VRI com3 <--- CMDCON [from FSUIPC init]
    62641 Memory in use: 1122Mb, Avail=2974Mb, MaxFreeBlock=2043Mb
    91172 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N
    91203 Aircraft loaded: running normally now ...
    91203 User Aircraft ID 1 supplied, now being used
    91594 System time = 20/12/2017 08:04:15, Simulator time = 08:02:45 (07:02Z)
    91594 Aircraft="Cessna Skyhawk 172SP Paint1"
    94532 Starting everything now ...

My Test (using serviceable MCP2 Boeing Panel)

      187 SimConnect_Open succeeded: waiting to check version okay
      187 Trying to use SimConnect Steam
      187 Opened separate AI Traffic client okay
      218 VRI port 1 "com4" opened
      234 VRI com4 <--- CMDRST [from FSUIPC init]
     1265 Running in "Microsoft Flight Simulator X", Version: 10.0.62615.0 (SimConnect: 10.0.62615.0)
     1265 Initialising SimConnect data requests now
     1265 FSUIPC Menu entry added
     1281 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y
     1281 C:\Users\andre\Documents\Flight Simulator X Files\C172 EGPH.FLT
     1281 C:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\C172\Cessna172SP.air
     1281 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=N
     1375 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y
     1453 VRI com4 <--- CMDCON [from FSUIPC init]
     1500 COMread:   8 bytes: 43 4D 44 43 4F 4E 00 42 
     1515 VRI com4 <--- CMDFUN [from FSUIPC init]
     1687 Memory in use: 727Mb, Avail=3369Mb, MaxFreeBlock=2043Mb
     1906 COMread:   8 bytes: 43 4D 44 4D 43 50 32 42 
     1921 VRI com4 <--- CMDVER [from FSUIPC init]
     1921 VRI MCP2B ("MCP2 Boeing") detected on port com4
     1968 COMread:   8 bytes: 43 4D 44 31 2E 31 30 30 
     1984 VRI com4 <--- CMDFR [from FSUIPC init]
     4250 Weather Mode now = Theme
    10781 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=Y
    10781 Aircraft loaded: running normally now ...

[Pete Dowson]

29 minutes ago, Scotfleiger said:

Just to conclude. My user and I have carried out tests without LINDA and they prove that his VRi MCP Combo 2 (Airbus) is faulty - see relevant portions of the logs below. It fails to respond to the 5 CMDCON requests sent by FSUIPC4.

Well that does look fairly conclusive. But, then, you said in your first post in this thread:

On 12/17/2017 at 9:12 PM, Scotfleiger said:

The panel is working with VRi's software (VriSim.exe) so it is working.

which is odd -- unless they changed the protocol and it needs some other command? I would need to use a COM port monitor to find out, monitoring the exchange between the device and VriSim.exe (which, incidentally, isn't the name of their program when I implemented all this).

Alternatively, did you try connecting it through FSUIPC, with VriSim running? i.e. using the method described in Appendix 3 to the Advanced Users guide with a pair of virtual ports? Then the Logging might show what is going on.

Pete

 

[Scotfleiger]

Hi Pete

VRI issues 2 interface programs: VRISIM (which does a combination of what FSUIPC and LINDA do in a simplified way for a limited range of aircraft) and SerialFP2 (which I think you may be referring to).

As my 2 VRI MCP Panels (Boeing and Airbus) work fine and they are the same firmware version (1.100) as my user, I don’t think there is anything more I can do. His panel is kaputt!!

[Pete Dowson]

1 hour ago, Scotfleiger said:

VRI issues 2 interface programs: VRISIM (which does a combination of what FSUIPC and LINDA do in a simplified way for a limited range of aircraft) and SerialFP2 (which I think you may be referring to).

Yes, SerialFP2 was the only software from them at the time I was adding this stuff to FSUIPC.

1 hour ago, Scotfleiger said:

As my 2 VRI MCP Panels (Boeing and Airbus) work fine and they are the same firmware version (1.100) as my user, I don’t think there is anything more I can do. His panel is kaputt!!

Yes, if the firmware level is the same too, I'd definitely agree!

Pete

 

[Scotfleiger]

Hi Pete

My user is still experiencing issues with connecting his VRi Combo Panel to FSUIPC4 and therefore LINDA. However, the VRi software can communicate with no issues. You mentioned above that FSUIPC tries to connect at 115200 bps which in this case be to high. Would it be possible to be able to vary this serial speed ideally as a .ini parameter? 

[Pete Dowson]

10 hours ago, Scotfleiger said:

My user is still experiencing issues with connecting his VRi Combo Panel to FSUIPC4 and therefore LINDA. However, the VRi software can communicate with no issues. You mentioned above that FSUIPC tries to connect at 115200 bps which in this case be to high. Would it be possible to be able to vary this serial speed ideally as a .ini parameter? 

Strange. Are they making them differently now? The Combo was one of the few panels provided to me by VRi. They were all at the same speed.  I don't remember offhand what speed that was. (I'm out all day today I'm afraid).

What is their software set to?

Pete