VrInsight Combo with FSUIPC

[MarkStallen]

If I use the rotary buttons on the Combo without FSUIPC then they work linear without sudden moves on the display of the combo. 

As soon as I start FSUIPC then the the movement is eratic and I have big jumps on the display.

If I do a clean start-up, without using LINDA and without declarations for the Combo, but only with [VRInsight] 1=COM3 in my ini-file than I've the problem as described.

 

What does FSUIPC do with the Combo, because I can't find any set-ups regarding the Combo and because of the clean start-up there are no LUA-files involved. Has it to do with the ComReadLoopTime (20 in the ini) or......?

[MarkStallen]

Maybe to make it more clear.

I've only have the FTDI USB Serial Converter installed on COM3

If I only start-up VRiSim without starting MSFS then I'm able to see the Combo-display and turn the rotary buttons with normal behaviour.

If I only start-up FSUIPC without starting MSFS then I'm able to see the Combo-display and turn the rotary buttons with eratic (if I turn fast for instance the heading display jumps 40 digits at once) behaviour.

So starting up FSUIPC changes the working of the rotary-knobs, and I'm wondering why. (com-port setup is standard with 9600 Bps 8 Databits, No parity, 1 stopbit and no data-transport-management)

[John Dowson]

I'm not sure I understand your issue. Please activate logging and see what is logged in the different situation. You probably need to log Buttons & Keys and also Events, but if your rotary works on an axis you also need to log Axes controls. I don't have any VRI devices and no nothing about VRISim, but if your assignments are done by VRISim, why  have you also assigned in FSUIPC?  Wouldn't your rotary be assigned in both, giving such issues associated with assigning in multiple places?
 

And I don't think its worth testing without MSFS running, and certainly not when using FSUIPC7.

[MarkStallen]

Testing with or without running MSFS gives the same result.

I'm not running with VRiSim, but if I use that, the rotary function works normal. Without anything loaded the combo display shows normal behaviour (no jumps, no eratic movements etc.)

As soon as I start FSUIPC without any LUA's button assignements etc. Just FSUIPC and [VRInsight] 1=COM3 then the normal behaviour is gone.

The rotary's are not working on Axes, but on buttons and keys

I guess hardcoded in FSUIPC the VRI device is opened. In the manuals I read that normally that is with dev = com.open(VRIdevice, speed, handshake) where  speed should be 115200 and handshake = 0. Maybe something is going wrong here.

Send you my ini and the log (this time with MSFS running). Because I didn't assign anything yet to the combo-keys and rotary's nothing is logged, but the combo-display is not working fine. If I close FSUIPC the the rotary and display is working good. If I assign commands to the same rotary's then they work, accept that the display on the combo is still eratic.

