taguilo

>Is there someone who can help me out with this problem i have>? >For my pfd i'm busy with the flight mode annunciations, but i>cant get the armed modes to work.. here's the code : >>(A:AUTOPILOT APPROACH HOLD, bool) if{ > (A:HSI GSI NEEDLE, number) 90.00 > (A:HSI GSI NEEDLE,>number) -90.00 < && if{ > 2 (>L:PATH_ARM_MODE, number) >} els{ > 0 (>L:PATH_ARM_MODE, number) > } >}>This sentence (A:HSI GSI NEEDLE, number) 90.00 > (A:HSI GSI NEEDLE, number) -90.00 < && will never give TRUE, you must use (A:HSI GSI NEEDLE, number) 90.00 > (A:HSI GSI NEEDLE, number) -90.00 < or Range goes from -127 to 127.Tom

>>would you by any slim chance know how to convert an XML>file>>written for FS9 into XML written to the new ACES.XML schema>so>>that it would load into ACES.exe?>>Yes. Very carefully! ;)>>Actually, I'm in the process of doing just that at the moment>with my ESDG "Garmin stack" of gauges.>>To make life simpler, I've carefully created "templates" for>each of the various types, and simply cut-n-paste>'em into the "new" gauge project's XML file.>>Keep in mind ALL of the existing parameters and>coordinate locations are the same, only their syntax and>locations have changed... So, it's really not that difficult.>Tedious and time consuming to be sure, but hardly difficult!>:)>I've started a similar procedure, just copying/pasting the structures to templates of the new format. VERY BORING, but not difficult at all. Besides, mostly of my codes are long stack structures and macros, which makes the whole thing simpler to convert :-)The idea, as Bill pointed out, is to take advantage of the new SPB format file, for which the ACES tool becomes mandatory. (though I still believe is a no-no for programing-only for exporting)Tom

>1 2 (@g:blinkingField) 4 == ? (>@c:FlightPlanLoadApproach)>>would be>> (@g:blinkingField) 4 == if{ 2 (>@c:FlightPlanLoadApproach) }>els{ 1 (>@c:FlightPlanLoadApproach) }Hi Roman,Actually is the inverse way :-roll :(@g:blinkingField) 4 == if{ 1 (>@c:FlightPlanLoadApproach) }els{ 2 (>@c:FlightPlanLoadApproach) }the first value on the stack is for true and the second for falseTom

Hi,Using a range of values within a as you intend is not possible. However, this is a optimized code that should work: (A:TURB ENG1 N2, rpm) 13.5 > Tom

>>It goes both ways. If you understand both you can do more.>I agree on this sentence for sure.Tom

