Zach De'Cou Complex Gauge

[tkyler]

This is an answer in response to a question Zach asked over at the org (http://forums.x-plane.org/index.php?showtopic=49683).

I started to answer it over there but changed my mind.

-------------------------------------------------------------------------------

Zach,

As the relationship between speed of sound and temp is non-linear and your mach bezel animation requires 2 inputs, (RPM and air temp) you have to simplify the problem without the use of a plugin.  Any equation with 2 inputs will yield a 3-dimensional plot.  There are 2 simplifying options:  

1.) You assume the lowest possible mach no. you might encounter in flying conditions or

2.)  You assume some average mach no between some temperature extremes.

Case one above gives you a safety margin of never exceeding real mach.

Case 1 example:   If you anticipate flying in no lower than -40 degree C conditions, then you can take the fixed value of 307 m/s as the speed of sound.  I ran a few numbers  with this SoS value and verified the outcome.  Given the range and angles of animations you provided, you should animate the RPM gauge like so:

Angle of rotation of RPM needle = 1.2727 * RPM  (I'm quite sure you got this one...not insulting your intelligence :-) )

Then you need to make the mach bezel a child of the RPM needle and animate it with the following relation:

Angle of rotation of Mach bezel = -1.4088 * RPM  (The negative value has the gauge rotating CCW)

This gives you two animations linearly related to a single RPM dataref.  These values come from basic unit conversion calculations.

Let's verify the mach gauge value at a arbitrary 157 RPM and assumed -40 degree T:

AT 157 RPM @ 50ft radius blade, tip speed = 16.44 rad/sec * 15.24m = 250.625 m/s for the tip speed.

if we assume the lowest value of the speed of sound you may encounter to be at 307 m/s (at -40c), then the mach value at that temp is 250.625 / 307 = 0.8164.

So now lets look at where the animated mach needle will be if using the above relation :

using the above relation of mach bezel angle, we have a mach bezel rotation of (-1.4088 * 157 RPM) = 221.18 degrees.

given your scale of (271 degrees / 1 mach unit), 221.18 / 271 = 0.8162.  This means your mach gauge will read 0.8162

So at 157 RPM, you actual tip mach (assuming -40c) is 0.8164 and your gauge reads 0.8162.  Any temp over that, the real mach is higher and you're in a "safe zone"

and Mu = (1.59 * RPM / airspeed), again a function with 2 inputs and one output.....so no solution here except plugin.  About 6 lines of gizmo lua would take care of that and having your gauge running pretty smooth.  For "accurate" mach values...as opposed to simplified, then a bit more programming would be needed.

[Zach Decou]

Hey Tom. Thanks so much for looking at this. Six lines of Gizmo to have a functioning mu indicator is tantalizing. I seriously need to look in into that. I'm still thinking laterally to try to find a way for mu ratio indication to be manifest by simple moving parts. Maybe it's just wishful thinking. 

Let me explain how I came to the animation convention I did. 1st job- animate the RPM needle against a fixed arc. No problem. I set arbitrary limits for the throw of the needle, divide that number of degrees by the maximum number of RPM the fully deflected needle will indicate, and i should be left with the number of RPM that each degree will indicate. I move the needle one RPM and set a rotate key frame (of course key frame 1 is zero RPM). Next I divided the arc with tick marks. Key frame 2 is 1 rpm using sim/cockpit2/engine/indicators/prop_speed_rpm. 

Job 2: Label and Animate the Mtip arc. remember that this arc shows resultant tip Mach, not just tip Mach in still air. 1st punch into my spreadsheet 0 airspeed and a desired Mtip of 1.0. This produces the RPM at which i can expect Mtip=1.0. I advance the RPM needle to that RPM and put a tick mark on the Mtip arc and label it "1.0". I subdivide the Mtip arc from 0 thru 1.0. Sitting at the ramp and prerotating, the indication is pretty dang close.  Now to animate the arc. I punch in 10 RPM and 10 kts airspeed into my spreadsheet (which I've found to be inaccurate and am now trying to fix) which spits out the Mtip for that RPM and Va. I then slide the Mtip arc to line up current Mtip with the RPM needle. Stamp a keyframe (again after stamping frame 1 at zero Mach). Then I increase the Va entered in the spreadsheet by 10 kts. and repeat the process until I reach the limit of the Mtip arc. It should be noted that the Mtip arc doesn't contain the same number of degrees as the RPM arc. This is because the RPM arc shows an arbitrary high limit, and the Mtip arc indicates a redline of 1.0 (0.99 to be exact). I may choose to match the number of degrees of both arcs, but for now... For Mtip arc, I use sim/cockpit2/gauges/indicators/airspeed_kts_pilot

So as it is, the two elements are independent of eachother. This is for the purpose of increasing Mtip with airspeed. Sitting still, Mtip at x rpm = y. But add 100 kts Va and you have an Mtip of y+100. The Mtip arc will become active when airspeed begins to build to reflect the aircrafts forward velocity being added to that of the tip of the advancing rotor. 

Anyway I read your post a couple times through to make sure I grasp it all. I grasp MOST of it. I do have an idea though. Child the Mtip arc bone to another bone that is set to move with temperature. Use -40 C as the starting point at frame 1. Then keyframe every 5 degrees C or so so the Mtip arc will always be adjusted for temperature. Seems easy enough. Think I'll try that now. 

I don't know if you saw it, but the blend file and spreadsheet I used (incorrect spreadsheet) are in the zip file uploaded at the org. 

That damn mu thing is going to haunt me! Night. 

[Ben Russell]

Ok so... this might do the trick?

--Make a new dataref to output our value into, cdr_ stands for custom dataref.
cdr_needle_output = xp.newDataref("zach/needle/mach_unit")

--Lookup the engines dataref in X-Plane.
dr_engine_rpms = xp.getDataref("sim/cockpit2/engine/indicators/prop_speed_rpm")


--this function is called once for every logical frame.
function main()

	--[[
	X-Plane and C/C++ store data like this
		prop_speed_rpm[0]
		prop_speed_rpm[1]
		...
		prop_speed_rpm[7]


	Gizmo and Lua, like this:
		prop_speed_rpm[1]
		prop_speed_rpm[2]
		...
		prop_speed_rpm[8]
	--]]


	--Zach Says: The RPM needle is tied to sim/cockpit2/engine/indicators/prop_speed_rpm [2]
	--"[2]" in X-Plane is "value number 3" ... 
	--The next function asks for values from the dataref, starting at 3. 1 serve please.
	local rpm = xp.getFloatV( dr_engine_rpms, 3,1 )

	local mu = 1.59 * rpm / acf.getKIAS()

	xp.setFloat( cdr_needle_output, mu ) --write our calculated value into the custom dataref we created at the start

end

...and if we take out (almost) all the friendly stuff, 7 lines..

cdr_needle_output = xp.newDataref("zach/needle/mach_unit")
dr_engine_rpms = xp.getDataref("sim/cockpit2/engine/indicators/prop_speed_rpm")
function main()
	local rpm = xp.getFloatV( dr_engine_rpms, 3,1 )
	local mu = 1.59 * rpm / acf.getKIAS()
	xp.setFloat( cdr_needle_output, mu )
end

...above code goes into a text file called ./scripts/init.lua .... in your aircraft folder.

[tkyler]

Job 2: Label and Animate the Mtip arc. remember that this arc shows resultant tip Mach, not just tip Mach in still air

DOH...talk about tunnel vision!   I did remember this and lost it in the conversion process.  Yea, anytime you have two inputs needed to calculate one output you're generally in custom programming territority.

I'm honestly no paid advertiser for gizmo but this is exactly why Ben has gone through the effort of creating it.  As many people think that Ben's simply out trying to make a buck, people who have known us a long time know it's more than about money and this is a tool not only Ben, Even folks in laminar has said this (a scripting language) is just what the community needs to bring in more "layperson"  programmers.   It does take a small bit of study, but most people with some natural intuition can pick up basic dataref creation and simple formulas with those datarefs.  I think when people see that a few lines of gizmo lua can get them where they want to go, most of the time in less than 30 minutes if they're comfortable with basic dataref creation, maybe they'll look at it differently.  If you want / need any help on it, we'll help you here, in fact, I think your gauge is an excellent case for writing a proper distributable tutorial on a common feature authors need, so if you can be bribed, I'll help you along with it providing you can hand me some screenshots and things along the way that can be used in the tutorial...it's a great first example and its pretty simple. 

Sorry about migrating from the org post....the org has a ton of value in many many areas, but as a struggling up and comer forum, we feel we have some knowledge value here.

Child the Mtip arc bone to another bone that is set to move with temperature

I dont' think this will get you where you need to go.  First a clarification question, the mach bezel rotates counterclockwise to indicate the mach number using the tip of the needle from the RPM indicator, is that correct?

NOW, if you want to use temperature in your calculations for mach  speed, then you'll need a custom script and a few extra lines of code.  The general procedure is to gather you input datarefs, create your output datarefs and then calculate your values.  The general outline of the script might go like so...refer to Ben's example to see how the actual code follows this outline, his order varies a little bit,  the important thing is that all variables, the ones you create and the ones you get from xplane, they come before the "main" function:

-- This is where you grab values from xplane to use in your calculations (the two dashes mean this line is a comment)

GetDataref_from_xplane  "outside air temperature"

GetDataref_from_xplane  "speed of aircraft"

GetDataref_from_xplane  "prop RPM"

-- this is where you specify the custom dataref names that you'll use in blender to drive your animations.

Create_dataref_in_gizmo   "needle for RPM"   (this isn't necessary but I like to keep all the logic in the script...personal preference)

Create_dataerf_in_gizmo   "mach_indicator"   (bezel in this case, could be needle by someone else)

Create_dataref_in_gizmo   "MU_indicator"      (recessed bezel?)

--  In gizmo there is a function called "MAIN" and it runs every frame in x-plane.

--  The basic framework of the main function is like this

function main()   -- this line is required to begin the main function

 PUT YOUR EQUATIONS HERE.

end   -- this line is required to terminate the 'main' function

[Zach Decou]

Tom- Of course I can be bribed! I'd love to give it a whirl (though i may have solved the mu problem, but it's VERY inelegant, ugly, and difficult to read on the instrument). The plugin side is something I need to dive into. First though, I am going to read through the Gizmo doccumentation. Indi's script looks incredibly simple, and so does yours Tom. Let me know what you need. A tutorial would be a great asset to both newcoming X-plane authors, as well as this forum  and I'd be thrilled to be a part.

Zach

[tkyler]

Ok then.  I'm going to being assembling the tutorial but not publish any posts or anything while you work through the problem, that would defeat the purpose of your learning.  Do I have your permission to use your blender file and gauge in the creation of the tutorial? 

[Zach Decou]

Absolutely you can use the files. I am on the road for the next couple of days and won't be of any help until Sunday.

I will be checking the forums though.

Have a good weekend.

[tkyler]

I'm well into writing the tutorial, but am going to wait until you have had a go at it Zach.  What I do not want to do is put any more ideas into your head about how to approach the problem as you'll learn a lots more solving it on your own.  As you work through it, we can take what you have achieved and work that into the tutorial for others.

[Zach Decou]

There are some functions reccommended above that appear to only be available to those who have Gizmo Pro. The above reccomendations do make perfect sense- make a new dataref, use known x-plane datarefs in an equation to write a new value to our new custom dataref, refrence that new value to drive an animation.

But I won't be able to purchase Pro for another couple months. I'm looking for a workaround at present. As I am new to programming (reading through my wife's textbooks) I may be misintepreting what I am seeing at x-plugins.com (e.g.  http://x-plugins.com/wiki/Gizmo/api/acf ). If I am, please let me know.

I have some ambitious ideas for this aircraft. I would like to develop an automated rotor management system (ARMS for a snappy acronym) that adjusts rotor trim and collective pitch per pilot inputed parameters. example: Pilot inputs an rpm or Mtip for jump takeoff. ARMS will manage engine NG to spin up the rotor to the inputed value, then maintain that value until the pilot engages the takeoff sequence. Then the clutch disengages as collective is automaticallty pulled and rotor mast trim and cyclic automatically trimmed to keep the nose to the horizion... I would like ARMS to manage the rotor in all phases of flight. I like the idea because X-Plane doesen't do any of this natively. Plus it give me a chance to figure out how to get all these pieces fit together. Battery is almost dead so I'll get off of here...

Thoughts?

Zach

[Cameron]

There are some functions reccommended above that appear to only be available to those who have Gizmo Pro. The above reccomendations do make perfect sense- make a new dataref, use known x-plane datarefs in an equation to write a new value to our new custom dataref, refrence that new value to drive an animation.

But I won't be able to purchase Pro for another couple months. I'm looking for a workaround at present. As I am new to programming (reading through my wife's textbooks) I may be misintepreting what I am seeing at x-plugins.com (e.g.  http://x-plugins.com/wiki/Gizmo/api/acf ). If I am, please let me know.

Hi, Zach,

The wording needs to be corrected a bit on our end to be more brain friendly. In simple terms, whatever you can do in Pro, you can do in Home, and the free 10 minute trial timer version for that matter. Gizmo lite is something that is pretty much no more. The entire API works across all three versions equally with the exception of being able to use DRM features on non-payware products.