Jump to content
The simFlight Network Forums

Script to read LVAR too slow


Recommended Posts

Hi Peter,

I am writing a script in LUA to read and write LVAR in Offset using, example:

ipc.readLvar("L:XML_Disp_HYDR_PRESS1_1") -- to read the lvar

ipc.writeUB(0x66dc, Disp_HYDR_PRESS1_1 ) -- to write in a offset

The script do not have much more to explain, but this structure repeats to each switch light or annunciator light on the panel (LVARS), the script have more then 90 lvar monitored unitl now.

Current the script expend more than 2 seconds to chage an offset value, when I turn on annunciator test and almost all lights are turned on, offset wait 2, till 3 seconds to modify the value. *LAG

questions...

will do the script faster if I write conditional to determine if lvar is diferent and so write to the offset ?

will do the script faster if I split the script in many scripts ?

wich of them expend more time, associate readLvar to a variable, write in a offset, or conditionals to check if is necessary write the offset?

Is there a event like event.offset to LVAR?

thanks...

Link to comment
Share on other sites

I am writing a script in LUA to read and write LVAR in Offset using, example:

The script do not have much more to explain, but this structure repeats to each switch light or annunciator light on the panel (LVARS), the script have more then 90 lvar monitored unitl now.

Current the script expend more than 2 seconds to chage an offset value, when I turn on annunciator test and almost all lights are turned on, offset wait 2, till 3 seconds to modify the value

Sorry, can you explain what you mean in a little more detail: 2 seconds for each ipc.write? I really can't believe that -- it's up to 1 millisecond assuming the offset write does not trigger further actions in FS as many do.

If you mean that the whole cycle of 90 LVar reads and ipc.writes takes so long, then surely the majority of the time is spent in the Gauges of the specific aircraft getting the LVars? What aircraft is it?

You could make the ipc.writing part much faster by reading all the LVars into a Lua array or individual variables, then writing the whole lot to offsets using one ipc.writeStruct. The writeStruct facility is much more efficient for multiple writes (just as also is the readStruct for reads).

will do the script faster if I write conditional to determine if lvar is diferent and so write to the offset ?

Certainly if the offset being written causes some further action, yes. Otherwise it would be better to use writeStruct.

will do the script faster if I split the script in many scripts ?

That depends. How are you running it? I assume it is loaded only once then running all the time -- if not, that's the man change to make, because loading and compiling a long script is going to take more time than its execution. But otherwise all you are doing is having many threads all trying to read LVars instead of one. If the LVar reading routine in FS is reentrant that might be faster, but otherwise it will be slower.

wich of them expend more time, associate readLvar to a variable, write in a offset, or conditionals to check if is necessary write the offset?

You'd need to use the ipc.elapsedtime function to find that out. I've no idea, though I'd suspect reading the L:Vars is the one taking most time as the rest is only local code in FSUIPC and used in many very fast Lua plug-ins.

Is there a event like event.offset to LVAR?

Not at present. That would mean that FSUIPC would need to be in a loop reading LVars all the time in case one changed. I could consider adding such a facility, but if you used it for 90 LVars I would be concerned that, with the code then running in the main FS thread, it would affect FS performance. However, please do try the example Lua plug-in provided with FSUIPC which logs L:Vars and their changes. See how long that takes with your aircraft.

Can you tell me which aircraft you are testing this with? I could try some experiments here, then, if you wished.

[LATER]

I've just done some testing on calling the L:Var reading routines directly, in the Lua thread, instead of via a message to the main thread (which I thought would be necessary as many FS routines aren't re-entrant so access to them has to be 'regimented' through the normal main thread). So far, with two separate threads reading L:Vars I can't make it crash or go wrong, but that doesn't mean it's safe so I'm not rushing into releasing such a version. But I will pursue it further. Would you like an interim update to test there? What FSUIPC version are you currently using?

Regards

Pete

Link to comment
Share on other sites

Sorry, can you explain what you mean in a little more detail: 2 seconds for each ipc.write?

No Pete... sorry. I don't know exactly how much time the script expends, but I see that in current stage, with until now 138 lvars being read, when a light is turned on on panel, in the offset the value will be changed until 1 second later.

What aircraft is it?

Fokker 100 Digital Aviation

The writeStruct facility is much more efficient for multiple writes (just as also is the readStruct for reads).

Yeah, I thought in this, and I tried to do this with 7-seg digits, but along the way I decided to use a conditional to after read the LVAR, test if the lvar is diferent from current value stored in a Lua global var, after case the values are not equal so write respective offset.

All the script is based in a concept of run in a loop, read the current value from Lvar, test if is diferente from the value stored, writes the new value if not equal and to each lvar the script will repeat this structure.

If I use that concept will be difficult to use writeStruct.

writeStruc must to be used if I write all Lvar, independent if has change. right?

I assume it is loaded only once then running all the time

yes, it load only once and it run all time in a while loop untill I kill the lua or send a parameter diferent of 1

