Pete Dowson

These are entries into menus or similar: However, this is a sign that either FS or just SimConnect is being deprived of processor time: but that was 5 hours and 9 minutes into the session! Sounds like it might be some sort of memory leak or other problem. I've seen lots of reports of problems arising after many hours. Luckily I only like short flights -- all the fun is taking off and landing! Pete

You've "gone through the manual" but apparently skipped the very example of exactly what you want to do? Did you not even try searching on the word "gear", which finds the right place immediately? In the current (4.91) copy of the FSUIPC4 UIser Guide the whole of page 44 is all abouty EXACTLY what you want to do. In the FSUIPC3 version its the whole of page 45. How could you miss out a whole page realting to exacvtly your need? The reference with the gear up/down example? Pete

No, FSUIPC does no such checking. It is FS which ignores invalid requests. You mean "process" calls, not reads or writes, which are accumulated into a block for sending to FSUIPC when you execute the Process call. I don't know of any restriction on reads or writes to set anything. But you should do the process calls at intervals which aren't going to slow FS down too much -- 20-30 times per second is normally good enough on most systems, even for lots of data. And it is best to have the whole thing event driven rather than loops with "sleeps" if possible. Just more efficient. Why do you think there are offsets needing a delay after accessing them? Have you any examples? Yes. It is the same as a Parameter supplied to an assigned FSUIPC or FS control, which are always 32-bit integers. What makes you think it does anything? In general only "_SET" or "AXIS_" controls use parameters. If the function is merely a button which toggles something, or is specifically an ON or an OFF control it probably doesn't use the parameter. But, interestingly, some do and what the parameter does, if anything, has to be determined by experiment because none of this was ever documented by Microsoft. The offsets can be updated separately, but not the individual digits. You'd have to read the value, change just the quartet (4-bits) you need to change, then write it back. Most of your questions appear to be either based on a misunderstanding (like just because there's a parameter, why isn't it used?), or related to Microsoft operation, for which Microsoft should ideally answer, except of course they don't develop or really support FS any more. When folks are developing stuff they find their way. FSUIPC is only an interface into FS, not the implementation of the things you are manipulating. Regards Pete

That's certainly a sign of an overloaded FS, or possibly (but less likely in my experience) some add-on having a problem with Simconnect which stops it supplying data. But there's nothing there indicating any problem with FSUIPC or SimConnect. This message: 1135578 Sim stopped: average frame rate for last 1026 secs = 29.7 fps merely indicates that SimConnect told FSUIPC that the simulation is paused when in a menu or loading something, that's all. And the frame rate certainly looks healthy enough. If your add-on is complaining of a disconnect simply when the data stops changing fast enough, it needs some attention in its coding. Regards Pete

I am not sure that a disconnect from a client application will result from a failure to receive SimConnect events. More likely that the same problem causes both -- something not allowing either Simconnect or FSUIPC any processor time. I think you are possibly being grossl unfair saying it is "issues with FSUIPC". I am interested to know what it is you see in your Log which suggests a lack of SimConnect events. What sort of frame rate is occurring at this time? What else is running? What does the internet connection have to do with it? FSUIPC's SimConnect stall merely allows more "lack of receiving" time till it tries to reconnect. It won't stop it stalling in the first place.. Why would AS2012 have anything to do with it? It sounds as if you have something seriously affecting FS's performance, so much so that everything stalls. I'm afraid there's not ebough data here. You don't even state the version of FSUIPC in use. Note that nothing earlier than 4.91 is now supported for FSX or P3D. I'm afraid i am now away till next Tuesday. Regards Pete

Yes, of course. In fact it is given as the example of how to use the "range" assignments facility in the Axes tab. Please look in the (seldom used?) FSUIPC User Guide, find the Axis Assignments chapter, and go down a two ro three pages or so till you get to the explanation of the right-hand side of the assignments tab, with exactly the example you seek. Pete

U32 is more appropriate as it can't go negative, but either will do unless FS is ever able to be allocated as much as 2147 Gb. ;-) Pete

