FSUIPC Client DLL for .NET - Version 2.0

[HondaCop]

Paul, that was exactly what I needed! Only thing is that I don't understand VB... Do you have those samples in C#?

BTW, I did contact the author of XPUIPC and there is indeed an offset that tells you if the sim is X-Plane or not... For those interested, it's 0x6FFF... If the sim is XP, then it returns a 1 otherwise it's a 0.

[Paul Henty]

Do you have those samples in C#?

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

Reading Payload and Fuel data

=============================

The payload and fuel data is accessed from a new property on the FSUIPCConnection class called 'PayloadServices'.

It's a good idea to assign this to a local variable to save typing FSUIPCConnection.PayloadServices all the time...

// Get a reference to save so much typing...
PayloadServices ps = FSUIPCConnection.PayloadServices;

Whenever you want to get the latest payload and fuel data you just need to call RefreshData() on the PayloadServices object...

// Get the latest data from FSUIPC
ps.RefreshData();

Once you have done that there are lots of properties on the PayloadServices class that will give you weight and fuel data for the aircraft overall. For example:

ps.PayloadWeightLbs
ps.AircraftWeightLbs
ps.FuelWeightLbs
ps.FuelCapacityUSGallons

Most are self-explanatory and there is Intellisense on everything.

You also have access to the individual payload stations and fuel tanks. Here is an example of iterating through each payload station.

// Go through each station and get the name and weight
foreach (FsPayloadStation payloadStation in ps.PayloadStations)
{
   string name = payloadStation.Name;
   double weight = payloadStation.WeightLbs;
}

You can do the same thing with the FuelTanks collection. This holds a FsFuelTank object for each possible tank. Some might not be in use for the current aircraft though.

To access properties on a specific fuel tank you can use the following syntax: (This gets the current level of the Centre_Main tank in US Gallons. Other properties and tanks are available.)

ps.GetFuelTank(FSFuelTanks.Centre_Main).LevelUSGallons

Changing Payload and Fuel

=========================

You can also write new values to individual payload stations or fuel tanks.

To change the value of payload station, just change one of the weight properties for that station (Lbs, Kg etc).

When you've made all the changes you want call WriteChanges() on your PayloadServices object. This will send all the changed values to FSUIPC.

Fuel tanks are the same except, in addition to changing the weight, you can also change them by setting a new % full level or a volume in Gallons or Litres.

Note that WriteChanges() send both Payload and Fuel changes in one go.

Here's some code to set all the payload stations to 0

// Get the latest values
ps.RefreshData();
// Go through each station and set weight to 0
foreach (FsPayloadStation payloadStation in ps.PayloadStations)
{
   payloadStation.WeightLbs = 0;
}
// send the changes to FSUIPC
ps.WriteChanges();

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

Thanks for the info about the XPUIPC offset.

Paul

[HondaCop]

That did the trick, Paul! Thanks!

BTW, pardon my ignorance, but do we still need to have a reference to the fuel tank's FSUIPC offset in order for your Payload Services class to work or no? I want to update my code to use the PS instead of directly calling the offset and I was wondering if that offset still needs to be set.

[Paul Henty]

BTW, pardon my ignorance, but do we still need to have a reference to the fuel tank's FSUIPC offset in order for your Payload Services class to work or no?

No, you don't need to create any fuel or payload offsets in your code if you use PayloadServices. The DLL manages those for you behind the scenes.

Paul

[HondaCop]

Gotcha, thanks Paul...

[HondaCop]

Paul, sent you a PM.

[greevard]

Below is code for a form that puts two menu items on the FS menu and responds to the user selecting these menu items.

This shows you everything you need to do. If you want to put this behind a real form to see it working, you'll need two timers on the form called 'timerPollForInput' and 'timerKeepAlive'. You'll also have to change the namespace and class name to suit your project and wire up the _load event.

 

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using FSUIPC;

namespace TestApp
{
public partial class MenuDemo : Form
{
	 UserInputServices ui;

	 public MenuDemo()
	 {
		 InitializeComponent();
	 }