FSUIPC is changing the way that the combo works, without receiving or writing anything to it (maybe in the initialasation because then the combo-display shows SPD 100, HDG 000 and ALT 10000. instead of SerialFP v2.520 MCP-Combi SN:_VRI_ (that is shown as the combo receives power or as FSUIPC closes again)

FSUIPC7.log FSUIPC7.ini

[MarkStallen]

The next log is with my assignements and LUA's enabled.

If I now turn the heading rotary. Then it show the same eratic movements. 

For instance I turn it to the right from 0 degrees and then it jumps to 41 degrees on the combo display. It only send a few times the A32NX.FCU_HDG_INC to the sim so in the sim it goes from 0 to 3. And after that because that's programmed in the LUA FSUIPC write this 003 value back to the combo-display.

If I test with VriSim or serialFP2. then turning doesn't give a jump an the combo display. So that goes normal to 003 and the heading in the aircraft the same.

 

FSUIPC7.log

FSUIPC7.ini

[John Dowson]

3 minutes ago, MarkStallen said:

Testing with or without running MSFS gives the same result.

Hmm, I don't see how this can be.. Without MSFS running, no offset data is populated, and no controls/events are sent. I don't see any point investigating or looking at this without MSFS running (and an aircraft loaded and ready-to-fly).

10 minutes ago, MarkStallen said:

I guess hardcoded in FSUIPC the VRI device is opened. In the manuals I read that normally that is with dev = com.open(VRIdevice, speed, handshake) where  speed should be 115200 and handshake = 0. Maybe something is going wrong here.

No idea, sorry, as I don't have (and have never used) any VRI devices. Maybe check the FSUIPC & VRIinsight manual (or search the support forums).

11 minutes ago, MarkStallen said:

Send you my ini and the log (this time with MSFS running). Because I didn't assign anything yet to the combo-keys and rotary's nothing is logged, but the combo-display is not working fine. If I close FSUIPC the the rotary and display is working good. If I assign commands to the same rotary's then they work, accept that the display on the combo is still eratic.

So, if you close FSUIPC, what is controlling the rotary assignments if your VRISim software isn't running? 

25 minutes ago, MarkStallen said:

The next log is with my assignements and LUA's enabled.

Ok, more relevant. But maybe better to exclude your lua's for the time being, especially LINDA, if your issue is just with your assignments.

30 minutes ago, MarkStallen said:

If I now turn the heading rotary. Then it show the same eratic movements. 

Are these the events fired when you turn your rotary:

Quote

   132578 *** EVENT (Custom): Cntrl= 32849 (0x00008051), Param= 0 (0x00000000) MobiFlight.A32NX.FCU_HDG_INC
   132672 *** EVENT (Custom): Cntrl= 32849 (0x00008051), Param= 0 (0x00000000) MobiFlight.A32NX.FCU_HDG_INC
   132766 *** EVENT (Custom): Cntrl= 32849 (0x00008051), Param= 0 (0x00000000) MobiFlight.A32NX.FCU_HDG_INC

?
If so, what is sending them - I can't see anything assigned to those events in your FSUIPC7.ini file. Maybe you can let me know what/where the assignments to your rotary are (i.e. which lines in your FSUIPC7.ini)? And if its assigned to a lua (HDG.lua maybe?), then please show me that lua.

 Also, please activate logging for buttons & keys - this will at least show me which device/button number you are operating. 

And what is driving the display? Is that offset 07CC, the one you are logging? If so, please correct to log as S16. Does the display show the same as the offset (*360/65536)?

Also, as another test, please try disabling your VRI device from FSUIPC7, but use FSUIPC7 for logging when you operate the device and the VRISim software is running, so we can see what is logged when it is running normally.

Also, please check the FSUIPC & VRInsight document. It does say:

Quote

f you've already set up your system for using FSUIPC with VRInsight devices, as you should have, you will have a
[VRInsight] section in your INI file already. This will be something like this:
        [VRInsight]
        1=COM5,COM2
where COM5 is your VRInsight device connection, and COM2 is one of a pair of Virtual Ports. You COM numbers
will be different, of course, and if you have multiple VRI devices there will no doubt be more entries in this section,
one parameter line for each device.

You are not specifying the second COM port, but I do not not enough about VRInsight devices to know if this is needed or not.

John
 

 

[Pete Dowson]

47 minutes ago, MarkStallen said:

If I test with VriSim or serialFP2. then turning doesn't give a jump an the combo display.

I've never seen or dealt with "VriSim". That must have come along a while after I ceased VRI development. In my days with VRI stuff I seem to remember that "SerialFP2" was needed. Is its function now superseded by LINDA on your system?

I think perhaps that you need LINDA support?

The COM port settings must be okay because the log shows the device recognised and named:

1735 VRI FMER ("MCP Combi") detected on port COM3

so it's either something to do with the way you are interpreting the inputs, or more than one program trying to adjust the same values. What interprets the encoder movement as button presses? Is that in LINDA or one of your own plug-ins? In our document "Lua plugins for VRInsight Devices" we provide an example
"VRI_SetMach: An example for the MCP Combi Device", but this depends on setting it all up with the pair of COM ports.

I can only assume that LINDA takes it all on by itself?

Pete

 

 

[MarkStallen]

If you use FSUIPC, you don't need vrsim or serialfp2. Most buttons and rotary switches for my combo are programmed in the button-section of FSUIPC. The only thing what LINDA does for me (for instance the heading) is indeed writing 07CC back to the combo-device.

So if I disable Linda then I can turn the heading knob FSUIPC executes the events and that works fine in the sim but the display of the combo does not match the heading shown in the aircraft. Using Linda matches the display with 07CC.

But the strange thing is if I turn my heading knob and watch the display of the combo it's working fine. As soon as I start FSUIPC with or without assignements or Linda the display of the combo-device is eratic. That's strange, because you say in that case nothing is sent to or from the combo, so my ques is that there is something going on with the handshake en initialisation of the device in FSUIPC. And FSUIPC is sending something to the device because the displays only shows SPD, HDG and ALT as FSUIPC is started and not before and not after closing FSUIPC (with or without Linda or MSFS)

I understood that the second com-port in the ini is only used when you use FSUIPC together with Serial2FP , but I don't use this program.

 

So again. Everything is working fine with the combo together with Linda and FSUIPC accept that as I use FSUIPC something goes wrong on the display of the combo. Even without using Linda or assignements or other LUA's or even without starting MSFS.

In the logs I can't see what FSUIPC does with the combo on the moment that it connects to com 3, but it definitly does something because the displays are changing. The only thing what I can do with FSUIPC is to assign [VRInsight] 1=COM3, but only with that sentence the behaviour of my rotary buttons change 

 

 

[MarkStallen]

Here the HDG lua.

HDG.lua

[MarkStallen]

LOG with buttons and LOG with VRISIM running without coupling FSUIPC with com 3.

FSUIPC can't find com 3 because that's used by vrisim so it doesn't see any buttons on the combo (in this case rotary is running normal)

FSUIPC7_prev.log FSUIPC7.log

[John Dowson]

 

2 hours ago, MarkStallen said:

If you use FSUIPC, you don't need vrsim or serialfp2

Are you sure? Is that if using LINDA? I have no idea what is making the display erratic, but, looking at the documentation (and also what Pete has said), I think you  still need the SerialIFP2 driver if using it with FSUIPC, or check with Linda support.

Your logs show that FSUIPC is working as expected. However, some of the runs of the HDG.lua were killed before running, meaning some button presses would have been cancelled by subsequent ones as they are using the same lua and didn't have time to complete. Maybe not an issue, and certainly not related to your problem.

 

 

[John Dowson]

There is one parameter you could try that stops the CMDRST command being sent to the device - from the Advanced User Manual:

Quote

VRIDisableCMDRST: This optional parameter in the [General] section of the INI can be set to ‘Yes’ to disable the
sending of the CMDRST call for VRI devices.

...but I think that was added for issues related to connection (and also closing down) VRI devices. See 

John

 

Edited September 6, 2021 by John Dowson
Further info added

[Pete Dowson]

18 hours ago, MarkStallen said:

If you use FSUIPC, you don't need vrsim or serialfp2. Most buttons and rotary switches for my combo are programmed in the button-section of FSUIPC. The only thing what LINDA does for me (for instance the heading) is indeed writing 07CC back to the combo-device.

So if I disable Linda then I can turn the heading knob FSUIPC executes the events and that works fine in the sim but the display of the combo does not match the heading shown in the aircraft. Using Linda matches the display with 07CC.

Ah, I see. So without LINDA what are you using for the display? How are you expecting the display to work?  I thought you needed to rely on SerialFP2 (or maybe that newer program). I think that is why I always used a pair of virtual ports to link SerialFP2 to the device with FSUIPC sitting in the com chain.  SerialFP2->VPort1-linked to VPort2->FSUIPC->RealPort.

If it works okay with LINDA why do you not want to use it? You need something to drive the displays.

Pete

 

 

[MarkStallen]

VRIDisableCMDRST=Yes

Doesn't do the trick.

I'm using FSUIPC and Linda together. Most buttons and rotary's are programmed by FSUIPC and a few by Linda. Linda drives the displays with internal LUA's. Linda only works together with FSUIPC. But it doesn't matter if I activate the Linda.lua or not. If I start-up FSUIPC the rotary switches act abnormal as described.

If I don't use FSUIPC but start-up with VriSim or Serialfp2 then they act normal. These two programs have very limited options to use with MSFS 2020 so I really need FSUIPC instead. If have the possibility to run them both (SerialFP2 and FSUIPC as you described), but as soon as I start FSUIPC then the abnormal acting starts. And that happens before something is writing to the combo even without starting MSFS already.

If I run MSFS then the movement of the rotary display is eratic. It displays in one or two clicks jumps over 20 to 40. It sends the commands to MSFS normally, and after that MSFS send back it's new state to the combo and the display on the combo is then again the same as in MSFS.

So the problem is something internal in the combo, but it is only ocuring when FSUIPC is started. Even before driving the display off the combo. Starting FSUIPC activates the combo. (Display of Combo switches from welcome-text to SPEED, HDG and ALT). Stopping FSUIPC deactivates the combo again. So FSUIPC is doing something with the combo at initialisation and there is something going wrong, because after the handshake of FSUIPC and the combo the error ocures. 

Starting SerialFP2 does the same thing  (Display of Combo switches from welcome-text to SPEED, HDG and ALT) but then the rotary buttons stay reacting normal.

[MarkStallen]

To make it more clear.

First foto is as you put power on the combo.

Second foto is the display after starting FSUIPC (is the same after starting SerialFP2)

Third foto as you can see is turning the HDG button 180 degrees to the right (11 clicks) with FSUIPC running gives 53 (sometimes it even goes up to 91)on the display

Fourth foto is with SerialFP2 running same turn of the HDG button (11 clicks) gives 11 on the display.

This without running MSFS or Linda or LUA's etc. But if I run those the outcome is exactly the same, but due to the LUA's the display of the Combo changes after a few moments back to 11, because MSFS sends then the 077C offset (in this case 11)  via FSUIPC and the LUA in Linda back to the Combo.

[John Dowson]

3 hours ago, MarkStallen said:

Fourth foto is with SerialFP2 running same turn of the HDG button (11 clicks) gives 11 on the display.

Without FSUIPC or Linda running? If so, then SetialIFP2 must be getting the input from your rotaries and changing the display. 

3 hours ago, MarkStallen said:

This without running MSFS or Linda or LUA's etc.

As I have said, there is no point testing this with FSUIPC without MSFS running.

3 hours ago, MarkStallen said:

But if I run those the outcome is exactly the same, but due to the LUA's the display of the Combo changes after a few moments back to 11, because MSFS sends then the 077C offset (in this case 11)  via FSUIPC and the LUA in Linda back to the Combo.

Is this with SerialIFP2 running AND configured properly in FSUIPC using the real and virtual com ports? If you have not tried to configure using SerialIFP + FSUIPC as described in the manuals, you should really try this before anything else..
And if using Linda, you should ask on the Linda support forums, if it is Linda that is driving the display.

You should also try with other simpler/stock  aircraft, and not he FBW A320 - maybe the A320 is not using the Autopilot Heading Lock Dir sim variable. Have you tried with other aircraft?

You can also try logging VRI coms by adding the following to the [General] section of your ini (although I doubt this will reveal anything of use):
    Debug=Please
    LogExtras=4

Have you used this successfully with any other flight sims  - FSX or P3D)?