>Tom,>>We're all here to learn.Cannot agree more on this.>All I am trying to say is every>aircraft has a different system for start, and there are 10>million ways to design that, but if you want your engines to>spool as the real aircraft...meaning once ignited, the spool>at realistic rates of rotation with the ambient air and>weather affecting it and smooth spool up...this is how. Well, I have to disagree on this, not with the technical aspects of your sentences but with the mode you state them. I would prefer to read something like "this is a good way to improve startup" rather than "this is HOW a real aircrat starts". Because your method, no matter how great could be, is just one of many that other talented people use here; I for one don't use your approach and my engines start smooth as well, no matter how deep I fake the gauges in a further step. >I am not trying to show anyone how to code the parameters outside>of that, which is where you keep focusing. That's why I say>you miss the point.True, but as you were trying to show FS generic parameters as realistics when they are clearly not (some of them not even close), I tried to clarify that point. If that wasn't your intention, then probably you're right and I missed your point in the essentials. >>I think where you get confused is when I say the variable>outputs unrealistic values that can be used to get the engine>to perform realistically. I just want the end product to>perform realistically... which is what you want so we are on>the same side. Never thought that we were on different ones; maybe we have a different level of acceptation for some FS technical aspects.>And trust me Tom you are a friend, not an enemy. You posted>useful information in a civilized way for all to read, which>is why I am here.>Never could have post a line in this thread if I would consider you an enemy. I don't ever talk with enemies (don't know of having ones) but for sure can dialogue in a respectful manner with people that don't share some or all of my points of view. I see you are doing pretty much the same now, then let's keep our future exchanges this way :-)Tom

>you must have a language barrier because you appear to not>comprehend anything i say.>>The fuel on from the beggining was a test to see at what point>FS9 simulates the start.Maybe I can't comprehend you because you confuse your concepts too much. My fault anyway, and I apologize for that.>>The variables I pointed out are constants. If you don't>understand how that makes them important regardless of how>unrealistic they are I can't help you.But it was you who started the thread saying "if you are trying to replicate the real aircraft"... and was me who was trying to help you understand that those concepts pointed by you were important to the sim but not realistic in terms of actual engine behavior. That was all about, and in the end you state the same in the above paragraph, so yes, it becomes difficult to comprehend you, sorry again.>They can be manipulated however you want without complex>coding and all using A vars.Of course, and I suspect that lot of people in this forum know how to configure their engine tables to obtain what they want (I being one of them). Anyway, your findings do add another perspective; thank you for sharing that with us.>As far as how an engine works, there is a difference between>needing to understand an engine and purposely breaking>procedure in an effort to understand the sim.I don't see the point in doing an effort to understand how the sim works, without undrstanding the basic concepts of the real procedures just to help the sim behave as real as it gets.Tom

Ridgell, els{ } will execute as long as the last stack's value is 0. No need to have an if{ preceeding, but no really useful without it...For example:els{ 1 2 + } will return 3 Tom

""So how is it an unstarted engine produces 20 PSI?""Because it is not realistic! Simply put.""That is a negative. The start N2 is set as I outlined above. about 19 PSI is calibrated to it. regardless of whether the engine starts at 30 N2 or 10 N2 it will have ~20 PSI of bleed air"" FS requires:16 PSI of fuel pressure18.8 PSI of bleed air115 pounds of fuel (set by thrust) and that is all regardless of N2 or fuel valve position.""Do I need to repeat that a real engine will be able to start with a variable range of bleed air supply,fuel flow and fuel pressure, depending on present conditions? Those fixed values enable FS to simulate startup in a generic set of engines; that is good for the sim but not real if you are modeling a specific engine, which is my case.""Most FDEs start at x=0 and y=0x is your fuel flow and y is your N2x needs to be zero at the point the engines will be started.In my A/c it is 25% N2 so my x=0 is y=25.01, or zero fuel flow at 25 N2. if you cut in the fuel early will continue to spool due to the starter but it will not start until reaching 25.If you start your FDE with x=0 and y=0 then at x=0.24 and y=24 your are injecting 24% of the total fuel flow into the engine at ignition. In reality you would hear a loud KABOOM followed by sirens...in FS it burns all that fuel in a huge spike.""Must I assume that you are putting fuel on immediately after opening the starter?? How bad :-( Fuel switch must be turn on ONLY when N2 spool rate has reached a certain number (usually marked with a magenta indicator on turbofans). Anyway, as long as N2 core rotates fuel pump is working, then if turn on fuel switch, fuel will enter and soak the combustion chamber at low RPM, also generating a dense white vapor trail from the engine's exaust, and most probably end in a hot start once the fuel ignites in combustion.I do not mean to offend you, but I think you should review the way a real engine works on startup and the parameters that are taken into account. Some of these are really difficult to understand in a whole.Tom

>Tom, you missed the point.>>The point is most FS9 FDEs notoriously spools up erradically>and unrealistically. Mine don't. That's the point.I didn't miss your point; only said that what you stated was true but incomplete to be as real as it gets; and not because of your fault but rather because of FS's own limitations.>>As for your point of bleed air and engine pressure, that was>beyond the scope of this post...but since you bring it up, yes>FS does model bleed air pressureFS models ENGINE bleed air, once the engine is running...but air source needed to start the first engine can only come from APU or Ground starter, and neither of them are modeled in FS9, just APU is in FSX but only limited to sound/fuel/power so far I've tested.>but it defaults to 20 psi for start combustion Where do you measure this value?? What I know is FS waits for a certain N2 value to start the combustion once fuel is added (i think is around 20 % CN2); if you add fuel immediately after open the starter, it won't fire up until that value, and then N2 rpm will increase abruptly, the same as EGT..very unrealistic. In the real a/c, RPM won't accelerate much more than normal and EGT will rise in a steady line.>>For instance, in my aircraft, 32 psi are required for a clean>start. Yes, that is a common value. However, a turbine engine will probably start with lower values, but with a noticeable delay to obtain proper N2 rotation. >During start up, if the system does not sense required>pressure it will deny or delay combustion, all through>standard A:vars. Makes it all simpler and more reliable.>And how do you sense bleed pressure, using an Lvar? then you're faking a bit, like me :-). Otherwise, if you use Engine AVars, that's unrealistic.>Hot Start:>>If fuel is added before air pressure and air flow reach>certain levels, a "fake" temperature is added to the standard>TGT. This extra temperature will take 2-3 times as long to>cool. If the engine starts while in this condition, the>temperature goes with it, and as in the real aircraft, a start>attempt with a residual temperature of 150*C will most likely>lead to an exceedance and engine shutdown.If you aborted a start with an EGT/TGT near limits, there is no problem to redo the start process immediately (in fact it is done in real cases); crancking the starter is the best way to lower EGT temperature fast, then when reaching 110-150 C you can put the fuel on and go for a new try. THis is not simulated in FS.>Hung Start:>>I have a bug in my code that I am glad to have. Didn't try to>make this but, on my last flight I unintentionally hung the>start. Why? It was hot and the barometric pressure was low,>and I (in a complacent, FS always works fine and I am in a>rush kinda way) failed to check that I had 32 psi. I had 30!>it got up to 28% N2 then fell then tried to re-light then fell>and I had to shut it down because the TGT was rising.>With 30 psi instead of 32 the engine should start in ALL cases. Is a fact in real aircraft. Probably with a slower acceleration and a bit than normal rise in EGT, but that's all. Hung start would happen whenever engine combustion occurs, engine starts to accelelate towards idle speed and you (or a failure) cut the starter on beforehand, removing bleed air source. The engine will never reach idle speed and will stabilize at low N2 RPM, with higher than normal EGT. When you add power with the throttle, the engine will not speed up and EGT will tend to rise beyond limits. Time to shut try a restart. Not simulated in FS as well.>>Compressor Stall:>>I do not have enough knowledge of compressor stalls to model>this so if you could explain how it happens I would appreciate>it. The only of this kind I have modelled is attempting to>ground start with a tail wind, and N1 is below 4%. Will lead>to a compressor stall and can lead to an engine fire.Strong tailwinds on startup is a common source for engine surge/stall (mostly on older/non FADEC engines) It's simply the N2 spool's compression cycle becomes unstable and or disrupted, and the compressed air escapes forward instead. This produces a loud bang, sometimes a short fireball, and the N2/EPR instrument readings rise and fall abruptly. Could lead to engine damage.Something interesting to "fake": put your plane at service ceiling (40,000+feet),do an abrupt pitch up, and figure out what would probably happen with the engine instruments...>>High Altitude Starts:>>I haven't tested this one yet! Thanks for reminding me!!!!! >Gonna try it now.You need to build up speed to ensure a minimum N2 RPM (due to ram drag,usually 15% will be enough) then put fuel on and wait near two minutes for a slow acceleration and stabilization of the engine. AND be prepared to exceed the EGT limits, but who cares in these cases? So, as you see, real engine behavior is a little more complicated than the basic (but efficient) FS handling. It's up to every one how far to go and match it by code.Tom

Hi Ridgell,>>re;INS system >can i get away with the long 'if'y m:event above? man is it>long and ugly! i have noticed alot of code is sloppy about>closeing all the '{' that are opened and for the most part>with out any ill effects. if the hierachy of '{' & '}' is not>crucial then the code above is doomed. Many times if{ els{ syntax can be avoided by using "bool maths"; I cannot say this is one of those cases though. You can search the forum for a bunch of posted examples.>>this code is repeated 20 times, to avoid repeating it 60 times>i need to nest the conditions, or nest a buch of >statements >If I was you, I would try to code a set of macros to deal with repetitive code :-)>i have never seen an inside of a mouse event so the>nested ifs or visibles seem my only option>There is no chance to insert an inside a section...>>your thoughts ?>Just posted :-)Saludos,Tom

Hi,I really don't want to contradict you but,>if you are trying to replicate the real aircraft...>Which one? aircraft behave different on startup accoring to the type/brand/model of their engines, amongst other things.>>In my aircraft I have video from the cockpit during start up>so I was able to play the video and run the FS Start>simultaneously. The engines spool within +/- 1 seconds and>+/- 2 % N1 from fuel on to idle. No jump or spike...smooth as>a baby's bottom.>My spool up rate in table 1501 is set to 0.0015 >My fuel_flow_gain in the aircraft CFG is set to 0.00075>If your aircraft is a turbofan/turboprop, I think you're missing one critical point: engines need bleed air aid to start, and spool up time has a direct dependency on bleed pressure. FS doesn't simulate this, so in the end if you want to stick to the REAL procedure, you'll need to fake the gauge indicators for N1/N2/N3/EPR through a set of polinomials and other similar stuff. Setting the correct relationship between engine spools, fflow and spool rate as you stated is really important, but not complete IMHO. I know this very well, as I needed several months to develope a precise simulation of my RB211 engines (including all kinds of abnormal situations: hot starts, hung starts, compressor stalls, high altitude inflight starts, etc)Tom

Hi,I think Jan's initial code, with a little amendment, is maybe the only one that will work, at least for this tiny piece of code:(A:AUTOPILOT TAKEOFF POWER ACTIVE,bool) ! if{ (>K:AUTO_THROTTLE_TO_GA) } els{ (L:TO_GA_TRIGGERS,number) ! (>L:TO_GA_TRIGGERS,number) } When TOGA is first pressed, AVar value is 0 because it hasn't been updated yet, remember events are processed before the standard code.But as you don't want TOGA to execute, just fire TOGA again by code to cancel, which is going to send a new TOGA event. Immediately after the code-executed TOGA, the event is processed again and this time your LVar is updated with 1 or 0, depending whether you launched or canceled the command via your hardware switch.Hope this makes sense!Tom

>I was wondering if the following can be put into a Macro?>Very curious to see what you think.>Roelof,Actually it doesn't matter what we could think: it can't :-(Tom

Jan,I use a similar approach for an INS project I'm working on. Click on the keypad and transform that into a valid coordinate's value. With a bit of macros' help, it becomes an easy task. I also use arrays of LVars to store flightplan/user input coordinates and fly the route via LNAV. Tom

Hi,Could you try using 28 instead of 7 and 27 instead of 6?.I think it should work... Tom

Jan,Do you mean which format I use for displaying coordinates? Because for any call to the gpsdll functions, degrees with fractions must be used.Tom

%((G:Var1) 0 >= if{ 'N' } els{ 'S' })%!s! %((G:Var1) abs)%!6.2f!:-)Tom

Hi, Just thought of this practical solution:...Color="%('White' 'Red' (A:Radioheight, feet) (L:radio_ht_adjust,feet) - (A:DECISION HEIGHT,feet) < d (L:ThreeSecs,number) * (>L:ThreeSecs,number)(P:absolute time, number) 1 % 0.5 > d (L:ThreeSecs,number) + 7 min (>L:ThreeSecs,number) * ! (L:ThreeSecs,number) 6 > or ?)"...This should make the text flash white/red for about 3 secs and then stay white. You can play with "7" and "6" values to adjust the timer.Let me know if it works :-)Tom