	 private void MenuDemo_Load(object sender, EventArgs e)
	 {
		 // Open FSUIPC
		 FSUIPCConnection.Open();
		 // Get a reference to the UserInputServices
		 ui = FSUIPCConnection.UserInputServices;
		 // Add our Menu Items
		 // The first parameter is the key and can be whatever you want.
		 // We'll use this later to see which item was chosen.
		 // The second patamter is the text to display on the menu item.
		 // Putting an & before a letter makes it underlined and becomes the shortcut key.
		 // Set the last paramter to true is you want to FS to pause when the user chooses this item.
		 ui.AddMenuItem("MenuA", "Our Menu Item &A", false);
		 ui.AddMenuItem("MenuB", "Our Menu Item &B", false);
		 // Sink the MenuSelected event so we can respond
		 ui.MenuSelected += new EventHandler<UserInputMenuEventArgs>(ui_MenuSelected);
		 // Start our two timers.
		 // This one keeps FSUIPC from deleting our menu items (every 4 seconds)
		 this.timerKeepAlive.Interval = 4000;
		 this.timerKeepAlive.Tick += new EventHandler(timerKeepAlive_Tick);
		 this.timerKeepAlive.Start();
		 // This one checks to see if the user has selected a menu item (2 times a second).
		 this.timerPollForInput.Interval = 500;
		 this.timerPollForInput.Tick +=new EventHandler(timerPollForInput_Tick);
		 this.timerPollForInput.Start();
	 }

	 private void timerPollForInput_Tick(object sender, EventArgs e)
	 {
		 // Check if the user has selected our menu items
		 ui.CheckForInput();
	 }

	 private void timerKeepAlive_Tick(object sender, EventArgs e)
	 {
		 // Stop FSUIPC from deleting out menu items
		 ui.KeepMenuItemsAlive();
	 }

	 private void ui_MenuSelected(object sender, UserInputMenuEventArgs e)
	 {
		 // This method is called when the user selects one of our menu items.
		 // Check which one and do stuff
		 switch (e.ID)
		 {
			 case "MenuA":
				 // Do menu A stuff here
				 MessageBox.Show("Menu Item A selected!");
				 break;
			 case "MenuB":
				 // DO menu B stuf here
				 MessageBox.Show("Menu Item B selected!");
				 break;
		 }
	 }

	 private void Form2_FormClosing(object sender, FormClosingEventArgs e)
	 {
		 // Remove our menu items from FS
		 ui.RemoveAll();
		 // Close FSUIPC
		 FSUIPCConnection.Close();
	 }
}
}

Paul

 

Excelent Thanks a lot For your Code!!! i will try to make a work!!! 

[greevard]

Hi paul, do you have any error with PMDG ngx (FSX, fs9) Airplane, 

because i can't read autopilot values from OFFSET for this airplanes, but, in another airplanes, works fine! 

 

do you know Why? 

 

Thank's a lot 

 

Demian  :cool:

[Paul Henty]

...i can't read autopilot values from OFFSET for this airplanes, but, in another airplanes, works fine! 

do you know Why? 

 

Hi Demian,

 

PMDG aircraft use their own systems for things like autopilots.  They do not use the normal Flight Sim systems.  Since FSUIPC only gets the standard Flight Sim data, some data from PMDG aircraft is not normally available from FSUIPC.  Other designers of very complex aircraft do the same thing and they and PMDG have their own SDKs for getting the data.

 

However, FSUIPC had a 'bridge' added in 4.84 that lets you get data for the PMDG 737 NGX.  This uses a different block of offsets from normal.  See the document called "Offset Mapping for PMDG 737NGX" in your FSX "modules\fsuipc documents" folder.  This doesn't seem to be available for any other PMDG plane or FSUIPC3 though.

 

Paul

[Pete Dowson]

However, FSUIPC had a 'bridge' added in 4.84 that lets you get data for the PMDG 737 NGX.  This uses a different block of offsets from normal.  See the document called "Offset Mapping for PMDG 737NGX" in your FSX "modules\fsuipc documents" folder.  This doesn't seem to be available for any other PMDG plane or FSUIPC3 though.

 

 

PMDG don't provide any details for access to their aircraft's systems -- except for the 737NGX, for which they provided an SDK which reveals both the special Control numbers for all ther switches etc, and a method of reading out (but not directly setting) all the values and switch positions.

