Problems Connecting to VRI Combo MCP Panels

[Scotfleiger]

Hi Pete

I have had a number of reports from users that their VRInsight Combo MCP panels are failing to connect to FSUIPC and LINDA. I have been unable to find a common cause and have been unable to reproduce the problem on my own system. There is a possibility that the problem may be linked with a Win10 update (power management) or a change made to FSUIPC5 5.14-5.15. My system is fully up-to-date and I am using v5.15 without any issues.

When FSUIPC connects to the VRI Panel using the comport defined in FSUIPC5.ini [VRInsight] block, it reports "VRI port 1 "com5" opened". This should be acknowledged by an entry identifying the panel model connected "VRI MCP2 ("MCP2 Boeing") detected on port com5". This is the information (CMDMCP2B) returned from the panel with the command CMDFUN. See attached FSUIPC5-VRIConnection.log line 344 = BAD and FSUIPC5-VRIGood.log  lines 281 and 60500. The VRInsight software VRISIM.exe can be used to test this.

In the reported cases, there is no panel model reported by FSUIPC but the Device ID is returned . LINDA uses the Device ID as confirmation that the panel has been successfully connected. However, commands to the panel (CMDCON and CMDFUN) do not work and the panel is unresponsive.

Have you made any changes to the VRI logic? Any suggestions?

FSUIPC5-VRIConnection.log

FSUIPC5-VRIGood.log

[Pete Dowson]

2 hours ago, Scotfleiger said:

I have had a number of reports from users that their VRInsight Combo MCP panels are failing to connect to FSUIPC and LINDA. I have been unable to find a common cause and have been unable to reproduce the problem on my own system. There is a possibility that the problem may be linked with a Win10 update (power management) or a change made to FSUIPC5 5.14-5.15.

Nothing updated for VRI devices for years. 

2 hours ago, Scotfleiger said:

See attached FSUIPC5-VRIConnection.log line 344 = BAD and FSUIPC5-VRIGood.log  lines 281 and 60500. The VRInsight software VRISIM.exe can be used to test this.

I no longer have any VRI devices. No further VRI development was anticipated.

The "Good" log is from 5.15. Your "bad" log is from 5.14!  I suspect the 5.14 user hasn't got the VRI driver installed or set correctly.

2 hours ago, Scotfleiger said:

In the reported cases, there is no panel model reported by FSUIPC but the Device ID is returned .

What's the "Device ID"?

2 hours ago, Scotfleiger said:

Have you made any changes to the VRI logic?