You'd need to use the ipc.elapsedtime function to find that out. I've no idea, though I'd suspect reading the L:Vars is the one taking most time as the rest is only local code in FSUIPC and used in many very fast Lua plug-ins.

If I run FS9 over a network, and I distribute tasks to copy, will the access to the offset faster?

Explaining: A copy for captain's instruments, reading part of lvar, and a copy for first office's instruments to read the rest... If I use FSUIPC with Lua scripts for read lvar and write to offset and shrinking the work load, at the same time each IOCP in his respective computer running a fs9 copy will map his respective offset and comunicate with IOCARDs as clients... Is this a interesting solution to load balance when has a lot of lvar?

Would you like an interim update to test there? What FSUIPC version are you currently using?

3.998q.Yes, if you have any beta, I can try it with you.

Thanks for all...

See you...

Link to comment
Share on other sites

... but I see that in current stage, with until now 138 lvars being read, when a light is turned on on panel, in the offset the value will be changed until 1 second later.

That's odd. with 90 values it was taking 2 seconds, but with 138 it takes only 1 second?

All the script is based in a concept of run in a loop, read the current value from Lvar, test if is diferente from the value stored, writes the new value if not equal and to each lvar the script will repeat this structure.

If I use that concept will be difficult to use writeStruct.

If you are already only writing changes, then why did you ask me? If all you want to do is copy it all over then read all the LVars, then do one (r a few) wrteStructs. Your choice. You asked for advice and that was it.

If I run FS9 over a network, and I distribute tasks to copy, will the access to the offset faster?

Sorry, I don't know what you mean. You can't handle L:Vars from a client.

Explaining: A copy for captain's instruments, reading part of lvar, and a copy for first office's instruments to read the rest... If I use FSUIPC with Lua scripts for read lvar and write to offset and shrinking the work load, at the same time each IOCP in his respective computer running a fs9 copy will map his respective offset and comunicate with IOCARDs as clients... Is this a interesting solution to load balance when has a lot of lvar?

Sorry, I've no idea. I find out such things by experiment.

3.998q.Yes, if you have any beta, I can try it with you.

Try 3.998r,

http://fsuipc.simflight.com/beta/FSUIPC3998r.zip

The LVars are read in the Lua thread in that version, instead of being queued.

Regards

Pete

Link to comment
Share on other sites

Not Found

The requested document was not found on this server.

-----------------------------------

That's odd. with 90 values it was taking 2 seconds, but with 138 it takes only 1 second?

When I asked you in the first time I just read and wrote, but now, I read and I process the value, writing only if not equal from current value wrote in offset. At moment i have 144 LVARS.... and rising...

You asked for advice and that was it.

Ok. my doubt was about the faster method to read numerous LVar and write without lag from aircraft panel to my hardware.

Soon that the zip is available to download I will test the elapsed time, when I finish the script I will add elapsed time routine to determine how is faster.

Thanks

See you...

Link to comment
Share on other sites

Not Found

Odd because the same link is used in the Download Links subforum, where it works perfectly. Go there then. I was placed there at the same time as my last reply to you, three days ago.

Soon that the zip is available to download I will test the elapsed time

It's been available for over three days now. Use the subforum. Don't know why that link is different.

Regards

Pete

Link to comment
Share on other sites

Not Found

The requested document was not found on this server.

The reason why it does not resolve is that the link its pointing to is http://fsuipc.simflight.com/beta/FSUIPC3998q.zip not http://fsuipc.simflight.com/beta/FSUIPC3998r.zip which is what you need. The link in the sub-forums resolves correctly to http://fsuipc.simflight.com/beta/FSUIPC3998r.zip

Link to comment
Share on other sites

The reason why it does not resolve is that the link its pointing to is http://fsuipc.simflight.com/beta/FSUIPC3998q.zip not http://fsuipc.simflight.com/beta/FSUIPC3998r.zip which is what you need. The link in the sub-forums resolves correctly to http://fsuipc.simflight.com/beta/FSUIPC3998r.zip

Ah, mea culpa! Apologies.

Pete

Link to comment
Share on other sites

Okay gentlemen, I just download the 998r and the first impression is amazing.

Pete, the lvar read is now very fast, so fast then I will use the lvar from panel clock, when otherwise I should to write a independent script to clock...

That is the initial impression, more test will be made and I will do a report in here.

how we say in Brazil, literally: The diference is whopping...

now version 998r and the LVAR is faster than ever

The reason why it does not resolve is that the link its pointing to is http://fsuipc.simflight.com/beta/FSUIPC3998q.zip not http://fsuipc.simflight.com/beta/FSUIPC3998r.zip which is what you need. The link in the sub-forums resolves correctly to http://fsuipc.simflight.com/beta/FSUIPC3998r.zip

Thanks alaxus for link...

Thanks Pete...

Edited by Tiago Thiengo Vieira
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.