taguilo

Welcome back, Master :-)CheersTom

Paul,I suspect there is a stack value left lost in one of the macros. In the first example it would be "popped" by the command , therefore not noticed. You can do this test to confirm:@CrzAltDisplay 100 * @EndDecAlt - abs (A:GPS ETE, minutes) 8 + / r p (A:GPS ETE, minutes) * (>L:VNAValtProfile,number)Tom

Jan,You're right, but I guess " (A:Vertical Speed,feet per minute) abs " instead of " -1 * " just to manage negative v/s data on descent.Tom

Well...my best congratulations then!:D :D :D Tom

Paul,Maybe using this snippet..:((A:Indicated Altitude, feet) (L:AltChange,number) - abs (A:Vertical Speed, feet per minute) / (P:ZULU TIME, minutes) + d 1440 >= 1440 * - (>L:TCTime,minutes) (in Zulu format)and then to extract hours and minutes: (L:TCTime,hours) int(L:TCTime,minutes) 60 % intTom

If you are checking for character typing, this could be an approach (pseudocode)In Mouse section :Button1 --> CRSClick= 1(>LSbMenuActive) (PAbsoluteTime) (>LTime)Button2 --> ADFClick= 1(>LSbMenuActive) (PAbsoluteTime) (>LTime)etcIn Update section: (LTime) 0 != if{ (LTime) 2 + (PAbsoluteTime) < if{ 0 (>LSbMenuActive) 0 (>LTime) } }In Element section (SubMenu):Visible = (LSbMenuActive)In Keys section:On Key (alphanumeric, etc)Process the key (PAbsoluteTime) (>LTime)Tom

>Yes, the 727 uses JT8D.>>but the logic of ron for the JT8D is valid... I don't know how>works EPR in the RR engines...>>EPR principle of functioning is the same for every engine model, although figures are quite different. Big turbofan engines like PW use a lower scale (1.0-1.80) while older types like JT8D measure higher values (1.0-2.20) being RR in the middle.>but the best way to check the epr is via N1. all charts in QRH>and for TO planning gives only your EPR, your N1 and the>correction for a bleeds off for take-off...I would say the easiest way, but there are others as well :-) And CNx must be used if one wants to plot only one curve for Nx to EPR. This is easy to do in a spreadsheet, through the conversion formula I posted before on this thread. A bit of work though, but worth the effort.Tom

I recall Ron Freimuth did a fit of EPR vs CN1 for a 727 engine, also a JT8D if I'm right. I for one did a plot of EPR vs CN2 for a RB211 535E4 engine, the one used in 757s. Ron and I discussed the different advantadges/disadvantages of using either of the spools (LP or CN1/HP or CN2). After a couple of months doing tests, I opted for the CN2 variable, which in fact was a bit more complex to plot, because I needed to know the proper EPR for a given throttle position (RB211 Commanded EPR gauge) and throttle is linked to CN2 (tables 1503 and 1504). Tom

>but am not sure how you arrived to the corrected>N values. Juat curious,Convert Nx to CNx:CNx = Nx/Sqrt((TAT

Hi,If what you want is to detect if a key is pressed like when entering data on the GPS, or a specific is executed,it would be simple. Now, if the reversion must be canceled upon ANY event or keypress is done, it would be a tough work :-)Tom

Hi,Actually, FS internally plots "SAT normalized" engine data, called "Corrected Nx" (CN1,CN2) as to avoid changes in readings because of pressure/temperature differences (TAT).So a single plot of EPR/N1/N2 can be done by converting nominal (instrument) readings to its Corrected version.For example:EPR ref: 2.15TAT -40C N1= 87.1 N2= 84.9 CN1=96.84 CN2=94.39TAT 10C N1=96 N2= 93.6 CN1=96.84 CN2=94.39TAT 15C N1=CN1= 96.84 N2=CN2= 94.39Then you can plot EPR=2.15 = CN1= 96.84 = CN2= 94.39 and so on for each file in the table.As FS handles CN1 and CN2, I think you should make EPR the Y value for the calcs.Just my two cents :-)Tom

""KTAS = KIAS+((0.15*KIAS)*alt/1000))""I understand the rule of thumb for IAS to TAS conversion isTAS = IAS plus 2% of IAS per 1000 ft Using your formula TAS = IAS +((0.02*KIAS)*alt/1000))Tom

Jan,This "third option" should be the most efficient:(L:condition,number) 100 < d (>L:failure 1,bool) (>L:failure 2,bool) etcproviding failure lvars must accept the same logical value of the first comparison (which may not be the case usually).Tom

""Your job is making sure that the big needle with the knob on top is displayed at exactly 50% in the console arc when the gauge is sending the message 'big needle with knob on top = 50% travel', and nothing more.""It depends. If you are working on a project that has to be as real as it gets, you need to suit FS parameters and simulate gauge readings so that 'big needle with knob on top = 50% travel' comes from the REAL aircraft requeriments and not otherwise. That's the big challenge every panel developer has to deal with. In fact, most of the very popular payware panels (LDS, PMDG, etc) has some "cosmetics" on their gauges, as to simulate as much as possible the real systems functions.FS .air file is a pretty well job done by the MS team. However, in some sections, like Engine tables for example, things are a bit rigid. Interpolation between columns follows a linear pattern, where in RW values usually follow a polinomial order, so no matter the best work you do with those tables, there would be inaccurancies that can be solved by coding the panel gauges properly.EPR and EGT in turbo/jet engine are unrealistically modeled to say the least. But they can be simulated to match RW data almost perfectly, and with no penalty at all in aircraft performance.I agree flight dynamics should be respected, but not to the point of compromising REAL data output in panel gauges for those of us who want to play "real", in those situations where FS performance won't be substantially altered by customized code.As a specific example, it tooks me quite a lot of time to program the REAL engine startup sequence for my 757, yet being not finished at all. The complexity of this process goes well beyond what the generic FS jet engine is able to simulate, and there is no smart FD adaption that can make the numbers match as needed. But a bunch of XML polinomials did make my day, and now the needles point where Boeing (and not MS) intended they have to.""<>Of course it is. Those data are then carefully imposed on the engine specific flight dynamics by the flight dynamics author.""Unfortunately, flight dynamics alone can't solve much of complex aircraft system's behavior, due to the inherent limitations stated above. That's when smart coded gauges do their job...""Consequently there is no problem to be solved.""For all of us who make panels for our own enjoyment (or other valid reasons), thanks god ALWAYS will exist problems to be solved!:-) Tom