No, not for years. And it evidently works in 5.15 as shown in your "good log". (Why isn't the other user on a supported version?)

2 hours ago, Scotfleiger said:

Any suggestions?

You can use FSUIPC VRI comms logging.  You need these lines in the [General] section of the INIfile:

Debug=Please
LogExtras=x4

For more logging, with all data on COM ports use LogExtras=x44

Pete

 

[Scotfleiger]

Hi Pete

Thanks for the reply. Other users with the problem have been using 5.15 so I’m not sure that is the problem. 

By Device ID I mean the handle returned when you first connect to a comport (I can’t remember the actual command) this is then used for all read and write to the port.

I will update you if I find a solution. 

[Scotfleiger]

Hi Pete

Just to update you.

Turning on the additional VRI logging has revealed more evidence of the problem. The log shows FSUIPC trying to connect to the VRI Combo panel. The comport is opened and a reset command (CMDRST) sent. The users report the panel flashing as expected. FSUIPC then tries to connect using CMDCON. This is failing and the command is sent a further 4 times in an attempt to gain a connection. This should be followed by a CMDFUN command which returns the panel type. This confirmation does not appear in the log.

Users also report that pressing the panel lamp button causes the USB/Serial Port connection to interrupt. The lamp also flashes when the panel is reset. Although the panels are powered by a DC transformer, it appears that the additional power draw of the lights is causing the disconnection. Once disconnected FSUIPC does not try to reestablish a connection. The Flt Sim must be restarted. This has worked fine for me and many others.

I suspect that the problem may lie with a recent update to Win10 USB power management. I will investigate further. 

FSUIPC5.log

[Pete Dowson]

47 minutes ago, Scotfleiger said:

FSUIPC then tries to connect using CMDCON. This is failing and the command is sent a further 4 times in an attempt to gain a connection. This should be followed by a CMDFUN command which returns the panel type. This confirmation does not appear in the log.

So the device isn't responding.

48 minutes ago, Scotfleiger said:

Users also report that pressing the panel lamp button causes the USB/Serial Port connection to interrupt. The lamp also flashes when the panel is reset. Although the panels are powered by a DC transformer, it appears that the additional power draw of the lights is causing the disconnection.

Ouch.

48 minutes ago, Scotfleiger said:

Once disconnected FSUIPC does not try to reestablish a connection

No, all the initialisation for VRI devices is performed only when loading. It would be quite an upheaval to try to do it again, at least automatically. It might be possible to make it occur by FSUIPC option or control. I don't know without looking.  And it would be only for FSUIPC5, not FSUIPC4.

Pete

 

[Scotfleiger]

Hi Pete

Thanks for the comments. I have been in contact with FDTI Support regarding the drivers for their USB-serial com port. They confirm that 2.12.28.0 dated 16 Aug 2017 is the correct.

Further testing by users confirms that it is the extra power draw by the panel lights that is causing a power 'spike' that is disconnecting the comport. The lights are triggered by the reset command (CMDRST sent on FSUIPC initial connection and subsequently by LINDA) or manually. Is is possible to ask for a test build of FSUIPC5 that removes the CMDRST - just has Open Port and CMDCON to connect?

Andrew

[John Dowson]

Hi Andrew,

can you please try the following version:

FSUIPC5150h.zip

To activate, (i.e. disable CMDRST calls) add a new flag to the [General] section of your ini file:

VRIDisableCMDRST=Yes

This should disable all sending of CMDRST.

I haven't tested this as I don't have any VRI devices (but the fix was pretty simple!).

Cheers,

John

[Scotfleiger]

Thank you very much John. I will report back. 

[Scotfleiger]

Hi John/Pete

The requested test build 5.150h is helping but the fsuipc5.ini switch keeps resetting itself negating its use. I have myself inserted the switch and set it only to find it he setting became reversed. Should it be =true or =yes?

[John Dowson]

Sorry, it should be 'Yes', not 'True'. Setting 'True' will be the same as 'No!'. My mistake - please try with 'Yes'.

(I'll edit the previous post where I gave the incorrect 'True' value).

 

[Scotfleiger]

Thank you John for confirming the typo. The 5.15h build with the ability to prevent the CMDRST command has worked in isolating the power spike to the VRI Combo panels. However, the changes you did are stopping the subsequent CMDCON (sent up to 5 times) and the CMDFUN and CMDVER being sent. It is only the CMDRST command that needs to be switched off. Also FSUIPC may no longer be reading data from the comport when the Could you check your code and advise?

UPDATE: with the switch set to yes, no inputs from the comport and panel are being received.

[John Dowson]

Hi Andrew,

Hmmm...it was only the CMDRST call that was disabled. You can try the following, which has the CMDRST enabled before closing (so the device is ready for next use):

FSUIPC5150i.zip

If this doesn't work, maybe the device does not respond unless being reset first? Otherwise it may be a power problem - do the devices have a powerful enough power supply?

Cheers,

John

[Scotfleiger]

Hi John

The VRI Combo 2 panel normally receives a CMDRST to initialise the display. Testing using other tools (VRSIM.exe and an app I have been working on) have shown that for several users the reset and flashing of the lights is causing the disconnect of the comport.

The panel does not respond to inputs or output button/knob inputs until it is connected using CMDCON. With 515h and 515i no CMDCON is logged (see FSUIPC5-515i-CMDRST-Yes.log). When everything is working, we see CMDRST (to be disabled) followed by CMDCON (up to 5 times). If the CMDCON is accepted, FSUIPC normally sends CMDFUN and CMDVER to get the panel type and firmware version (see FSUIPC5-515i-CMDRST-No.log lines 54657-54985).

I agree that the panel PSU may be a cause. All the issues have been reported by new purchasers of the VRI Combo 2 panel. I still think it is related to Win10 updates but I cannot determine a common factor.

Many thanks

Andrew

FSUIPC5-515i-CMDRST-Yes.log

FSUIPC5-515i-CMDRST-No.log

[John Dowson]

Hi Andrew,

the state wasn't being advanced which will have prevented the commands being sent. Please try the following build:

FSUIPC5150i.zip

 

Cheers,

John

 

[Scotfleiger]

Hi John

Thank you for the latest 5.15i. It works as expected with the expected VRI commands being sent (lines 265-672) and now reads all inputs from the panel. I will report back when my users have had a chance to test it. Many thanks.

FSUIPC5.log

[John Dowson]

Hi Andrew

I just replaced the above attached zip with a minor correction if you could use that instead. Thanks,

John

 

[Scotfleiger]

Noted

[Scotfleiger]

Hi John

Those users with the VRi Combo problem who have got back to me confirm that the special build 515i provides a workable solution to their power spike issue. I recommend that the VRIDisableCMDRST switch be incorporated into the baseline. Thank you for your help.

[John Dowson]

Hi Andrew,

thanks for the update. This patch will be officially released with a few other minor updates within the next week or so.

Cheers,

John