MarkStallen

Yes stupid, just found it myself. Thanks a lot

I've in my FSUIPC.ini : 6=A32NX_ECAM_SD_CURRENT_PAGE_INDEX=UB66C8 and in my LUA : LastECAM = ipc.readSB("66C8") LastECAM = LastECAM + 1 if LastECAM == 12 then LastECAM = -1 end ipc.writeSB("66C8",LastECAM) Everything works and the LVAR is set in MSFS 2020 except for the moment I write -1 to the variable, then the variable doesn't change. If I look in the aircraft behaviour in MSFS , it's possible to set the variable to -1

Super John, everything is working again. Superb job!!!!

As an example : I've in the ini : 5=A32NX_EFIS_L_OPTION=UB66C6 If I read this address I get the correct value. But if I write to this address the 66C6 changes, but not the LVAR of the aircraft. If I use the button in the simulator itself, then it changes 66C6 correctly

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.

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.

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.

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.

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.

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.

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

Here the HDG lua. HDG.lua

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

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

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