Jon,GeoCalc functions can be called more than once in a gauge, and they return their values immediately, so there is no penalty in their use. Which IS slow is the A:GPS... set of avar's values. That's the reason for me to use Plane Lat/Lon values present and past, combined with the GeoCalc calls to obtain the a/c tracking/bearing on each cycle.Tom

Ridgell,This is an easy one ;-)%((G:Var1) 0 >= if{ 'N' } els{ 'S' })%!s! %((G:Var1))%!6.2f!I would recommned to use LVars instead of GVars. GVars reset to zero whenever screen mode is changed, and don't support unit conversions.Tom

Ridgell,I prefer to use Plane Latitude because it updates on every cycle instead of GPS Positiom AVar that updates every three cycles. Haven't found any trouble so far. As Jan stated, bearing is a True North reference then you must substract MagVar to obtain magnetic info.Tom

Hi Ridgell,I would recommend to use the gps calls as their calcs must be the same used by FS engine to plot course/distance:C:fs9gps...(L:YourLatitudeFrom,degrees) (>@c:GeoCalcLatitude1,degrees) (L:YourLongitudeFrom,degrees) (>@c:GeoCalcLongitude1,degrees) (L:YourLatitudeTo,degrees) (>@c:GeoCalcLatitude2,degrees) (L:YourLongitudeTo,degrees) (>@c:GeoCalcLongitude2,degrees) (@c:GeoCalcBearing,degrees) (>L:FromToBearing,degrees)(@c:GeoCalcDistance,nmiles) (>L:FromToDistance,nmiles)...That's it -no need to manage complex calcs :-)Tom

