XML, a little help with electronic tach?

[Jim Robinson 122]

Hi, I made an "Electronics International" tachometer for a panel I'm working on. The tach has a digital readout for RPM which wasn't a big problem, but it additionally has a semi-circle of LEDs that light according to the RPM. For example, the first LED lights at 1200 RPM, the second at 1300 RPM, etc. I can easily display a .bmp (lighted LED) at each RPM graduation without much trouble, but I'm pulling my hair out trying to get each LED to stay lit only through a given RPM range.This is what I'm using to "light the LEDs"; of course they stay on as long as the RPM is above whatever value they are set for. What I want to do is have the 1200 RPM LED go out at 1300 RPM when the next LED lights. (A:General Eng RPM:1,RPM) 1200 >I tried this (and about 100 different derivatives of this) which is something I attempted to adapt from another gauge that works similarly. I don't know why it didn't work, but the LED was just on all the time. It doesn't seem to me like I should have to use an L:var in the first place. It seems like I should be able to use "if" or something in the above code somehow instead but I've tried everything and can't get anything to work. I'm about to give up and start making AI flight plans instead of gauges :) . (L:1200 light, bool)(A:General Eng RPM:1,RPM) 1200 > (A:General Eng RPM:1,RPM) 1300 < || if{ 1 (>L:1200 light, bool) }Any thoughts?Thanks,Jim

[Guest Patrick_Waugh]

You seem to have separated the detection logic from the on/off logic, and I'm wondering if just combining that so there is no order of eval problem.Also, I think you have a boundary condtion problem. (ie what if it's exactly 1300)I do stuff this way:

		<Visible>@isBatteryOn</Visible>				<Element>			<Position X="@P0" Y="@TOP" />			<Select>				<Failures><SYSTEM_ELECTRICAL_PANELS Action="0"/></Failures>				<Value>@isFloatArmedCaution</Value>				<Case Value="1">					<Image Name="@Float_Armed" Bright="Yes" ImageSizes="@imagesize" />				</Case>			</Select>		</Element>		<Element>			<Position X="@P0" Y="@TOP"/>			<Select>				<Failures><SYSTEM_ELECTRICAL_PANELS Action="0"/></Failures>				<Value>@isTest</Value>				<Case Value="0">					<Image Name=".bmp" ImageSizes="@imagesize" />				</Case>				<Case Value="1">					<Image Name="@Float_Armed" Bright="Yes" ImageSizes="@imagesize" />				</Case>			</Select>		</Element>

[taguilo 33]

Jim,You might try this:(* Mind the next line *) (A:General Eng RPM:1,RPM) s0 1200 >= l0 1300 <= andYou need to replace "<" with the & + amp; in the final codeTom

[Jim Robinson 122]

Thanks for the replies, gents.Patrick, I'm afraid you lost me with "@isBatteryOn" :-hmmm . Never seen anything like that in XML, but then again I'm not very advanced in this.The boundary condition problem shouldn't matter I don't think because there is a second LED for 1300 RPM through 1400 RPM. If both LEDs are on momentarily as the RPM rises through 1300 it would hardly be detectable on the gauge I would think. Or am I missing the whole point?Tom, I'll give that a try this evening and post back tomorrow.Thanks again,Jim

[Guest Patrick_Waugh]

Sorry, that @ thingy is a macro.Any yeah, your code would mean that both would be on, at the boundary 1300, and if that's ok then no worries. But easily fixed with a '<'.I haven't coded in XML for awhile, so I'm just pasting in from some proto-type stuff I wrote 2 years ago.

[Jim Robinson 122]

Tom,Sorry it took me so long to get back to this thread. Thank you very much for the help, that works perfectly! I applied it to the manifold pressure gauge as well which operates the same way as the tach.Here's what it looks like, this is before the fix. Sorry, didn't get a screenshot of it with only one LED lit at a time. I think it was a little "garish" with all the LEDs illuminated. It looks much better now.http://www.cat-tamer.com/attach/ei-tach.jpgNow if I just knew exactly what you did ;) . I can see that you called up the engine RPM and stored it, how does "1200 >=" relate to "the stack"? Then I see you retrieved the stored RPM figure (and placed it on the stack?). Then I'm lost with the "1300 &amplt;=" again. Also, what does the "and" do? About now you're probably wishing you'd never replied to this thread, aren't you... :)Thanks a million, I really appreciate the help.-----------------------------------------------------------Patrick,I recognize the @ thingy as a macro now that you pointed that out. Thanks. The "boundary issue" doesn't seem to be a problem. I can't, for the life of me, make 2 of the LEDs illuminate at the same time, so I guess I won't worry about it.I got a chance to try out your GaugeGlow (1.8) tool last night and I have to tell you I'm very impressed. Very good program and I can see you put a lot of effort into the help file. Excellent work, my friend.Jim

[Guest Vorlin]