Yes, that looks right. FSUIPC's ding sounds at 300 Mb left, yes, but that was just a value I found by experiment seemed to give enough warning to do something. Soon after that, if it keeps decreasing, odd things start to happen. Regards Pete

The calibration tab does NOT read joysticks at all -- It merely calibrates FS controls! You can assign an axis in FS or in FSUIPC, and if it is assigned to one of the controls for which FSUIPC offers calibration services, it will be detected there in the relevant section. You need to assign that axis first, then, either there in the assignments tab or in FS. BTW please make sure you are using a currently supported version of FSUIPC -- 4.91 for FSX and P3D or 3.999z5 for FS9. Regards Pete

All offsets operate using the offset value given. That is all 100% of those you can write to. Offsets aren't simple memory locations, they are instructions to FSUIPC to read or write things. The days when they were truly memory related (FS98) are long gone. Pete

It sets Engine 2 throttle provided it hasn't been disconnected using offset 310A. Offset 0924 is the real throttle, not disconnectable. Please refer to the FAQ thread explaining about bits, bytes and so on. You need to know those things if you are messing with offsets. WORD = 16bits = 2 bytes. The full range of the throttle setting values is as defined and you quoted. Why ask me when it's written there and you've quoted it? It isn't strange that throttle = 0 is idle, surely? Pete

Sounds like you've said "No" to the questions which come up on each new version. You'll need to delete the FSUIPC entries in the FSX.CFG [Trust] section to get the prompts up again, or change any that aren't set =1 to =1. Pete

Yes. Annoying that the 'latest post' info doesn't update with edits. With a fixed format listing like the Download Links threads it's just too much fuss posting a completely new item and deleting the old one. So I just highlight the new changes in the little tags you can see under the thread titles. Pete

The action of setting the frequency is triggered by writing to 0x311A, so the second line has no effect. Why are you bothering to convert Hexadecimal into Decimal in order to write in any case when the hex representation is obviously clearer in this case? You would be best simply witing the offset as one value. Writing one byte then the other, in either order, may not work properly because the offset reflects what the COM1 standby radio is currently set to. Since it is only changed by writing to 311A, by the time you try to write to 311B it is too late, the value there reflects the radio setting. The proper way is ipc.writeUW(0x311A, 0x2325) Note that no ";" characters are needed in Lua, though I don't think they do any harm. See that it makes sense using the correct ipc.write instruction for the size of the value you are writing? If you do not know the correspondence between bits, bytes and things like Words, Dwords, etc, please review the FAQ thread about bits, bytes ad numbers. Regards Pete

No trouble. I am actually concerned about what could be causing this. Maybe a different way of assighning the toe brakes will do the trick, I don't know. Currnetly it is a mystery, presumably wraped up in the methods PMDG are using to simulate the autobrake operation. Okay. If it isn't sorted I'll have to think of other ways of delving into the events which occur. I'm sure there are lots of folks using the NGX and with FSUIPC exclusively for assignments, so there must be a solution. Regards Pete

Well, with most of the lines you'll use with FSUIPC or WideClient there'll be calls to library functions which only exist in those programs. so the best bet is simply to run it in FSUIPC (assign a keypress for it), and check the log. You can have the Lua log separate from the FSUIPC log by checking that logging option in FSUIPC. Once you get the syntax correct you can use the Debug/Trace option to trace through its actions -- the log will show the line numbers and the values of variables when they change. Pete

Two 4.91 files have been available in the Download Links subforum since yesterday morning -- one with the Installer and one with just the DLL. It is also the one on the Schiratti site. There are no earlier versions now available. It sounds like you've not bothered to refresh your browser. Just press the curly arrow thing or press F5 or even Ctrl+F5! Pete

Yes you are. The LEFT hands side is assignment to the axis, the RIGHT hand side is clearly marked out for setting DIFFERENT controls to be sent in specific ranges along the axis. You wouldn't usually use both. didn't you even think it mildly odd to be assigning the exact same control to the same axis in two different places? Why would you think that normal at all? Folks have used the right hand side for Gear Up/ Off /Down on an axis, for example. Up to 10 ranges can be set so it's also useful for Flaps, instead maybe of using the flaps detebntes facility. The documentation does cover all this. Worth a read some day, perhaps? ;-) Pete

