An efficient way to read a lot of L:Vars?

[dagoston93]

Hi,

I am working on an interface software(C#) between my self-made hardware and FSX.
I am using the A2A C172, and it uses a lot of L:Vars.
My problem is that it seems to be very slow. I don't know if it is because of my computer.

When I call the FSUIPCConnection.Process(); method it feels to be fairly quick, takes around 50 millisecond to process my offsets.

But when i call the necessary ReadLVar() methods  as well, it takes around 500 milliseconds to run,
which is way  too much delay.

I have read in a topic that it is possible  to read LVars with offsets:
Here is the post i mean:

It seems very appealing to read LVars with offsets, but as far as i can understand is it possible to read only one at a time. Is that right?

What would you recommend if i need to work with large amount of LVars?

Would it make sense to try multithreading?

 

Thanks in adcance for any help 🙂

Best regards,

Agoston

 

 

[Paul Henty]

Hi Agoston,

Quote

I have read in a topic that it is possible  to read LVars with offsets:

That's what the DLL does when you call ReadLVAR(). It's just a nicer way of using the offsets provided.

Quote

It seems very appealing to read LVars with offsets, but as far as i can understand is it possible to read only one at a time. Is that right?

Yes only one LVAR can be read or written for each process() call. That's just how FSUIPC works with LVARS. When you use ReadLVAR() in the DLL it does a process call.

When you need to read a lot of LVARS then the time adds up. On my machine with FSX and default aircraft it takes about 20ms to get one LVAR. So reading 25 lvars will take half a second for me.

Quote

Would it make sense to try multithreading?

No it won't make it faster. FSUIPC communicates on a single thread. The DLL is 'thread safe' which means if you use it from multiple threads  and nothing bad will happen. But each thread will have to wait for the others to make Process calls. Only one thread can be talking to FSUIPC at a time.

Quote

What would you recommend if i need to work with large amount of LVars?

You could look into SimConnect. It's not very easy to use from .NET languages and the documentation is very poor for .NET. It might let you read LVARS faster, but I don't know.

The LUA scripting in FSUIPC also allows you to read LVARS and also monitor them for changes (an LUA event is fired). You could write a LUA script to monitor your LVARs and send the values to user offsets where you can read them from your program.

LUA scripts can only be run with a licensed copy of FSUIPC however. Documentation for the LUA library can be found in the Modules/FSUIPC Documents folder.

 

Paul

[dagoston93]

Hi,

Thank you very much for the quick reply 🙂

Yes, i have my experience with SimConnect... it was a disaster to use. I could not find a way to acces local variables with using only sim connect(maybe there is but as you mention, documentation was very poor...), so i had to work around the problem by writing a C gauge that could acces LVars and fired Win32 events to communicate with my c# program...that was really unefficient i think. Didn't measure time back then but it was very difficult to work  that way.

Thats why i tried your library 🙂 It makes everything so much easier.

I will look into the LUA solution. I hope it will make things as quick as i need 🙂

Thanks again, and best regards,

Agoston

 

[dagoston93]

Hi,

I have upgraded to the paid version of FSUIPC and tried the solution you suggested with Lua.

It works like a charm, thank you very much for that.

My question is if there are other offsets available  for custom use or just the 64 bytes beginning at 0x66C0?

Thanks in advance,

Agoston

 

[Paul Henty]

Good to hear that worked.

Quote

My question is if there are other offsets available  for custom use or just the 64 bytes beginning at 0x66C0?

These are the only official user offsets.

However, if your application is only for your use you can try using the blocks marked as reserved. These are allocated to third-party software. For example 0x04E0 (88 Bytes) is for Project Magenta software. If you don't use that then you could try that block. Or there is a block from 0x6420 to 0x65EC (640 bytes) which is for PMDG aircraft if you don't have those.

If your software is for general release (free or commercial) then you need to ask Pete (in the main support forum) for some offsets to be allocated for you so you don't clash with other software.

Paul

[dagoston93]

Hi,

Thanks a lot 🙂

I am developing for my own use right now. So i will try the PMDG block because I am using A2A Cessna 172 to build my home cockpit, so for sure using PMDG block it wont cause any problem 🙂

Thanks again 🙂

Greetings,
Agoston

[dagoston93]

Hi,

It's meg again 🙂

I have tried using the PMDG's offsets but they don't seem to be working.
But luckily Project Magenta's offsets work so combined with the allocated user offsets i seem to have enough space.

Now updating all info i need on the c# side is really qick using just a single Process() call, around 50 ms.

But the situation on the Lua seems to be a lot worse.
I decided to check the time the Lua needs to update all my offsets and it seems that it takes nearly 4 seconds to update them.

Maybe i am doing something wrong?

Here is my code:

while 1 do
	local time = os.clock()
	-- Data for flight instruments
	airSpeed = ipc.readLvar("L:AirspeedIndicatedNeedle")
	ipc.writeFLT(0x66C0, airSpeed)
	
	heading = ipc.readLvar("L:HeadingGyro")
	ipc.writeFLT(0x66C4, heading)

	attitudeIndicatorGyroFlag = ipc.readLvar("L:AttitudeIndicatorFlag")
	ipc.writeUB(0x66DC, attitudeIndicatorGyroFlag)	

	-- Data for navigation instruments
	cdi1Needle = ipc.readLvar("L:Cdi1Needle")
	ipc.writeFLT(0x66CC, cdi1Needle)

	gsi1Needle = ipc.readLvar("L:Gsi1Needle")
	ipc.writeFLT(0x66D0, gsi1Needle)

	cdi2Needle = ipc.readLvar("L:Cdi2Needle")
	ipc.writeFLT(0x66D4, cdi2Needle)

	adfCdiNeedle = ipc.readLvar("L:AdfCdiNeedle")
	ipc.writeFLT(0x66D8, adfCdiNeedle)

	nav1ObsNeedle = ipc.readLvar("L:Nav1ObsNeedle")
	nav1ObsNeedle = nav1ObsNeedle * 10
	ipc.writeSW(0x66DD, nav1ObsNeedle)
	
	nav1ToFromFlag = ipc.readLvar("L:ToFrom1Needle")
	ipc.writeUB(0x66DF, nav1ToFromFlag)

	nav1GsiFlag = ipc.readLvar("L:Gsi1Flag")
	ipc.writeUB(0x66E0, nav1GsiFlag)

	nav2ObsNeedle = ipc.readLvar("L:Nav2ObsNeedle")
	nav2ObsNeedle = nav2ObsNeedle * 10
	ipc.writeSW(0x66E1, nav2ObsNeedle)

	nav2ToFromFlag = ipc.readLvar("L:ToFrom2Needle")
	ipc.writeUB(0x66E3, nav2ToFromFlag)

	adfHeadingNeedle = ipc.readLvar("L:AdfHdgNeedle")
	adfHeadingNeedle = adfHeadingNeedle * 10
	ipc.writeSW(0x66E4, adfHeadingNeedle)

	-- Data for engine instruments
	engOilPressure = ipc.readLvar("L:Eng1_OilPressure")
	ipc.writeFLT(0x66C8, engOilPressure)

	fuelLeft = ipc.readLvar("L:FuelLeftWingTank")
	ipc.writeFLT(0x66E6, fuelLeft)

	fuelRight = ipc.readLvar("L:FuelRightWingTank")
	ipc.writeFLT(0x66EA, fuelRight)

	egt = ipc.readLvar("L:Eng1_EGTGauge")
	ipc.writeFLT(0x66EE, egt)

	fuelFlow = ipc.readLvar("L:Eng1_GPH")
	ipc.writeFLT(0x66F2, fuelFlow)

	tachometer = ipc.readLvar("L:Eng1_RPM")
	ipc.writeSD(0x04E4, tachometer)	

	oilTemp = ipc.readLvar("L:Eng1_OilTemp")
	ipc.writeFLT(0x04E8, oilTemp)

	ammeter = ipc.readLvar("L:Ammeter1")
	ipc.writeFLT(0x04EC, ammeter)


	
	-- Data for the radios

	com1OnOff = ipc.readLvar("L:Com1OnOff")
	ipc.writeUB(0x04F0, com1OnOff)

	com2OnOff = ipc.readLvar("L:Com2OnOff")
	ipc.writeUB(0x04F1, com2OnOff)

	nav1ElecPwr = ipc.readLvar("L:Nav1RadioOn")
	ipc.writeUB(0x04F2, nav1ElecPwr)
	
	nav2ElecPwr = ipc.readLvar("L:Nav2RadioOn")
	ipc.writeUB(0x04F3, nav2ElecPwr)
	
	nav1Ident = ipc.readLvar("L:Nav1PullIdent")
	ipc.writeUB(0x04F4, nav1Ident)
	
	nav2Ident = ipc.readLvar("L:Nav2PullIdent")
	ipc.writeUB(0x04F5, nav2Ident)

	isAdfOn = ipc.readLvar("L:AdfOnOffKnob")
	ipc.writeUB(0x04F6, isAdfOn)

	adfElecPwr = ipc.readLvar("L:AdfRadioOn")
	ipc.writeUB(0x04F7, adfElecPwr)

	adfModeOn =  ipc.readLvar("L:AdfAdfButton")
	ipc.writeUB(0x04F8, adfModeOn)

	adfBfoOn =  ipc.readLvar("L:AdfBfoButton")
	ipc.writeUB(0x04F9, adfBfoOn)

	adfKnobPull =  ipc.readLvar("L:AdfFreqInnerKnobPull")
	ipc.writeUB(0x04FA, adfKnobPull)

	transponderMode = ipc.readLvar("L:xpdr_onoff_knob_pos")
	ipc.writeUB(0x04FB, transponderMode)

	transponderElecPwr = ipc.readLvar("L:AvionicsElecPower")
	ipc.writeUB(0x04FC, transponderElecPwr)

	isDmeOn = ipc.readLvar("L:kn62OnOff")
	ipc.writeUB(0x04FD, isDmeOn)

	dmeMode = ipc.readLvar("L:kn62Function")
	ipc.writeUB(0x04FE, dmeMode)

	isGpsOn = ipc.readLvar("L:GpsOnSwitch")
	ipc.writeUB(0x04FF, isGpsOn)

	audioPanelNav1 = ipc.readLvar("L:kma26Nav1Switch")
	ipc.writeUB(0x0500, audioPanelNav1)

	audioPanelNav2 = ipc.readLvar("L:kma26Nav2Switch")
	ipc.writeUB(0x0501, audioPanelNav2)

	audioPanelMkr = ipc.readLvar("L:kma26MkrSwitch")
	ipc.writeUB(0x0502, audioPanelMkr)

	audioPanelDme = ipc.readLvar("L:kma26DmeSwitch")
	ipc.writeUB(0x0503, audioPanelDme)

	audioPanelAdf = ipc.readLvar("L:kma26AdfSwitch")
	ipc.writeUB(0x0504, audioPanelAdf)

	audioPanelSelector = ipc.readLvar("L:kma26SelectorKnob_pos")
	ipc.writeUB(0x0505, audioPanelSelector)

	-- Switch and lever positions
	-- For some reason 0x0506, 0x0507, 0x0509 don't work so replaced by later offsets
	alternatorSwitch = ipc.readLvar("L:Eng1_GeneratorSwitch")
	ipc.writeUB(0x051A, alternatorSwitch)

	batterySwitch = ipc.readLvar("L:Battery1Switch")
	ipc.writeUB(0x051B, batterySwitch)

	ignitionSwitch = ipc.readLvar("L:Magnetos1Pct")
	ipc.writeUB(0x0508, ignitionSwitch)

	fuelSelectorSwitch = ipc.readLvar("L:FSelC172State")
	ipc.writeUB(0x051C, fuelSelectorSwitch)

	fuelCutoffSwitch = ipc.readLvar("L:Eng1_FuelCutOffSwitch")
	ipc.writeUB(0x050A, fuelCutoffSwitch)

	trimPosition = ipc.readLvar("L:TrimtabPosition")
	ipc.writeFLT(0x050B, trimPosition)

	throttlePosition = ipc.readLvar("L:Throttle1Position")
	ipc.writeFLT(0x050F, throttlePosition)

	mixturePosition = ipc.readLvar("L:Eng1_MixtureManualLever")
	ipc.writeFLT(0x0513, mixturePosition)

	gpsNavSwitch = ipc.readLvar("L:GpsModeLight")
	ipc.writeUB(0x0517, gpsNavSwitch)

	flapsLeverPosition = ipc.readLvar("L:LandFlapsPos")
	ipc.writeUB(0x0518, flapsLeverPosition)

	altStaticAir = ipc.readLvar("L:StaticAir")
	ipc.writeUB(0x0519, altStaticAir) 
	-- Next available offset: 0x051D

	-- Annunciator panel Data
	annPanelLowFuel = ipc.readLvar("L:FuelLight")
	ipc.writeUB(0x051D, annPanelLowFuel)

    annPanelLowFuelL = ipc.readLvar("L:FuelLLight")
    ipc.writeUB(0x051E, annPanelLowFuelL)
	
	annPanelLowFuelR = ipc.readLvar("L:FuelRLight")
    ipc.writeUB(0x051F, annPanelLowFuelR)
	
	annPanelPitchTrim = ipc.readLvar("L:PitchTrimLight")
	ipc.writeUB(0x0520, annPanelPitchTrim)

    annPanelOilPress = ipc.readLvar("L:OilPressLight")
	ipc.writeUB(0x0521, annPanelOilPress)

    annPanelVac = ipc.readLvar("L:VacLight")
	ipc.writeUB(0x0522, annPanelVac)
    
	annPanelVacL = ipc.readLvar("L:VacLLight")
	ipc.writeUB(0x0523, annPanelVacL)

    annPanelVacR = ipc.readLvar("L:VacRLight")
	ipc.writeUB(0x0524, annPanelVacR)

    annPanelVolts = ipc.readLvar("L:VoltsLight")
	ipc.writeUB(0x0525, annPanelVolts)

    annPanelSwitchPos = ipc.readLvar("L:AnnunciatorPanelTestSwitch")
	ipc.writeUB(0x0526, annPanelSwitchPos)

	ipc.display(string.format("elapsed: %.4f\n", os.clock() - time))
end

Also the log file of my Lua script in the Modules folder looks strange.
 

 2024641 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:13
  2024656 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:15
  2024656 LUA: Local: time = 2024.651
  2024656 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:16
  2024656 LUA: Global: airSpeed = 0.012498825303282
  2024703 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:18
  2024703 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:19
  2024719 LUA: Global: heading = 312.2686369365
  2024766 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:21
  2024766 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:22
  2024828 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:25
  2024828 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:26
  2024828 LUA: Global: cdi1Needle = 46.609531300374
  2024891 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:28
  2024891 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:29
  2024953 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:31
  2024953 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:32
  2024953 LUA: Global: cdi2Needle = 53.390503277407
  2025000 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:34
  2025000 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:35
  2025063 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:37
  2025063 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:38
  2025063 LUA: Global: nav1ObsNeedle = 27
  2025078 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:39
  2025078 LUA: Global: nav1ObsNeedle = 270
  2025125 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:41
  2025125 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:42
  2025188 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:44
  2025188 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:45
  2025250 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:47
  2025250 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:48
  2025250 LUA: Global: nav2ObsNeedle = 117
  2025250 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:49
  2025250 LUA: Global: nav2ObsNeedle = 1170
  2025297 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:51
  2025313 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:52
  2025359 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:54
  2025359 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:55
  2025359 LUA: Global: adfHeadingNeedle = 170
  2025375 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:56
  2025375 LUA: Global: adfHeadingNeedle = 1700
  2025422 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:59
  2025422 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:60
  2025422 LUA: Global: engOilPressure = 65.36714720856
  2025484 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:62
  2025484 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:63
  2025484 LUA: Global: fuelLeft = 13.288883924031
  2025547 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:65
  2025547 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:66
  2025547 LUA: Global: fuelRight = 12.178045634074
  2025609 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:68
  2025609 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:69
  2025609 LUA: Global: egt = 1171.4484418552
  2025656 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:71
  2025656 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:72
  2025672 LUA: Global: fuelFlow = 2.0379332020828
  2025719 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:74
  2025719 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:75
  2025719 LUA: Global: tachometer = 1043.8934864848
  2025781 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:77
  2025781 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:78
  2025781 LUA: Global: oilTemp = 83.864938908228
  2025844 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:80
  2025844 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:81
  2025844 LUA: Global: ammeter = 23.541568853379
  2025906 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:87
  2025906 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:88
  2025953 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:90
  2025969 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:91
  2026016 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:93
  2026016 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:94
  2026078 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:96
  2026078 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:97
  2026141 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:99
  2026141 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:100
  2026203 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:102
  2026203 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:103
  2026266 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:105
  2026266 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:106
  2026313 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:108
  2026328 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:109
  2026375 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:111
  2026375 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:112
  2026438 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:114
  2026438 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:115
  2026500 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:117
  2026500 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:118
  2026563 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:120
  2026563 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:121
  2026625 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:123
  2026625 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:124
  2026672 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:126
  2026688 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:127
  2026734 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:129
  2026750 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:130
  2026797 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:132
  2026797 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:133
  2026859 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:135
  2026859 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:136
  2026922 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:138
  2026922 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:139
  2026984 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:141
  2026984 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:142
  2027047 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:144
  2027047 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:145
  2027109 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:147
  2027109 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:148
  2027156 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:150
  2027156 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:151
  2027219 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:155
  2027219 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:156
  2027281 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:158
  2027281 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:159
  2027344 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:161
  2027344 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:162
  2027406 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:164
  2027406 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:165
  2027453 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:167
  2027469 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:168
  2027516 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:170
  2027516 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:171
  2027578 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:173
  2027578 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:174
  2027641 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:176
  2027641 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:177
  2027703 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:179
  2027703 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:180
  2027766 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:182
  2027766 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:183
  2027828 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:185
  2027828 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:186
  2027891 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:190
  2027891 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:191
  2027938 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:193
  2027953 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:194
  2028000 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:196
  2028000 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:197
  2028063 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:199
  2028063 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:200
  2028125 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:202
  2028125 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:203
  2028188 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:205
  2028188 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:206
  2028250 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:208
  2028250 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:209
  2028297 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:211
  2028297 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:212
  2028359 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:214
  2028359 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:215
  2028422 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:217
  2028422 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:218
  2028484 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:220

I noticed that after  most of the lines where i write a variable, its value gets logged.
But i noticed that some of them don't get logged. Like nothing is logged after line 81.
First i thought tha only the values that are different from their previous values get logged. 
But as i scrolled further down i noticed that for example the adfHeadingNeedle's value doesnt change and still gets logged.
Is this behaviour of the logging normal?

My software seems to get all the data, but some of them with significant delays.
For example when a light flashes on the annunciator panel, in FSX it is a consistent flashing but when it gets to the c# code,
it just seems to be a mess. Sometimes it doesnt even come on. 

When I write just one Lvar to an offset it takes around 60ms. So similar to a process call.
Am i doing something wrong that it is so slow?

Is there a faster way that i ignored?

Thanks in advance, best regards,

Agoston

[Paul Henty]

I'm not sure an infinite loop is the best way to do this.

You might have better performance using the event system. This monitors the LVar values in the background and fires an event when they change.

Here's an example from another user...

writeN1(varname, value) 
   ipc.writeUB(0x66C0, value) 
end
event.Lvar("B200CFuelCrossfeed", 100, "writeN1")

writeN2(varname, value) 
   ipc.writeUB(0x66C1, value) 
end
event.Lvar("B200CRvsNotReady", 100, "writeN2")

writeN3(varname, value) 
   ipc.writeUB(0x66C2, value) 
end
event.Lvar("B200CLBld", 100, "writeN3")

writeN4(varname, value) 
   ipc.writeUB(0x66C3, value) 
end
event.Lvar("B200CRBld", 100, "writeN4")

You declare a function that sets the value to the offset and then register this with the event system (event.Lvar). See the FSUIPC Lua docs for full details but in summary the call is:

event.Lvar(lvarName, polling_interval_in_ms, function_to_run)

If you prefer you can make only one function that is called by all the events. This would need to test the LVAR name (varname argument) and write to the correct offset.

I don't know about the logging as I don't use lua at all. You'll need to ask Pete about that in the main support forum.

Paul

[Pete Dowson]

9 hours ago, dagoston93 said:

First i thought tha only the values that are different from their previous values get logged. 
But as i scrolled further down i noticed that for example the adfHeadingNeedle's value doesnt change and still gets logged.
Is this behaviour of the logging normal?

It only logs changes. Your extract only shows two entries for adfHeadingNeedle:

  2025359 LUA: Global: adfHeadingNeedle = 170
  2025375 LUA: ...\Microsoft Flight Simulator X\Modules\DiamontSim.lua:56
  2025375 LUA: Global: adfHeadingNeedle = 1700

They certainly don't look the same to me!

And Paul is correct. It would be much more efficient to use events. Let FSUIPC do the LVar scanning.

Pete

 

[dagoston93]

Hi,

Thanks for your answers.
I have tried using the event system, but for a strange reason i am having even worse results...
 

Here is the code:

function writeAirSpeed(varname, value)
	ipc.writeFLT(0x66C0, value)
end

event.Lvar("L:AirspeedIndicatedNeedle", 100, "writeAirSpeed")
	
function writeHeading(varname, value) 
	ipc.writeFLT(0x66C4, value)
end

event.Lvar("L:HeadingGyro", 100, "writeHeading")

function writeAdfCdiNeedle(varname, value) 
	ipc.writeFLT(0x66D8, value)
end

event.Lvar("L:AdfCdiNeedle", 100, "writeAdfCdiNeedle")

As long as i subscribe to only one event or two i am having no trouble, performance is great.

But already when i add the third one, one of the values get updated rarely, while the other two works fine. In this case the airspeed just gets refreshed every few seconds only.
First i have tried with a lot more values with similar results but then the values at the end of the code didnt get regular update.
I have read in the documentation that the minimum interval for polling is 100ms. So i have set the minimum value for every event, because i want to achieve the maximum refresh rate possible.
I have read somewhere that same type of events don't get queued if they are not handled fast enough.
Might something like that be happening in my case?

I created separate functions for each value so that it won't take extra time to process which value needs to go to which offset.

Is there anything I am overlooking?

And about the logging now i get it. I forgot that though the value coming from FSX is the same, but I am changing it before writing it to the offset, so the actual value changes.
Thank you for pointing it out 🙂 Now I understand more about logging 🙂

Thanks in advance, best regards,

Agoston

 

[Pete Dowson]

I've moved this thread to the Support Forum proper, where it more reasonably belongs now.

I wish there was a quicker way to read a big batch of L:Vars, but I'm afraid there isn't. Or at least not one I know about.  Each read involves two separate calls into other code, code which is mainly to do with the add-on creating the LVar. The first call requests the ID number of the named LVar, and the second actually reads it.

The overhead of using a Lua plug-in instead of your C# program is huge as well. Lua plug-ins are really no substitute for a proper compiled program. The system was never intended to be such. To start with the plug-ins are interpreted, as a script. then FSUIPC delberately introduces delays ("sleeps") between operations involvng outside agencies, such as the LVar provisions, so that there's no impact upon the mainstream operations of the simulator.

I don't really understand why you have so many LVars changing all the time. How is that? Or are you only talking about getting something initialised? If it is initialisation, then the time taken is surely trivial.

There is a supplied plug-in called Log lvars.lua which scans the LVars by ID (0 to 65535 max) to get the names then reads them to see if they've changed. That's always worked well, displaying the changes as they occur. Is that also overloaded by your aircraft?

Pete

1 hour ago, dagoston93 said:

I have read in the documentation that the minimum interval for polling is 100ms. So i have set the minimum value for every event, because i want to achieve the maximum refresh rate possible.

Why?  What is so important about getting a high rate of changes received?  It looks, from the names of the values you are reading, that this is for main aircraft instrumentation. If so then surely the aircraft maker offers a better way than just LVar access?  That is really unsuitable for hardware implementation no matter how you program it.

1 hour ago, dagoston93 said:

I have read somewhere that same type of events don't get queued if they are not handled fast enough.

There is no queuing for events at all. There is only one flag per registered event. If the value represented changes faster than the Lua plug-in can process them, the program will only get the latest value. That is surely as one would expect. You wouln't want them fed one at a time gradually getting later and later compared to reality!

But each LVar you create an event for will have a separate entry, a separate "changed" flag, and a separate entry in the value table. There is no specific limit -- the tables involved are not fixed tables in a defined space but chained allocated memory blocks. allocated as necessary.

So you shouldn't be losing any changes at all. However, by using the minimum polling interval for multiple events your Lua thread will be spending most of its time doing nothing else. You either need a larger polling interval or separatre threads (separate plug-ins) for each. Then watch your P3D performance carefully.

In the end I think you are trying to use simple Lua scripting in ways not really intended. As a way of testing things they are excellent. They are also good for extending the facilities of FSUIPC to do more things. But they are really no substitute for a properly interfaced compiled program. I certainly wouldn't use Lua to drive my hardware -- I wrote C/C++ programs for my PFC MIP, PFC centre console and flight controls, Cockpitsonic forward overhead, and Sismo aft overhead.

I just use small Lua plug-ins for my Flight Illusion clocks and a couple of replacement gauges (replacing single needles for dual needles on pressurization and duct pressure gauges), and to release the 737 magnetic starter latches when the engines start -- the latter work via an Arduino program too.

The only use of LVars on my system are for the 8 different doors which can be openedsed and closed on the Prosim 738 I use -- they used LVars for that purpose as the door control facilities in P3D are limited to just 4.

Pete

 

[dagoston93]

Hi,

Yeah, i forgot to give details what i am trying to achive in the end.

So I am designing a home cockpit of a C172. I chose to use an A2A C172 in FSX because it is modelled extremely realistically.
But i went the unconventional way and decided to build each gauge with stepper and servo motors and real needles instead of just putting an LCD behind the instrument panel.
And that is why i want to achive the maximum possible refresh rateof these data.

And that decision is causing a lots of headaches now... 🙂

On the hardware side I am using an Arduino mega and some custom design board to read a bunch of rotary encoders, a switch matrix, a LED control panel that can control up to 1024 LEDs, a stepper and a servo motor controller board. And I am using a C# applicatiuon with FSUIPCClient.dll to conenct arduino with FSX. 

The main problem is that A2A stores a lot of data in LVars.

They provide a nice pdf file with the list of LVars for home cockpit builders on their website. But I couldnt find any information about them providing a more efficient way to interface the airplane.

My first approach was to use SimConnect but for that i had to write a C gauge to send LVars to the C# program, and that seemed to be a way to complicated, but i havent done a speed test with that method unfortunately.

Now i started to think if it is possible to access fsuipc offsets with xml gauges, and if that would make any difference if i tried to write LVars to offsets that way...

Have you got any suggestions?

Or maybe should I chose a different model as the base of the sim?

Is there any realistic C172 model that can be well interfaced with FSUIPC?

Thanks in advance for any help,

Agoston

[Pete Dowson]

12 hours ago, dagoston93 said:

Have you got any suggestions?

If writing your interface in C# as in your first message here is too slow, then, no, not via L:Vars.

However, surely most of the faster changing values you need for instruments are just standard native FS values, which are supplied at the frame rate or better via offsets already. Heading, speed, altitude, and so on. What are you looking for not already supplied with well supported offsets?

The only things for which you need to find alternatives are those few subsystems which are specifically added or implemented in the add-on model and not part of the underlying simulation engine, and of course those controls (switches etc) associated with them. Surely for a C172 there's not many (if any) of either.

I have a cockpit originally made by Aerosoft Australia which is for a Piper Arrow III. It has all analogue gauges and I wrote a driver for it which only uses normal FSUIPC offsets and it works beautifully. I've gone through several aircraft models from add-ons over the years -- I think my current one is from Carenado, but it may not be (I'm afraid I've been too busy on my 737NG cockpit recently to have flown VFR for a while).

As far other possible aircraft models, sorry, I don't know. I think Carenado and Alabeo do C172 models, but I don't know if they are any more suited to cockpit instrumentation other than via the normal sim values and related offsets. Best to ask on somewhere like the AVSIM forums.

Pete

 

 

[dagoston93]

Hi,

I think many of the LVars could be replaced by native FS values, but definitely not all, and probably would lose some nice details of this beautiful addon A2A has created.

For example i did a test with the airspeed indicator. I compared the value of the LVar and the default value and I had to realise that the A2A LVar introduces the delay of the ASI, making it more realistic than the default one. (In stationary flight the values are quite the same.) So if there is a way, I would like to keep all the details possible.

So i started to think a bit. And i remembered the first way of approach I wanted to make the whole thing work. I used a C gauge to get data from FSX sending values to a SimConnect based C# application. I was wondering if it would be possible to read the LVars in the gauge, (thinking it would surely be faster to access LVars that way, since it is supposed to be running in the gauge system of the FSX) and then write those variables to FSUIPC offsets. I knew it was possible to read and write LVars via a C gauge but I was wondering if it is possible to access FSUIPC. (I was thinking there has to be a way, otherwise how would PMDG and other developers use FSUIPC offsets??) So I started goooooooogling a bit 🙂

And found this forum topic answered by yourself a few years back:

https://www.avsim.com/forums/topic/224015-how-to-reach-panel-parameters/

In your post on November 14, 2006 you wrote: 

Quote

Well, this is one of the things folks used FSUIPC offsets for. They would ask me to reserve some offsets into which, from the panel, they could write data. This could then be read by an external program interfacing to FSUIPC or WideFS.

  So that made me think I am on the right path, but could not find any examples how to access FSUIPC from the gauge system. Either from XML (if even possible) or C.

Do you think it is a good idea, or would it not make that much of a difference? If so could you please provide me with an example how to do that?

And the way you began your last answer to me made me think as well:

Quote

If writing your interface in C# as in your first message here is too slow, then, no, not via L:Vars.

Would you have suggestion if i used a different language? And if so what language should I go for?

Thank you very much in advance for your help, best regards,

Agoston

[Pete Dowson]

6 hours ago, dagoston93 said:

I compared the value of the LVar and the default value and I had to realise that the A2A LVar introduces the delay of the ASI, making it more realistic than the default one.

Hm, interesting I didn't now there were supposed to be delays! Most times you see it on gauges it is because of poor coding! 😉

I'm surely you could handle that quite easily in your interface to your gauge.

6 hours ago, dagoston93 said:

So i started to think a bit. And i remembered the first way of approach I wanted to make the whole thing work. I used a C gauge to get data from FSX sending values to a SimConnect based C# application. I was wondering if it would be possible to read the LVars in the gauge, (thinking it would surely be faster to access LVars that way, since it is supposed to be running in the gauge system of the FSX) and then write those variables to FSUIPC offsets. I knew it was possible to read and write LVars via a C gauge but I was wondering if it is possible to access FSUIPC

I suspect the gauge would have to use the exact same Gauge SDK functions which FSUIPC does, so I'm not sure how much advantage that would confer.

But, yes, except for XML gauges (which aren't strictly programs as such), you can access FSUIPC offsets from a C/C++ DLL or Gauge (which is only a DLL in any case). you have to use the Module Users interface, for which there's a separate little package in the SDK.

6 hours ago, dagoston93 said:

Would you have suggestion if i used a different language? And if so what language should I go for?

I use C or C++.  C# is a "managed" language, which imposes an overhead. C is about as efficient as you can get without resorting to machine code.

I'm on holiday now for a few weeks. John may be able to help with any further questions.

Pete

 

[dagoston93]

Hi, 

Thanks for your help.

Yes, the ASI has some delay in real life if you make sudden change in airspeed 🙂 But if it is too much it may be because of poor programming as well 🙂

I will have a go and try to read some data from a C gauge then. I will see if i can have a little better performance.  

Thanks for your help. I will post if i get stuck and we will see if John or someone may be able to answer 🙂

Have a great holiday, best regards

Agoston

[dagoston93]

Hello 🙂

Just to let you know I managed to get the code working 🙂

 I wrote a C gauge that reads LVars and puts them in the FSUIPC offsets, using your Module User library of the FSUIPC SDK.

Haha, it took me nearly two whole days to find all information and to get everything working but finally up and running. 🙂
It seems to be significantly quicker to access offsets and LVars from within a C gauge. I can't notice any significant delay now 🙂

Ohh, and also did some timing on the Lua solution before started the C gauge. It took only 8 ms to read a single LVar but 50-60 ms to put it in the offsets...strange...I thought accessing the LVars was the slower part.

Thanks for all the help 🙂

I hope now everything will work like a charm 🙂 

Best regards,

Agoston

[Pete Dowson]

10 minutes ago, dagoston93 said:

It seems to be significantly quicker to access offsets and LVars from within a C gauge. I

Well, yes, it certainly should be! You are basically becoming part of the add-on aircraft.

11 minutes ago, dagoston93 said:

It took only 8 ms to read a single LVar but 50-60 ms to put it in the offsets

You mean the ipc.writes? That's rather odd. There's no built-in delay for those, though there would be for the LVar reads.

Pete

 

 

[dagoston93]

Yes, I mean the ipc.write()-s.
But it might be just on my system, or also might not be doing the most precise time checking.
I used the os.clock() and then the ipc.display() to display it.

Agoston

[gr8guitar]

Hello. I am able to read an offset and insert a value into a Lvar. However, per Paul Henty and dagoston93 examples above, I attempted to have a Lvar value being inserted into an offset 66CD as follows; with no luck (the Lvar exists). I am using the FSUIPC logging option to check 66CD:

function writeFDCmdr(varname, value)

   ipc.writeUW(0x66CD, value)

end

event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr")

BTW: Shouldn't the ipc.readLvar(Lvar name) be used first? I did try it but to no avail. Do any of you see an obvious reason why the above lua doesn't work?

I tried this too, with no success:

 

function writeFDCmdr(varname, value)

  ipc.writeFLT(0x66CD, value)

end

writeFDCmdr("CpitCmdrSetValue",ipc.readLvar("CpitCmdrSetValue"))

event.Lvar("CpitCmdrSetValue",100,"writeFDCmdr")

 

also, is there a way to reload a lua without having to shutdown FS and restart it?

 

 

Edited September 12, 2020 by gr8guitar
a new try

[spokes2112]

This is just a hunch as I have run into this with the MaddogX. I also noticed other advanced aircraft use this procedure.
The L:Var "CpitCmdrSetValue" sure does sound like it is a command to do something with the internal programming / logic  of the aircraft.
EX. Sending the value 12258597 to the L:Var will open the map box, just an example.
In the gauge logic it would be something like - ( in XML ) 

<Update>
	(L:CpitCmdrSetValue, number) 0 != if{
	
		<!-- Open the map box -->
		12258597 (L:CpitCmdrSetValue, number) == if{
			<!-- Provide code for animating the map box opening -->
		}
	
		<!-- Close the map box -->
		12258598 (L:CpitCmdrSetValue, number) == if{
			<!-- Provide code for animating the map box closing -->
		}
	
		<!-- This resets the L:Var -->
		0 (>L:CpitCmdrSetValue, number)
	}
</Update>

As you can see, if the L:Var is zero it bypasses most of the code.
If the L:var is not zero then it will find what value matches, then do something.. After that it resets the L:Var back to zero. This is the key part. The gauge system is much faster (55 msecs) versus the L:Var polling of the lua (100 msecs).
What may be happening with you is that yes, the L:Var is changing, but it is returning to zero so fast that the lua is not picking it up.

It sounds like you would like to find out what the value is to, later on, maybe do something. IE provide a custom command thru a L:Var or have some kind of indication. If this is the case you could try it in the following Lua. Note - you still may have to toggle the L:Var command a few times before the lua will catch the value, after that, at least, you will have the necessary value. 

function writeFDCmdr(varname, value)
	if value ~= 0 then
		ipc.writeUW(0x66CD, value)
	end
end

event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr")

Again just a hunch.. May be way out of the ballpark too 😉

Roman

1 hour ago, gr8guitar said:

also, is there a way to reload a lua without having to shutdown FS and restart it?

Yes.. Just assign a keyboard key to the dropdown command "Lua <lua name>" ( not LuaKill, LuaToggle, LuaSet or LuaClear)

[gr8guitar]

Hello spokes2112. Thank you for your reply. Actually CpitCmdrSetValue is a Lvar from Glenn Copeland's Cockpit Commander gauge. It can be found at library.avsim.net or flightsim.com, or at least it used to be there. It is a great gauge in that it's easy to insert data directly for Nav/Com and autopilot parameters. It has a "keyboard" of numbers, so say you want the AP altitude to be 8500. Just "type" 8500, then hit the ALT button and that value goes into AP's altitude. btw: when the ALT button is "pressed" CpitCmdrSetValue is set to 0 (zero). This is required so a new value can be inserted. It's really nice for the Nav/Com frequencies. I've taken that gauge and added more features for my own use. Now use that function along with WideFS on a touchscreen tablet and life is easy. However, unless there is a way that I don't know about (high possibility), I can't see the L:CpitCmdrSetValue on the remote computer. The next step I took was to implement this idea using Excel. Excel talks to FSUIPC rather nicely with the offsets. I don't know if Excel can talk to Lvar's, that would be even easier, if so, what is the format for a Lvar in Excel? I know Excel can talk to the offsets so if I can move the Lvar into an offset, I can see that value on the tablet. Thanks for the lua tip.

[spokes2112]

Downloaded and took a quick  look at it.
Ahh that's it.. My hunch was kind of right.
On every one of the click commands (the ones that finalize something)  lines 182-366, somewhere in each of those click spots is the command ( an instant reset, faster than 1 msec ) :

0 (>L:CpitCmdrSetValue, number)

Your original lua should pick up on each numerical digit as it's pressed and added up only to the point prior to sending to a radio / ap command. 
Will install his gauge and make a lua for my sacrificial aircraft to test more.

Never used excel in FS, probably never will. In all the "weird" stuff i've ever created, either a xml gauge, advanced FSUIPC.ini programming or lua fits my needs. - sorry. 

Roman

EDIT... Are you running this L:Var detection lua on the local or the WideFS machine? If on the WideFS machine it will not work as stated in the FSUIPC Lua Library.pdf. If you run the L:Var detection on the sim machine, then use event.Offset on the WideFS machine it should work then.

[spokes2112]

Just got done testing on the local FS machine, the only way L:Var detection via Lua will work.
Works fine except... You should write to the offset as a 32bit float. The frequency values are floats, but they have rounding errors! That can be fixed on the WideFS lua.

function writeFDCmdr(varname, value)
		ipc.writeFLT(0x66CD, value)	
end

event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr")

 

[gr8guitar]

Hello spokes2112. Thank you for your info. I did change the datatype to FLT and the lua is running on the local pc (with FS runnning). Still nothing, strange. I see you have it working on yours!!! Will keep plugging. Glenn Copeland's gauge is pretty cool as it brings some flight operations into the "digital" age. BTW, any math errors can also be corrected with Excel.