Tiago Thiengo Vieira Posted January 12, 2012 Report Posted January 12, 2012 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...
Pete Dowson Posted January 12, 2012 Report Posted January 12, 2012 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
Tiago Thiengo Vieira Posted January 13, 2012 Author Report Posted January 13, 2012 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...
Pete Dowson Posted January 13, 2012 Report Posted January 13, 2012 ... 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
Tiago Thiengo Vieira Posted January 16, 2012 Author Report Posted January 16, 2012 Try 3.998r,http://fsuipc.simflight.com/beta/FSUIPC3998r.zip 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...
Pete Dowson Posted January 16, 2012 Report Posted January 16, 2012 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
alaxus Posted January 17, 2012 Report Posted January 17, 2012 Try 3.998r, http://fsuipc.simflight.com/beta/FSUIPC3998r.zip Regards Pete 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
Pete Dowson Posted January 17, 2012 Report Posted January 17, 2012 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
Tiago Thiengo Vieira Posted January 17, 2012 Author Report Posted January 17, 2012 (edited) 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 January 17, 2012 by Tiago Thiengo Vieira
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now