"Now if I just knew exactly what you did ;) . I can see that you called up the engine RPM and stored it, how does "1200 >=" relate to "the stack"?"Before Tom answers this, you need to prepare in order to be able to follow his answer:4 Cups Coffee6 Ginko Biloba tablets4 Ginsing tablets12 hours of sleep so that you're well restedThe phone number of the local Computer Science professorWhen it comes to asking about the stack, Tom's the right guy to ask... just be sure that you're ready to do more than read his answers. They usually require some background research to understand them completely!And, in all seriousness, be sure you've fully digested and understand RPN because you're about to wade up to your eyeballs in it. A thorough understanding of RPN and how to convert back and forth between RPN and forward reading notation is critical when you start diving into the stack.Scott / Vorlin Edited for lousy spelling at 7:30 AM...

[Guest Vorlin]

Just took a good look myself, this one's not bad at all. This may be worded in a way that's below your skill level but I'm writing it to be understood by anyone who searches this topic later, including novices... (A:General Eng RPM:1,RPM) s0 1200 >= l0 1300 <= andis the same as: (MyVariable) StoreInPosition_0 1200 >= RetrieveFromPosition_0 1300 <= and That's in RPN... now to convert it into something human... (MyVariable) StoreInPostion_0NOTE: When you first store a var, *I think that* you don't need to retrieve it to use it. You can use the storing statement as if it were the var itself... however, it may be referring back tot he original var. Tom, clarify please?To continue, take:StoreInPosition_0 1200 >=and then slide the >= in between the two items previous:StoreInPosition_0 >= 1200 and since the storage statement is the same as the var we have:(MyVariable) >= 1200 Let's put it within parens to keep things organized:( (MyVariable) >= 1200 )... now take the next set and do the same thing:RetrieveFromPosition_0 1300 <=Using the above (skipping the details) we end up with:( (MyVariable) <= 1300 )That only leaves the "and" on the end... and, according to RPN, we simply slip that in between the two statements previous to it:( (MyVariable) >= 1200 ) ( (MyVariable) <= 1300 ) andnow becomes:( (MyVariable) >= 1200 ) and ( (MyVariable) <= 1300 ) So we now have the forward reading version of the statement:Finished RPN code: (A:General Eng RPM:1,RPM) s0 1200 >= l0 1300 <= andTranslated into something easy to read looks like this: ( (MyVariable) >= 1200 ) and ( (MyVariable) <= 1300 ) What s0 and l0 do is allow us to do this operation faster than if we hadn't used them:(A:General Eng RPM:1,RPM) s0 1200 >= l0 1300 <= andis far more efficient than:(A:General Eng RPM:1,RPM) 1200 >= (A:General Eng RPM:1,RPM) 1300 <= andRemember, each time we reference an var, the system has to go look up it's value. By copying it to the stack, we can skip that step during the second compare op because we stashed a copy of our var into the stack. This way, we can simply pop that value back off the stack within the CPU itself rather than run out to RAM, find the tables, locate the var and fetch it's value a second time.However, either will work just fine. When you see people using S0 and l0 it's because they're beyond the point of writing code that simply functions, they're writing code that's effictient too.Their code is efficient, unlike my spelling at 8 am when I have a 101F temperature (fo those using metric, 98.6F is normal). I got cut by a razor at work on Tuesday and it got infected. Yes, I'm on antibiotics... and going back to bed.Scott / Vorlin

[n4gix 4,947]

>However, either will work just fine. When you see people using>S0 and l0 it's because they're beyond the point of writing>code that simply functions, they're writing code that's>effictient too.In addition, it's a lot faster to type out! ;)It's a real pity that XML doesn't support a system similar to C where one creates a properly typed variable (integer, float, string) and then perfom a single lookup function (which may be each cycle or scheduled)... ;)

[Jim Robinson 122]

Thanks for that explanation, Vorlin. That helps a lot.Still a little fuzzy around the edges, but basically I can see that the case value is "1" (display the bitmap) when the RPM is greater than or equal to 1200 and less than or equal to 1300. Still having some problems visualizing what numbers are on the stack or where it even comes into play in this case, but it's probably not important because I think I'll be able to apply/adapt this info to another situation in the future if necessary.Interesting points regarding efficiency and storing values. Something I'd never given a thought to. I think I have a few gauges that I can apply that to.Good luck with the infection. Get well soon.Hi Bill.Thanks again everybody,Jim

[spokes2112 179]

Another way to do this is to have an array of the 17 different light states subtract the minimum and divide by the difference between the max/min divided by 17. ( available options ) = 91.176 rpm per dot.(A:General Eng RPM:1,RPM) 2750 min 1200 - 91.176 / near 1 max case = 1 1 light lit case = 2 2 lights lit case = 3 3 lights lit etc etc case = 17 17 lights litDoing it this way involves 17 different bitmaps but... Only one bitmap will be active on the gauge at one time. Where as the other way you may have 17 of the same bitmaps loaded at 2750. Also the math involved will be queried only once per gauge read instead of being queried 17 times per read.it's a horse a piece. Roman