""What needs to be done is to add a dependency to the output manifold pressure values that are displayed by the gauge in a way that the MP will rise if the RPM is decreased (RPM lever position)and at the same time to compare the RPM handle position against the throttle lever position and increase or decrease the MP pressure only if the position of RPM handle against throttle(MP) handle is relatively changing. A realistic value of change to start with is some 10% of change in MP with 10% of change in RPM, so if the RPM is decreased from 2500 to 2250(10%) the manifold will raise from 23 to 25.5 and this increase and decrease of MP can be considered linear thru the normal operating ranges. It's not that I'm lazy or something, but this kind of programming in XML is simply well above my current capabilites.""*************All this seems feasible to code in XML...Ball goes to Nick's field now! :-)Tom

>Who can tell me the difference:>- between ENG RPM ANIMATION PERCENT and TURB ENG N1?>- between AMBIENT PRESSURE and BAROMETER PRESSURE?>(In these 2 cases, my tests showed these variables always have>the same value, no difference...)>- between TURN ENG N1 (or N2) and TURB ENG CORRECTED N1 (or>N2)? What does the "correction" change?>>Thanks for any help !!>Eric>Synoptically:-ENG RPM ANIMATION PERCENT is preferable to be used by xml code for parts animation, not by panel gauges.-AMBIENT PRESSURE and BAROMETER PRESSURE? - Never tested these yet, sorry.-TURB ENG CORRECTED N1 is an ISA (15

""The situation that is absolutely not modelled in the simulation is that at a constant altitude when the propeller levers are moved, thus changing theRPM there is a noticeable change in the MP, lower RPM, higher MP and vice versa.In a turbocharged engine MP is kept the same with the altitude changes by means of a special vastegate up to a certain altitude, reffered to as "critical", even there is nothing critical in the situation, and then at higher altitudes MP falls of at a standard rate, and this behaviour is NOT MODELED in the simulation at all, and the same situation is with the RPM changes, where the MP raise and drop is also not modeled. ""***********************************I believe that FS unmodelled behavior you stated can be perfectly simulated using XLM code. However, you'll need to know which are the real numbers for the relationship between RPM increase/decrease and MP decreas/increase. Basically two things to consider before coding startup:-If there should be a significant difference in engine performance as MP raise/drop in response to RPM changes, you would have to tune RPM and throttle events by code, faking its respective lever bitmaps'positions (ie "throttle lever position", etc)- On the opposite, if there is not such a difference noticeable in some kind of flight characteristics alteration, should be enough to fake the gauge's readings using polinomials extracted from real tables.Tom

"" When I open this table, the first row (grey) shows CN1, and the first comlumn (also grey) shows the mach. The other cells show CN2. Is this right? ""Nope. First row are CN1 values at 0 Mach for each CN2 column value.Second row are CN1 at 0.9 Mach for the same. FS makes a direct interpolation of the two values for a given (Mach) speed, which in real world is rather incorrect, but FS doesn't use polinomials...Tom

Hi,Table 1506 is another than can be tweaked as well. It relates Thrust vs. CN1. Try reducing Thrust coefficient for CN1 idle value(s).Tom

Eric,Maybe you'll need to grab the latest AirEdit version, plus its .ini version by Ron Freimuth. You can edit 3d tables directly; it's a great tool.http://perso.wanadoo.fr/hsors/FS_Soft/fsairfile.htmlTom

Nick,I know nothing about manifold pressure. However, I do know a bit of XML :-) So, if you could bring a practical example of what values do you need to relate and how, maybe I could think of something.Tom

>>...So if the real temp is>+10 deg C the ISA temp is -5 deg C. You can see the problem>already you have a + temp to change to a -. If the real temp>was +30 deg C the ISA is +15 so thats the problem.>>> Then why don't you make a simple rest??%((A:Ambient Temperature,celsius)) 15 -)%3d%For example, if Ambient temp is 10, you will get a -5 ISA value. Now, if it is 20, you will get ISA 5 but no plus "+" sign, though it would be easy to add it within the string.Tom

Paul,When (A:Ambient temperature, celsius) is 13, you get 2 and you think you should get -2? Well, then I think RPN wins...:-)(15 13 -) equals 2 positive(15 20 -) equals 5 negative (-5)Unless I missed something.Tom

Paul,"case" operator doesn't seem to be the best solution for what you want.Maybe this one works:(Setvalue) sp0l0 1 == l0 2 ==l0 5 == l0 10 ==l0 15 ==+ + + + ! if{ INVALID ENTRY }Tom

Eric,I know of two possible methods:1) Modify the a/c .air file, table 1502, CN1 vs CN2; increasing CN1 on the second row (Mach 0.9) for the lowest CN2 values and up to the next CN2 column greater than "ground" idle.2) If you don't want to play with .air files, just include in a gauge a polinomial that "converts" the original CN1 idle values to those needed at high altitude/speed. With this method you will need to code the engine N1 gauge using LVars of your own.Tom