Other than that, I do not know what to advise with this. There have been no changes in this area for many years (apart from the addition of the VRIDisableCMDRST ini parameter 2.5 years ago), so I suspect it is either related to your  configuration or maybe MSFS+FBW. Maybe some other VRI users can help...

 

[MarkStallen]

I think I don't get my problem clear. Maybe you can answer the following question. What code (hardcoded in FSUIPC.exe) did you use to open communications with the VrInsight Combo on com-port 3. (which baudrate etc.)

I'm think that FBW A320 is using AUTOPILOT HEADING SLOT INDEX (with spaces) and should be a A:-type simvariable. I'm trying to find that one to test it.

[MarkStallen]

AUTOPILOT HEADING SLOT INDEX isn't right either.

So I don't know which LVAR or VAR is setting the FCU FBW A320 display. 

The LVAR A32NX_AUTOPILOT_HEADING_SELECTED is depicting what the FCU shows, but if you change it the FCU display doesn't change with it.

[John Dowson]

2 hours ago, MarkStallen said:

What code (hardcoded in FSUIPC.exe) did you use to open communications with the VrInsight Combo on com-port 3. (which baudrate etc.)

Did you try the suggested logging? That should show you what is being sent. And ithe port is irrelevant. What is relevant is if you have set-up using the virtual port or not. Have you tried this? If not, why not?
And, as I have said, the FSUIPC code for VRI devices hasn't changed much (or at all, apart from the new ini option already mentioned) in 10 or so years, without an issue.
You are not responding to my questions or suggestions, so I can't really do anything about this.