FSUIPC uses the information in the SDK to map the NGX data onto a set of offsets, which is what the document Paul referred to details. If you compare that mapping with the PMDG SDK "header" document which gives these details you will see that it is a direct copy, from their structure directly into FSUIPC offsets.

Unfortunately PMDG never provided such information before, and most such previous  data which can be gleaned has been through folks hacking. The FS9 versions of the 737 do use some FSUIPC offsets I think and folks have found some of those. On FSX, though, I think you have a problem with anything other than the 737NGX unless you pay PMDG to write a driver for you, or pay even more to give you secret information under an NDA.

 

Regards

Pete

[greevard]

Hi Demian,

 

PMDG aircraft use their own systems for things like autopilots.  They do not use the normal Flight Sim systems.  Since FSUIPC only gets the standard Flight Sim data, some data from PMDG aircraft is not normally available from FSUIPC.  Other designers of very complex aircraft do the same thing and they and PMDG have their own SDKs for getting the data.

 

However, FSUIPC had a 'bridge' added in 4.84 that lets you get data for the PMDG 737 NGX.  This uses a different block of offsets from normal.  See the document called "Offset Mapping for PMDG 737NGX" in your FSX "modules\fsuipc documents" folder.  This doesn't seem to be available for any other PMDG plane or FSUIPC3 though.

 

Paul

Thank's a lot

[greevard]

PMDG don't provide any details for access to their aircraft's systems -- except for the 737NGX, for which they provided an SDK which reveals both the special Control numbers for all ther switches etc, and a method of reading out (but not directly setting) all the values and switch positions.

FSUIPC uses the information in the SDK to map the NGX data onto a set of offsets, which is what the document Paul referred to details. If you compare that mapping with the PMDG SDK "header" document which gives these details you will see that it is a direct copy, from their structure directly into FSUIPC offsets.

Unfortunately PMDG never provided such information before, and most such previous  data which can be gleaned has been through folks hacking. The FS9 versions of the 737 do use some FSUIPC offsets I think and folks have found some of those. On FSX, though, I think you have a problem with anything other than the 737NGX unless you pay PMDG to write a driver for you, or pay even more to give you secret information under an NDA.

 

Regards

Pete

Thank's a lot

[HondaCop]

Hello Paul,

 

Is there any advantage in running a timer at 100ms instead of 200mn or even slower? What would be the fastest timing to set a timer and not cause issues with FSUIPC and this DLL client?

[Paul Henty]

Hello Paul,

 

Is there any advantage in running a timer at 100ms instead of 200mn or even slower? What would be the fastest timing to set a timer and not cause issues with FSUIPC and this DLL client?

 

Your refresh rate really depends on what type of data you are getting and how you are using it.  For example a black box flight recorder will require a high refresh rate (e.g. 30 times per second) whereas a moving map may only need to measure the aircraft position every few seconds.

 

Also within the same application you might want to run different timers that work with different offset groups (see my UserGuide for more info on Offset groups) at different frequencies.  Some data you might need to collect many times a second, some you only need maybe once per minute.

 

Another way of doing that would be to use one fast timer and only process() the slower groups on every 10 ticks or whatever.

 

Realistically you wouldn't need to update faster than the FS framerate because the data is only going to be different between frames. 

 

FSUIPC and my DLL can handle refresh rates of around 30 times per second (Timer Interval = 33ms) without a problem and this would be plenty fast enough even for a glass cockpit.  You may even be able to go faster.

 

The other thing you need to consider is the performance of your own program.  If the contents of the timer tick() method takes say 60ms to run then this will be the fastest you can run the timer even if you give it a lower interval (e.g. 40ms).

 

Basically, the rule of thumb is go as slow as you can get away with.  If your application works fine with getting data every 60 seconds then there's not much point having a 100ms timer.

 

Paul

[HondaCop]

Your refresh rate really depends on what type of data you are getting and how you are using it.  For example a black box flight recorder will require a high refresh rate (e.g. 30 times per second) whereas a moving map may only need to measure the aircraft position every few seconds.

 

Also within the same application you might want to run different timers that work with different offset groups (see my UserGuide for more info on Offset groups) at different frequencies.  Some data you might need to collect many times a second, some you only need maybe once per minute.

 