So your are using all the PM 501c versions released yesterday? An FSUIPC 4.91 released yesterday? Please ALWAYS give version numbers. "Latest" is actually meaningless as it means "the latest I saw or bothered to download". Folks have said that and been a year or more out of date! "this information" being the DME distance? No idea. Maybe monitoring the offsets containing this data will show whether it's a PM problem or corruption in memory. oc29 for DME1, 0C33 for DME2, both are strings. You can monitor them using the Monitor (right-hand side of FSUIPC logging tab), or possibly in the PM CDU. Pete

I don't understand your axis assignments. For every one, all assigned to FS contorls rather than "direct to FSUIPC", you also have a strange Range control set, for the same FS axis control, but no range actually set. Why? The lines shown red below are never right. [Axes] 0=0X,256,F,66387,0,0,0 1=0X,BR,0,0,66387,0 2=0Y,256,F,66388,0,0,0 3=0Y,BR,0,0,66388,0 4=0R,256,F,65764,0,0,0 5=0R,BR,0,0,65764,0 6=1R,256,F,65765,0,0,0 7=1R,BR,0,0,65765,0 8=2X,256,F,65763,0,0,0 9=2X,BR,0,0,65763,0 10=2Y,256,F,65762,0,0,0 11=2Y,BR,0,0,65762,0 12=2R,256,F,65764,0,0,0 13=2R,BR,0,0,65764,0 You must be in the habit of checking something on the right-hand sde of the assignments tab, the area specifically designed to allow controls to be assigned to ranges of the axis. Delete those red lines and try again. I really have no idea if it'll help, but those certainly won't be doing anything good. If that doesn't help, try assigning the brakes direct ot FSUIPC instead. I'm surprised you've not used that technique for all the axes -- your assignments are exactly the same as assigning them in FS instead of FSUIPC. The calibration applies no matter where you assign. Finally, these "calibrations": Aileron=-16384,0,0,16383 Elevator=-16384,0,0,16383 Throttle=-16384,16383 Rudder=-16384,0,0,16383 LeftBrake=-16383,16384/16 RightBrake=-16383,16384/16 are actually all default settings except for the reversal of the brakes. It appears you've never actually followed any of the recommendations in the User Guide, the numbered staps to good calibration. So all in all your use of FSUIPC is actually identical to not using it (for axes) at all. It would be absolutely no different if you used FS assignments and no FSUIPC calibrations. Regards Pete

Sorry, I've no information to go on here. What version of Flight simulator? What version of FSUIPC? Is the VOR/DME being received still -- i.e. do the radials stil register etc? I can't imagine anything which would suddenly cause things to go wrong after flying a while except for overheating, memory problems, and memory corruption. Software doesn't change with time. Well, not this sort of software. Check that everything is up to date. Current versions of FSUIPC are 4.91 and 3.999z5. For PM they are 501c for Boeing. no idea for other aircraft. Regards Pete

Blimey! From the time you started the extra logging to the time you stopped it 30 seconds elapsed. What took so long? In those 30 seconds it looks like simply thoudands of PMDG-dedicated controls were sent. I've no idea what the xxx that program is doing! Most of them sem to be repeats of Cntrl 70092, over 30 times a second by the look of it. Weird. Anyway, the only Brake Axis controls were these: 552244 *** AXIS: Cntrl= 66387 (0x00010353), Param= 16383 (0x00003fff) AXIS_LEFT_BRAKE_SET 552244 *** AXIS: Cntrl= 66388 (0x00010354), Param= 16383 (0x00003fff) AXIS_RIGHT_BRAKE_SET The first entries logged already show a full brake application. I assume this is down to the way the PMDG aircraft does the AutoBraking. You then used the assigned toe brakes, press then release, thus: 553071 *** TOE BRAKE AXIS, Right set = 16 (IN=-13824, OUT=-13826) 553071 *** AXIS: Cntrl= 66388 (0x00010354), Param= -13762 (0xffffca3e) AXIS_RIGHT_BRAKE_SET 553102 *** TOE BRAKE AXIS, Right set = 41 (IN=-9728, OUT=-9730) 553133 *** TOE BRAKE AXIS, Right set = 52 (IN=-7936, OUT=-7938) 553133 *** AXIS: Cntrl= 66388 (0x00010354), Param= -7864 (0xffffe148) AXIS_RIGHT_BRAKE_SET 553164 *** TOE BRAKE AXIS, Right set = 56 (IN=-7168, OUT=-7170) 553195 *** TOE BRAKE AXIS, Right set = 77 (IN=-3840, OUT=-3842) 553195 *** AXIS: Cntrl= 66388 (0x00010354), Param= -3769 (0xfffff147) AXIS_RIGHT_BRAKE_SET 553227 *** TOE BRAKE AXIS, Left set = 69 (IN=-5120, OUT=-5122) 553227 *** TOE BRAKE AXIS, Right set = 100 (IN=0, OUT=-2) 553273 *** TOE BRAKE AXIS, Left set = 171 (IN=11627, OUT=11626) 553273 *** TOE BRAKE AXIS, Right set = 110 (IN=1586, OUT=1584) 553273 *** AXIS: Cntrl= 66387 (0x00010353), Param= 11631 (0x00002d6f) AXIS_LEFT_BRAKE_SET 553273 *** AXIS: Cntrl= 66388 (0x00010354), Param= 1638 (0x00000666) AXIS_RIGHT_BRAKE_SET 553305 *** TOE BRAKE AXIS, Left set = 189 (IN=14534, OUT=14532) 553305 *** TOE BRAKE AXIS, Right set = 111 (IN=1850, OUT=1848) 553305 *** AXIS: Cntrl= 66387 (0x00010353), Param= 14580 (0x000038f4) AXIS_LEFT_BRAKE_SET 553305 *** AXIS: Cntrl= 66388 (0x00010354), Param= 1802 (0x0000070a) AXIS_RIGHT_BRAKE_SET 553336 *** TOE BRAKE AXIS, Left set = 190 (IN=14798, OUT=14796) 553336 *** TOE BRAKE AXIS, Right set = 110 (IN=1586, OUT=1584) 553367 *** TOE BRAKE AXIS, Left set = 150 (IN=8192, OUT=8190) 553367 *** TOE BRAKE AXIS, Right set = 14 (IN=-14080, OUT=-14082) 553367 *** AXIS: Cntrl= 66387 (0x00010353), Param= 8191 (0x00001fff) AXIS_LEFT_BRAKE_SET 553367 *** AXIS: Cntrl= 66388 (0x00010354), Param= -14090 (0xffffc8f6) AXIS_RIGHT_BRAKE_SET 553398 *** TOE BRAKE AXIS, Left set = 0 (IN=-16383, OUT=-16383) 553398 *** TOE BRAKE AXIS, Right set = 0 (IN=-16383, OUT=-16383) 553492 *** AXIS: Cntrl= 66387 (0x00010353), Param= 6553 (0x00001999) AXIS_LEFT_BRAKE_SET 553492 *** AXIS: Cntrl= 66388 (0x00010354), Param= -16384 (0xffffc000) AXIS_RIGHT_BRAKE_SET 553570 *** AXIS: Cntrl= 66387 (0x00010353), Param= 4914 (0x00001332) AXIS_LEFT_BRAKE_SET 553632 *** AXIS: Cntrl= 66387 (0x00010353), Param= 3276 (0x00000ccc) AXIS_LEFT_BRAKE_SET 553695 *** AXIS: Cntrl= 66387 (0x00010353), Param= 1638 (0x00000666) AXIS_LEFT_BRAKE_SET 553773 *** AXIS: Cntrl= 66387 (0x00010353), Param= 0 (0x00000000) AXIS_LEFT_BRAKE_SET 553804 *** AXIS: Cntrl= 66387 (0x00010353), Param= -1639 (0xfffff999) AXIS_LEFT_BRAKE_SET 553866 *** AXIS: Cntrl= 66387 (0x00010353), Param= -3277 (0xfffff333) AXIS_LEFT_BRAKE_SET 553929 *** AXIS: Cntrl= 66387 (0x00010353), Param= -4915 (0xffffeccd) AXIS_LEFT_BRAKE_SET 554007 *** AXIS: Cntrl= 66387 (0x00010353), Param= -6554 (0xffffe666) AXIS_LEFT_BRAKE_SET 554069 *** AXIS: Cntrl= 66387 (0x00010353), Param= -8192 (0xffffe000) AXIS_LEFT_BRAKE_SET 554131 *** AXIS: Cntrl= 66387 (0x00010353), Param= -9830 (0xffffd99a) AXIS_LEFT_BRAKE_SET 554194 *** AXIS: Cntrl= 66387 (0x00010353), Param= -11469 (0xffffd333) AXIS_LEFT_BRAKE_SET 554241 *** AXIS: Cntrl= 66387 (0x00010353), Param= -13107 (0xffffcccd) AXIS_LEFT_BRAKE_SET 554303 *** AXIS: Cntrl= 66387 (0x00010353), Param= -14745 (0xffffc667) AXIS_LEFT_BRAKE_SET 554365 *** AXIS: Cntrl= 66387 (0x00010353), Param= -16384 (0xffffc000) AXIS_LEFT_BRAKE_SET which as you can from the BOLD entries see eventually left both left and right brakes fully off. This is a mere 2 seconds or so into the sequence. But then it looks like you, or something, presses the brakes fully. This is just over a second later: 555676 *** TOE BRAKE AXIS, Left set = 200 (IN=16384, OUT=16384) 555676 *** TOE BRAKE AXIS, Right set = 200 (IN=16384, OUT=16384) 555676 *** Both toe brakes over threshold: FS BRAKES control sent 555676 *** EVENT: Cntrl= 65588 (0x00010034), Param= 0 (0x00000000) BRAKES 555707 *** AXIS: Cntrl= 66387 (0x00010353), Param= 16383 (0x00003fff) AXIS_LEFT_BRAKE_SET 555707 *** AXIS: Cntrl= 66388 (0x00010354), Param= 16383 (0x00003fff) AXIS_RIGHT_BRAKE_SET Now both brakes are fully on. What pedals are you using? Are they calibrated correctly? Do they behave okay normally, eg, when taxiing? Maybe you need to show me your FSUIPC INI file. And do you have any Lua plug-ins running at all, like LINDA or anything like that? Pete