And I do not know why you keep mentioning specifics about the FBW A320. FSUIPC is aircraft agnostic - it is YOU that nee to know how the aircraft works and configure FSUIPC accordingly. As I previously mentioned, add-on aircraft may not use the FS facilities and implement their own systems, so standard FS controls/offsets may not work. Have you actually tried with any other (preferably stock) aircraft?

I'm sorry but I have nothing more to say on this matter until I get some response from what I have already proposed. Mainly, have you actually tried setting things up as described in the documentation? 

If you are not prepared to try this, this topic is closed.

John

 

[Pete Dowson]

As well as what John has told you, FSUIPC's inbuilt VRI facilities only deal with inputs -- switches etc which you can assign. It does not handle displays at all. You need to address whatever it is handling the displays. In the solution suggested by us, as described in the Lua Plugins for VRInsight Devices document, the Lua plug-ins needed  for proper support depend on using SerialFP2 and the twin ports as described.

That document also confirms that the correct COM port speed is 115200, but, anyway, yours must be correct for the device to be correctly identified and logged, as I explained before.

Pete

 

[draci]

Dear Marc,

I have a similar problem in P3dv5, when the MPC Combo is LINDA-driven. I wouldn't call the behaviour "erratic" but when I turn the heading knob - let's say - 1  click to the right, the HDG sometimes jumps up to 3 degrees to the right and sometimes even three to the left, although I turn the knob to the right. Whether FSUIPC or LINDA is the culprit, I don't know, most probably it is just a worn-out knob-mechanism since I have been using the MCP Combo for ten years now, and the HDG knob was turned thousands of times. What helped a little is disabling the fast movements (++) and (--) which seems to give a little more control precision. My problem is even worse than yours, since I constantly get ucrtbase.dll errors on every flight in the PMDG QOSII and I have the suspicion that it must be the VriSIm-software causing it. Reading your discussion above brought me to the idea that I could try the VriSim Software instead of LINDA (since I already use it successfully for the CDUII in P3dv5), perhaps this will prevent the CTD, however, I don't remember exactly how to set it up: In the keymap-file I assign key shortcuts which I then assign in FSUIPC to PMDG offsets (taken from the .h file in the PMDG folder), is that correct?