Another way of doing that would be to use one fast timer and only process() the slower groups on every 10 ticks or whatever.

 

Realistically you wouldn't need to update faster than the FS framerate because the data is only going to be different between frames. 

 

FSUIPC and my DLL can handle refresh rates of around 30 times per second (Timer Interval = 33ms) without a problem and this would be plenty fast enough even for a glass cockpit.  You may even be able to go faster.

 

The other thing you need to consider is the performance of your own program.  If the contents of the timer tick() method takes say 60ms to run then this will be the fastest you can run the timer even if you give it a lower interval (e.g. 40ms).

 

Basically, the rule of thumb is go as slow as you can get away with.  If your application works fine with getting data every 60 seconds then there's not much point having a 100ms timer.

 

Paul

 

Thanks for the explanation, Paul. I will just keep the timer that I use to process all FSUIPC offsets at 100ms... :-)

[HondaCop]

BTW guys, I just want to give props to Paul, not only for this awesome DLL which has been a blessing for me, but for the OUTSTANDING support he provides. It's something that really needs to be brought out in the open. He's always available no matter what the question is and is extremely professional. My hats off to you, sir.

[Paul Henty]

BTW guys, I just want to give props to Paul,...

 

Thanks, that's very kind of you.  It's my pleasure to work with you guys.  It's a good little group we have here and there are some great applications being built.

 

Paul 

[lordofwings]

BTW guys, I just want to give props to Paul, not only for this awesome DLL which has been a blessing for me, but for the OUTSTANDING support he provides. It's something that really needs to be brought out in the open. He's always available no matter what the question is and is extremely professional. My hats off to you, sir.

 

I concurr ;-) though I get to work with this DLL from time to time as time permits to develop my app, I must say his support has always been very professional, never getting annoyed for no good reason. All in all, 5 star support. I would even say this should be a forum by itself rather than a thread in a forum.

[Pete Dowson]

I concurr ;-) though I get to work with this DLL from time to time as time permits to develop my app, I must say his support has always been very professional, never getting annoyed for no good reason. All in all, 5 star support. I would even say this should be a forum by itself rather than a thread in a forum.

 

 

I can't create Forums or even Subforums by myself, but I do think at least a Subforum here would be worthy. I can ask SimFlight to set that up if Paul agrees, and transfer this complete thread over when done.

 

However, I am leaving for a 10 day break in a few hours and don't have time. Maybe Ian, if he ses this, can do the necessary.

 

Best Regards

Pete

[Paul Henty]

I can't create Forums or even Subforums by myself, but I do think at least a Subforum here would be worthy. I can ask SimFlight to set that up if Paul agrees, and transfer this complete thread over when done.

 

I think a subforum here would be good as this thread is getting a bit long now but whenever you have time, there's certainly no rush.

 

Thanks,

 

Paul

[Ian P]

I'll try and sort it over the weekend for you.

 

Cheers,

 

Ian P.

[HondaCop]

I'll try and sort it over the weekend for you.

 

Cheers,

 

Ian P.

Thanks, Ian... Well deserved for Paul!

[scrablor]

Hi Guys, Just wondered with this DLL if there is a way to check 2 things:

1. A way to check If the engines are On or Off

2. A way to check the Metar information within FSX

 

Cheers,

 

Dan

[Paul Henty]

Hi Guys, Just wondered with this DLL if there is a way to check 2 things:

1. A way to check If the engines are On or Off

2. A way to check the Metar information within FSX

 

Hi Dan,

 

The DLL gives you access to all information provided by the FSUIPC interface.  Details can be found by downloading the FSUIPC SDK and looking in the document called "FSUIPC4 Offset Status.pdf".

 

To answer your specific questions:

 

1. Yes, but it doesn't look like it's just one offset.  I think you'll need to check a few because different types of engine (reciprocating, turbine etc) have this data in different places.

 

2. Yes, an extended FSX METAR string can be retrieved for an airport or lon/lat location.  See offset B800 in the documentation I referred to above.

 

Paul

[Graham Pollitt]

Slightly OT but are you the same Paul that composes/records music as I have seen a few posts/vids elsewhere and he certainly looks like you :razz: