December 7, 200421 yr This is something I have always had a problem getting to work right, so I am done beating my head against the wall, and want to get this thing settled once and for all. I am doing an altimeter that has roll over digits for 10,000s, 1,000s, and 100s. I want them to 'sit' on the number until it reaches the next incriment. I did this by using the nonlinearity section, and that works great. In fact everything works great except for that they will not repeat. Once they reach 9, they do not start over again. Heres the code I am using for the 100s: (A:Indicated Altitude, feet) 100 /How do I get the numbers to repeat? Any insight is greatly welcomed!
December 8, 200421 yr Hi Ian,Stop beating your head against the wall ... I know by personal experiance that doesn't help at all :-) 1. Add the modulo (%) function to the value.So for the 100s: (A:Indicated Altitude, feet) 100 / 10 %2. To ensure the bitmap itn't "rolling" between two values: use the int function (= round to lowest integer value).Saves you all the *.9 definitions in the Nonlinearity.So for the 100s: (A:Indicated Altitude, feet) 100 / int 10 %3. It would save you a lot of typing if the Alt-Drum bitmap is linear (i.e. pixel distance between the center of the digits on the bitmap is equal between any two digits).So: no need to define all Item values between 0 and 9, resulting in:Cheers, Rob Barendregt
December 8, 200421 yr Thanks a ton Rob! Works perfect... I think I need to play with it a little because the numbers kind of 'snap' to the next value rather then a nice rolling action. This cant be too hard to fix though. I define every number so I can add a little imperfection :) I like to make some numbers a little off center. Thanks again!
December 8, 200421 yr Hi Bruce,I see what you mean with "snapping" vs. "rolling" to the next number.Now I understand why you had all the Item Values defined (so the numbers are fixed between *.0 and *.9, and "roll" between *.9 and *+1.0)So you can also add this instead of point-2:(A:Indicated Altitude, feet) 100 / 10 % so 9 > if{ l0 } els{ l0 int }In short: value is only truncated when between 0 and 9. Cheers, ROb
December 8, 200421 yr I will give this one a shot... Thanks for all your help, I really appreciate it. I don't know why these things always give me headaches lol.Best Regards
December 8, 200421 yr Rob,What does "so" mean?Jan"Beatus Ille Procul Negotiis" Jan "Beatus ille qui procul negotiis..."
December 8, 200421 yr Hi Jan,Oopsss.. Should have been s0 , not soIn short: store top-of-the-stack in temp. variable 0Note1: sp0 does the same, but also removes the value from the stack.I.o.w.: "d sp0" is the same as "s0"Note2: visibility of these 0,1,2,3,.... variables is limited to one schedule period of the gauge (unlike e.g. the G:Vars).Note3: Instead of "s0 9 > if{ l0 } els{ l0 int }" I could have written"d 9 <= if{ int }" which does exactly the same.Cheers, Rob
December 8, 200421 yr Ian or Rob,Now i become curious for your complete code of the altimeter!Jan"Beatus Ille Procul Negotiis" Jan "Beatus ille qui procul negotiis..."
December 9, 200421 yr Well, I got it working perfectly now! I ended up using a combination of methods. I ended up using just (A:Indicated Altitude, feet) 100 / 10 % and then defining the nonlinearity. It is probably not the most efficiant way of doing it, but it works exactly how I want it to, so I can't complain :) In the end the code ended up being: (A:Indicated Altitude, feet) 100 / 10 % Here is a bonus question though: how yould I define the the values for the Kohlsman digits. I want them split up like the altimeter numbers. I tried (A:Kohlsman setting hg,inHg) 10 / 10 % but that didnt seem to do it. I was thinking 10, 1, .1, .01 for the 4 digits. I think it is probably a bit more complicated than that though.Thanks once again.
December 9, 200421 yr Hi Ian,Is this a kind of standby altimeter?. I guess it is because you use a 100th precision instead of 10th. I've made a Boeing-style altimeter (and stdby as well) that works pretty close to the real one. Hope this to be helpful for you and others.-First, rolling happens from bottom to top. It means you need to design a bitmap that has a descending order from top to bottom (ie 0 9 8 7 6 5 4 3 2 1 0 see attachment)-Second, rolling sequence for the fist two groups (10,000 and 1,000) starts at aprox 80 % of its current value, but rolling for the last group (100) is continous. It means that, for example, a "1000" position starst to roll towards "2000" when its value reachs 1980.Here is the code that works for me: (A:Indicated Altitude, feet) 100000 + 100000 % 10000 / flr s0 (A:Indicated Altitude, feet) 100000 + 10000 % s1 9980 >= if{ l1 100 % 80 - 20 / } els{ 0 } l0 + (A:Indicated Altitude, feet) 100000 + 10000 % 1000 / flr s0 (A:Indicated Altitude, feet) 100000 + 1000 % s1 980 >= if{ l1 100 % 80 - 20 / } els{ 0 } l0 + (A:Indicated Altitude, feet) abs 100000 + 100000 % 1000 % 100 / I don't use the "100000s" factor in my newer gauges; I extracted this from the 747 altimeter and left it as is cause it works...:-)I can also post the kolshmann's digits coding if you want.Regards,Tom
December 9, 200421 yr The altimeter is for an older mid-sized plane as a primary altimeter. I will probably be adapting the code to a Beech1900D panel that I am working on as a side project. I defined all of my digits in the nonlinearity section for minor imperfections that would have no doubt evolved with the instruments age. In doing this, it also allowed me (in a simple way that my mind can understand hehehe) to control when the digits roll. As you can see, I used 1.9, 2.9 etc for the 100s. I just added another decimal place for the higher sets, ie 1.99 for 1000s, and 1.999 for 10000s. this makes them roll together, so upon reaching 10,000feet, all of the digits will roll over in unison. I am sure this is about as inefficiant as you can make it, but I am an artist, not a programmer ;) Maybe one day I will get all the extra stuff down. Thanks for all the imput though! I hope someday I can help all of you out in some way.
April 20, 201016 yr Moderator Hi Ian,Is this a kind of standby altimeter?. I guess it is because you use a 100th precision instead of 10th. I've made a Boeing-style altimeter (and stdby as well) that works pretty close to the real one. Hope this to be helpful for you and others.-First, rolling happens from bottom to top. It means you need to design a bitmap that has a descending order from top to bottom (ie 0 9 8 7 6 5 4 3 2 1 0 see attachment)-Second, rolling sequence for the fist two groups (10,000 and 1,000) starts at aprox 80 % of its current value, but rolling for the last group (100) is continous. It means that, for example, a "1000" position starst to roll towards "2000" when its value reachs 1980.Here is the code that works for me:<Element Name="Altitude 10 thousands"> <Position X="25" Y="28"/> <Image Name="StdbyAlt_Digits1.bmp"> <Nonlinearity> <Item Value="0" X="0" Y="170"/> <Item Value="10" X="0" Y="0"/> </Nonlinearity> </Image> <Shift> <Value> (A:Indicated Altitude, feet) 100000 + 100000 % 10000 / flr s0 (A:Indicated Altitude, feet) 100000 + 10000 % s1 9980 >= if{ l1 100 % 80 - 20 / } els{ 0 } l0 + </Value> </Shift> <Clip Left="24" Right="65" Top="28" Bottom="44"/> </Element> <Element Name="Altitude thousands"> <Position X="38" Y="28"/> <Image Name="StdbyAlt_Digits2.bmp"> <Nonlinearity> <Item Value="0" X="0" Y="170"/> <Item Value="10" X="0" Y="0"/> </Nonlinearity> </Image> <Shift> <Value> (A:Indicated Altitude, feet) 100000 + 10000 % 1000 / flr s0 (A:Indicated Altitude, feet) 100000 + 1000 % s1 980 >= if{ l1 100 % 80 - 20 / } els{ 0 } l0 + </Value> </Shift> <Clip Left="24" Right="65" Top="28" Bottom="44"/> </Element> <Element Name="Altitude Hundreds"> <Position X="54" Y="28"/> <Image Name="StdbyAlt_Digits2.bmp"> <Nonlinearity> <Item Value="0" X="0" Y="170"/> <Item Value="10" X="0" Y="0"/> </Nonlinearity> </Image> <Shift> <Value> (A:Indicated Altitude, feet) abs 100000 + 100000 % 1000 % 100 / </Value> </Shift> <Clip Left="24" Right="65" Top="28" Bottom="44"/> </Element> I don't use the "100000s" factor in my newer gauges; I extracted this from the 747 altimeter and left it as is cause it works...:-)I can also post the kolshmann's digits coding if you want.Regards,Tom Fr. Bill AOPA Member: 07141481 AARP Member: 3209010556 Avsim Board of Directors | Avsim Forums Moderator
Create an account or sign in to comment