Draci

[Andydigital]

Lorbys Axis and Ohs handles the VRi displays fairly easily with his VriBridge plugin. The original MCP combo is not supported though, just the MCP2 Boeing and Airbus FCU panels. 

As for the jumping, yeah that's worn encoders, think yourselves lucky them lasting so long. My original Combo need a replacement board after a little over a year.

[MarkStallen]

Andydigital and draci

The jumps only occure when I use FSUIPC. True that the buttons are more eratic over time, but the jumps of 20 to 40 degrees happen when I turn the switch fast. If I activate the VrInisght with VriSim or SerialFP2 that doesn't happen, only with FSUIPC. So I was wondering that for instance FSUIPC open the Combo with the wrong baud rate or something like that.

[MarkStallen]

Pete,

I don't want to arque with you, but I don't get my problem clear to you. One last try.

How the VrInsightCombo works:

If you just put it on with no other software at all and you turn for instance the heading button, then the display is showing 001 to 359 degrees without sudden movements. It does that on its own, without getting inputs of other programs. It's in the hardware of the Combo.

With LUA"S you can use the Combo to read and write to offsets (I don't use any commands for the heading). What it does, it reads what is in the Combo (as it displays) and writes that to an offset. Or other way arround it reads the offset and writes that to the Combo (and displays that). So when you're not using a LUA at all then the display just goes from 001 to 359 and vice versa and nothing else happens.

Without FSUIPC running the combo works as described no sudden jumps of 40 degrees if I rotate it fast. With FSUIPC, without running any LUA's or anything at all it looks like the rotary switches on my combo are reacting differently then without FSUIPC running. And that is strange because accept running FSUIPC with COM 3 under VrInsight in the ini-file I do nothing with my COMBO, because there are no lua's or commands running. If I disable the handshake with FSUIPC (take it off the ini file) and the Combo and I run FSUIPC then the Combo is working fine.

So the question is: does FSUIPC send things to the combo without any LUA -scripting or assignements to the combo?

 

I don't use VriSim or SerialFP2. I don't need them. I only started them up to see if they did the same thing with the combo as FSUIPC did (change the behaviour of my rotary switches). But they didn't. The only thing you need is a virtual com port driver (FTDI) and the line [VRInsight]1=COM3 in the FSUIPC.ini that is enough to get it working. And it works great accept of my problem. With my problem it's working too, but not so nice as it could be.

 

[Pete Dowson]

5 hours ago, MarkStallen said:

f you just put it on with no other software at all and you turn for instance the heading button, then the display is showing 001 to 359 degrees without sudden movements. It does that on its own, without getting inputs of other programs. It's in the hardware of the Combo.

So it isn't displaying the actual values in the Sim, is it? Seems little point. Surely when you are using the proper software with it, it is that which changes the displays? Otherwise how are the displays changing differently with FSUIPC running -- after all, all FSUIPC is doing is receiving the button presses from the encoders. It isn't sending anything back unless you've added something like LINDA or your own Lua plug-ins to update the displays.

5 hours ago, MarkStallen said:

So the question is: does FSUIPC send things to the combo without any LUA -scripting or assignements to the combo?

No. It doesn't know what to send or how without additional software.

5 hours ago, MarkStallen said:

I don't use VriSim or SerialFP2. I don't need them.

I'm sorry, I can't really help then. It was all designed to work the way it is documented. And that was many years ago. In all that time we've not had any other folks reported the problems you seem to have, but then I expect they are following the documentation.

Pete