Ridgell,I know that you must have thought of this, anyway I remember you that the levers move not only by user drag but also by keyboard/joystick input, hence the actual coordinates of the lever bitmap must be taken into account at any time :-)Saludos!Tom

Ridgell,I've done something similar with my throttles, and even the code is rather complex, I'll try to explain the way it works.To start, you have a background bmp for the throttle range, say 117 pixels high (forget wide for the moment). And you have a lever bitmap that is 32 pixels high.The goal is to let the levers move only when dragged from a range that lies between the height of the lever bitmap.Now, to start a drag you will have a click event first, that you need to detect whether it is within the lever bmp range or not.An example for the left throttle:@Eng1T is "(L:Eng1 Throttle Lever Position,percent)"@Eng1TC is "(L:Left Throttle Center, number)"@BothThrtRange is "@Eng1TC s0 @Eng2TC - s1 abs s2 32 <= (M:Y) l0 - abs 16 <= (M:Y) l1 - abs 16 <= or and", which test that the click is in the lever's range. Note that I left here the right lever part to show that using this method you can move both levers together even if they are splitted!.then,..etc (M:Event) 'LeftSingle' scmp 0 == if{ @BothThrtRange (>L:Eng Throttle enabled,bool) (M:Y) (>L:Eng Throttle Count,number) }...(M:Event) 'LeftDrag' scmp 0 == if{ (M:Y) (L:Eng Throttle Count, number) - sp0 (L:Eng Throttle enabled) if{ @Eng1TC l0 + 117 min 17 max s1 (>L:Left Throttle Center, number) 117 l1 - 0 max 100 min d 163.84 * (>K:THROTTLE1_SET) (>L:Eng1 Throttle Lever Position,percent) } }In the section, register the current Throttle center position : 117 @Eng1T 0 max - int (>L:Left Throttle Center, number)etc...My code is a bit more complex because I also control each lever individually using right drag, and manage the reverse thrust within the same strucuture.Hope this helpsTom