bcs112 Posted September 13, 2009 Report Posted September 13, 2009 Hi Pete, I'm pretty sure this is not something you have much control over but OK... I use Offset 310A to turn off joystick input axes to avoid the joystick interphering with my Autothrottle input. I set 310A to value 8 to turn off the joystick throttle axis (2^3) and I redo this approx every half a second or so. The problem is that it takes anywhere 2 and 20 seconds between the first time I write value 8 to offset 310A and the time the value actually changes. The same delay happens when I try to set the offset back from 8 to value 0. Is there anything I could do to speed up this process ? If it always happens within 2 seconds I would be happy but 20 seconds is a long time when you need your throttles back... Kind regards, Björn
Pete Dowson Posted September 13, 2009 Report Posted September 13, 2009 I set 310A to value 8 to turn off the joystick throttle axis (2^3) and I redo this approx every half a second or so. The problem is that it takes anywhere 2 and 20 seconds between the first time I write value 8 to offset 310A and the time the value actually changes. The same delay happens when I try to set the offset back from 8 to value 0. Good grief! How are you writing to it? Using the normal FSUIPC interface it can only take a maximum of something like a 100 mSecs or so (i.e. a tenth of a second). Requests are placed in the Windows message queue and then processed as soon as FSUIPC gets them -- always within one FS frame from then. In fact the complete cycle is usually within 20-40 mSecs even when performed from a networked PC using WideFS! There are autopilot programs (e.g. Project Magenta's MCP, also those from Sim-Avionics and Flight Deck Software) which operate from a client PC over a network and which would be completely unusable with response times exceeding a fraction of a second! There is no way FSUIPC has of "storing up requests for 20 seconds"! Something must be happening in your software BEFORE the request gets into FS. Have you tried doing the same thing with FSInterrogate, for instance? It is instantaneous as far as the user can tell! Regards Pete
bcs112 Posted September 13, 2009 Author Report Posted September 13, 2009 Hi Pete, Yeah, I know it should be instantanuous, I tried it in FSInterogator but I can only write a value 1 time and that doesn't change anything in FSUIPC and from your documentation I understand the value needs to be rewritten frequently, hence me writing data to the offset every 0.5 second. Here's what I do, very standard I think ? BYTE joystick = 0; //Check if any of the A/T functions is ON if ( ( srs_pos || n1_on_exp || ga_exp || spd_pos ) && sim_pause == 0 && sim_slew == 0 ) { if ( ( AIRCRAFT_ON_GROUNDvar.var_value.n && throttle_both > 12000 ) || AIRCRAFT_ON_GROUNDvar.var_value.n == 0 ) { joystick += 8 ; } } FSUIPC_Write(JOYSTICK, 1, &joystick, &dwResult); FSUIPC_Process(&dwResult); I was wondering, I read approx 30 variables from FSUIPC every TICK (+/- 18x per second) + the TCAS array. To make sure I have enough memory reserved I declare a rather large BYTE FsuipcMem[5120]; In my open sequence to establish a connection with FSUIPC: FSUIPC_Open2(SIM_ANY, &dwResult, &FsuipcMem[0], 5120); FSUIPC_Write(0x8001, 32, ®, &dwResult); FSUIPC_Process(&dwResult); Could the size of the array be too big for FSUIPC to deal with ? Resulting in some strange behavior ? Is there a maximum size for the memory assignment ? Björn
bcs112 Posted September 13, 2009 Author Report Posted September 13, 2009 I found a solution which seems to work fine: When I set bit 2^3 alone the reaction is extremely slow (maximum recorded reaction time 42 seconds!) but when I set bit 3 together with any other bit e.g. 6 and 7, reaction is instantanuous. So now I set 3-6-7 to on and off when turning the A/T on/off. Strange ... Björn
Pete Dowson Posted September 13, 2009 Report Posted September 13, 2009 Hi Pete,Yeah, I know it should be instantanuous, I tried it in FSInterogator but I can only write a value 1 time and that doesn't change anything in FSUIPC and from your documentation I understand the value needs to be rewritten frequently, hence me writing data to the offset every 0.5 second. Actually the timeout is about 10 seconds. I advise rewriting every few seconds, especially if running from a Client PC, in case of delays. There are no places in FSUIPC offsets which need rewriting as frequently as 0.5 seconds. Here I can write with FSInterrogate, demonstrate the disconnection of the axis for several seconds, before the timeout makes the connection good again. Here's what I do, very standard I think ?... FSUIPC_Write(JOYSTICK, 1, &joystick, &dwResult); FSUIPC_Process(&dwResult); ... I was wondering, I read approx 30 variables from FSUIPC every TICK (+/- 18x per second) + the TCAS array. To make sure I have enough memory reserved I declare a rather large Erhang on! You have one FSUIPC_Process call merely to write that one byte? And how many separate ones doing those reads or other things? Each Process call means a process switch and another message. You should be only doing one process call per cycle, eg. once per 50 mSecs or so, less if you aren't doing real-time control as an autopilot. Could the size of the array be too big for FSUIPC to deal with ? Resulting in some strange behavior ? Is there a maximum size for the memory assignment ? No, not relevant. I think 32k is the max for an external program, but from a GAU or DLL, as you are, up to 64k. Regards Pete
bcs112 Posted September 13, 2009 Author Report Posted September 13, 2009 I included the FSUIPC_Process to show that I use standard technique... The last results of my tests showed that setting the offset can be made to work fine (well more or less) except for the "0" value. I ended up setting the byte 4 to "on" and the other bits to off as the only way to set all the bits to "0" quickly, after a few seconds bit 4 will then also go to "0", trying to set all the bits to 0 in one go simply doesn't work for me and always results in a delays. Björn
Pete Dowson Posted September 13, 2009 Report Posted September 13, 2009 ... trying to set all the bits to 0 in one go simply doesn't work for me and always results in a delays. It really sounds like you have something else going on there. In FSUIPC this is a simple read/write location. What you see is what you last wrote, except after FSUIPC's timeout when the whole byte is written zero. There's really nothing hidden about it, no other actions whatsoever. Perhaps you'd try to use FSUIPC's logging and monitoring facilities to see what you have going on there? Pete
Pete Dowson Posted September 14, 2009 Report Posted September 14, 2009 Perhaps you'd try to use FSUIPC's logging and monitoring facilities to see what you have going on there? Did you check with logging? I had some time here today to do some checking on this myself. You'll note from the FSUIPC4 History document that the writing/reading of 310A has had a rather complex history. Well, to cut a rather long and complex story short, I believe I've found out what might be going on with your system and 310A delays in clearing it down (not in setting, only clearing, and then only when clearing all (except optionally the 2^3 bit). After a number of tests here, I found some odd code which can delay a full clearance (except the 2^3 bit) by up to 5 seconds. I cannot remember the reason for this at all nownor why it would apply to FSX but not to FS9 or before. Strange. There's must have been a good reason for it, but I'm blowed if I can think what it is! So, sorry, I owe you an apology. I think your original report, implying both setting and resetting bits was affected, and delays of up to 20 seconds, took me down the wrong path in what I was looking at. Please download and try version 4.533, which will be up in the Updates Announcement in an hour or two. Regards Pete
bcs112 Posted September 15, 2009 Author Report Posted September 15, 2009 Thanks a lot Pete for continuing to look at this ! I'll download the new built tonight and give it a try. I'll keep you posted. Björn
bcs112 Posted September 15, 2009 Author Report Posted September 15, 2009 Hi Pete, I installed FSUIPC 4.53, ran FSX => works fine, then I copied the latest update (4.533) dll over the 4.53 version but now FSUIPC is no longer loaded in FSX. Sorry for my ignorance but did I forget to do something ? Björn
Pete Dowson Posted September 15, 2009 Report Posted September 15, 2009 I installed FSUIPC 4.53, ran FSX => works fine, then I copied the latest update (4.533) dll over the 4.53 version but now FSUIPC is no longer loaded in FSX. Ouch. That's two reports. It works fine here on three different systems. Evidently i need to know more. What version of Windows are you using, please? And what update to FSX? [LATER] Please see the thread "add-on 4.5.3.3". Pete
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