Reading/setting gauge values

[Guest mlgoff]

We have been contracted to interface a Honeywell HT-9100 FMS with FS2004. This will be a real-time harware interface (most of which is already done). I need to be able to read data from the various gauges on the main panel and write back to the Auto-pilot and HSI. The Panels SDK talks about using "named variables" to communicate between gauges using C/C++. It also talks about XML gauges but doesn't specify how these comminucate with one another. I don't want to rewrite the Auto-pilot guage or the HSI (and frankly I don't have the time to rewrite them either).Is the source-code available for the guages so I can add the needed named variables? Or, is there a way to do this using the XML gauges? Is this something that can be done via the Netpipes SDK?ana assistance would be greatly appreciated.

[ddawson 35]

This stuff is all defined in the GAUGES.H header file, included in the SDK. When you include this file in your C/C++ source code, you have access to all of the FS defined variables and commands - you don't have to break into an existing gauge to get the information you are looking for. The SDK does provide a sample gauge that you can use as a starting point to create what you need."Named variables" are nothing more than pointers - the functions defined in GAUGES.H just provide a convenient way of setting them up. If you want to start working with atoms (something I know nothing about) you could presumably make an FS 'named variable' available to any application.XML gauges can share 'L:variables' C/C++ gauges can read and set these variables as well (only in FS9). I don't think you will be able to communicate with an external application, or with hardware, in any way using XML gauges though.Not sure what else to add right now - I suspect you will have more questions...Doug

[Guest mlgoff]

Actually that clears up a whole lot for me.So if I understand this correctly, I can create a button/gauge on the main panel that acts as both server and client for the variables I want to access. I can then add (if needed) L variables to the HSI and Auto-pilot (and others as needed) that can be read and updated by the button/gauge.The only thing that I can't seem to locate is information on how to access the L variables of one gauge from another. I don't see and equivalent to register_var_by_name() for the XML gauges. Unless all L variables are public by default and . will create pointer to any declared L variable regardless of the gauge in which register_var_by_name() is actually called. Is that how it works?

[ddawson 35]

Martin,I would envision that you gauge would read required FS variables (declared in C as MODULE_VAR's). This information would be passed to the hardware using the routines you have developed. FS 'Key_Events' would be triggered by the gauge, based on commands received from the hardware.I don't think you really want to get into XML L:vars for anything. However the commands to do so in C are: ID (FSAPI *check_named_variable) (PCSTRINGZ name); ID (FSAPI *register_named_variable) (PCSTRINGZ name); FLOAT64 (FSAPI *get_named_variable_value) (ID id); FLOAT64 (FSAPI *get_named_variable_typed_value) (ID id, ENUM units); void (FSAPI *set_named_variable_value) (ID id, FLOAT64 value); void (FSAPI *set_named_variable_typed_value) (ID id, FLOAT64 value, ENUM units);It's a two step process - get the ID for the L:Var, and then read or write the variable.The ID values aren't magic - they are simply integers, starting at zero and counting upwards, based on the number of L:Vars in use. Unfortunately, the ID values are dynamically assigned, hence the need to check them before accessing the L:Var.Keep in mind that XML L:Vars are just user declared variables. If you want to use them in a C/C++ gauge, you should really declare them there, using the 'register_named_variable' function. There is no harm in declaring a variable this way that has already been created, either by an xml gauge or by another C gauge. The function would be more appropriately described by 'if_necessary_register_named_variable' There is no formal declaration syntax in XML - you just use the variable.Doug

[Guest mlgoff]

Doug,Thank you again!As you probably know the FMS manipulates the autopilot and HSI.So I have assumed (dangerous I know) that I need to use XML L:Vars because I don't have the C code for the HSI and other gauges and I what documentation I can find leads me to believe that many of the values I need to push back to FSim do not already exist. If I had access to the C code for the gauges then I would skip the XML approach entirely. Do you know of a repository for the gauge C code?Martin

[n4gix 4,947]

Martin, you're failing to see the forest for the trees... ;)All guages communicate with FS bi-directionally. What the HSI displays, it gets from the sim!All your module needs to do is "talk to FS." Let FS "talk to the other gauges..." ;)There are very, very instances where what you might need to access will be "custom variables" that are unique to one, single gauge.

[Guest mlgoff]

Doug,I was just reviewing your previous post (for about the 10th time) and something clicked that didn't before. I think I see how to do just about everything I need to do. there are a few things that are still a little fuzzy. But if they don't clear up by the time I get to them I will post another question (if you don;t mind).In the meantime, thank you very much for your patience and assistance.

[Guest JeanLuc_]

Martin,you may consider contacting Reality XP. Reality XP has a unique technology in production with the GNS simulation, which enables:1) overide any default FS variable to allow your software feed any FS EHSI gauge for example with YOUR values instead of the FS computed values (used in the GNS for the CDI deviation and many other "nav" related variables2) make the FS default Autopilot work with YOUR CTS (Course To Steer) value instead of the FS computed value when the A/P is in NAV modeHope this helps!

[Guest mlgoff]

Thank you for the heads up but I don't think they will be of any use to me for the following reasons:1. They make a point of stating on their home page that their products are designed only for XP. I must support W2k. The two are similar enough that Reality XP's stufff might work but then again maybe not.2. Their EULA states the following: Prohibitions User may not distribute the Freeware. User may not modify, translate, or make derivative works of the Freeware Product. User may not sub-license, rent, lease or provide service bureau services such as Freeware leases or rentals with any portion of the Freeware Product.Reality XP's commercial license may allow the redistribution but if my client has to pay license fees to redistribute internally they won't accept the use of Reality XP's products.Thanks anyway though, it's good to know about them.

[Guest JeanLuc_]

I guess my point was not clear enough. Let me re-phrase: to build its products, Reality XP has developped unique technologies such as the one mentioned above. They are "showcased" (read: they work) in their products for some of the product functions.Now, Windows XP only is a requirement for the products. That does not mean this requirement apply to these technologies: they apply only to the products Reality XP sells.As for licensing, you refer to EULA for products, not for technologies...Hope this helps!