Just go to the Calibration chapter. Not far down you'll find a set of steps, numbered, which lead you through calibration. By all means if you get stuck on one ask the question, but asking what the two centre values mean tells me you've not really got as far as following those steps yet. Note that you do not need to actually care about what the numbers are, just that you need to set them all to correspond to good positions on your axes. The only really important number is the result, the "OUT" number, which is the one which controls FS. Regards Pete

As you wish. 512 ands -512 are simply the default centre zone limits. You should change them during calibration. Evidenely you've not followed any of the numbered steps to successful calibration given in the User Guide. You don't seem to understand what calibration is all about. Please just follow the numbered steps in the user guide. It is all very simple if you just do what it says. There's absolutely nothing to "get your head around". It is merely a numerical way of setting the limts and cerntre zones of your axis travels, so that FSUIPC can map the actual values it gets from your controls to those needed by FS, and ensure that your "central" position (hands off on the yoke, feet off on the pedals, idle on the throttle) matches the same position in FS. Regards Pete

Ah, sorry, you did not mention it was the 'on touchdown' G-Force. So you ARE using FSUIPC4? What version? You should always say. Only one now supported is 4.91. All that happens is that when FSUIPC detects "on ground" it copies 11BA to 11B8. 11B8 is set directly from a SimConnect value computed by FSX. If you bounce it could well be zero for a fraction , at the top of the bounce! ;-) I don't know VB much, but this seems odd: Dim strLDGGF As Double You read the offset value into a "double" (which is presumably a 64-bit floating point value), whilst the offset is a 2-byte (16 bit) integer! I don't see a definition for LDGGF, but surely that should be the "double", and strLDGGF should be an integer initialised to zero (because you only read 2 bytes and an integer is 4 bytes. You are only just learning VB? I don't think an FSUIPC application is the best way to learn. You need some easier projects first I think Regards Pete