[Setting offset for Body Yaw (30B8) to simulate helicopter to]

Hi Fred,

this works well except that I loose the inputs from the pedals that do not work anymore. It seems to me that FS possibly alters the body yaw offset in the meanwhile (between the ticks) and that the changes he makes get lost with my process().

Exactly: you keep resetting the yaw back to where it was when you last called Process() 50ms ago, the only difference being your torque adjustment.

To make this method work you need to read the value each tick (not take the value from the last tick), make the adjustment and write the new value.

Try making another yaw offset that is write-only and add it to a new group all of its own. (Keep the one in the exsiting group to read). Then each cycle you need to do this:

1. Process your original read group.

2. read the body yaw offset (30B8)

3. make your calculations and set the modified NEW WRITE-ONLY offset to body yaw offset (30B8)

4. Process the new write-only group to write the new yaw value

I'm not sure how well this will work, but now you're only losing pilot inputs that happen between steps 1 and 4, which presumably is not very much time.

The other drawback is that you now have two process() calls per tick so that's going to slow you down a bit.

setting the rudder value (0BBA), not tried yet but then I have to add the actual rudder input from the user...

This sounds like a better plan to me. The rudder pedals can be disconnected from the sim at offset 310A. Then each tick you just need to:

1. Read the position of the pedals at 332C

2. Make an adjustment for the torque effect

3. write the new value to 0BBA

Again you have two processes (step 1 and 3) - use different offset groups for each step. I imagine this method to be smoother because you're not interfering with the results of the flight modal like the first method. You're just adjusting the inputs to the flight modal.

Paul

[VB]

I've had a closer look at the offsets for fuel. If you want to know how much fuel is in the plane (and possibly change the amount) you need to be looking at offsets starting at 0B74 and another block starting at 1244. (These are 4 bytes and so you need Integers in this case).

Paul

[VB]

Hi,

Firstly the offsets you are looking at are documented as being 2 bytes long, not 4 so you should be declaring the offsets as Short not Integer.

The main problem though is that your code never makes a FSUIPCConnection.Process() call. This is the bit that actually gets data from FS and writes it.

You must call process() to update the values of all of your offsets you have declared. If you have changed the value of any offset, Process() will also send that value to FS.

On your button click, you need to add a Process call after you set Fuel.Value.

If you want your text box to show you the current fuel then it should be something more like this....

Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
        FSUIPCConnection.Process()
        TextBox1.Text = Fuel.Value / 256
End Sub

Have you read the UserGuide.htm in the docs folder? It explains all of the above. Please read it if you haven't.

If you need any more help though, just ask.

Paul

[VB]

You could start with downloading my .NET DLL that lets you talk to FSUIPC from any .NET language.

http://forums.simflight.com/viewtopic.php?f=54&t=53255

It has full documentation and an example project in VB.NET that shows how to use the DLL to read and write to/from offsets in FSUIPC.

It doesn't have any examples that deal with fuel, but you can find out which offsets relate to fuel in the "FSUIPC Guide For Programmers" in Pete's FSUIPC SDK.

Paul

[FSUIPC_version and FS_version]

Please be so kind, Can you tell me a little example for get out versions FSUIPC and FS.

If you download my .net client dll, it comes with documentation and an example application in C# showing you exactly how to read offsets from FSUIPC.

Once you know how to do that, it's a simple matter of reading the correct offsets (0x3304 and 0x3308).

Please look at the documentation and examples that I've already provided:

http://forums.simflight.com/viewtopic.php?f=54&t=53255

Paul

[Heading in the Bermuda triangle]

Thanks Paul. not totally different from C/C++ then! ;-)

Pete

Would be identical, except VB.NET insists on a rather vulgar and ostentatious capital D. ;-)

[Heading in the Bermuda triangle]

can you tell me what that type would be to get the Float64 value from 2B00?

You use a 'Double'.

Paul

[Heading in the Bermuda triangle]

Dim Heading As New Offset(Of Integer)(&H580)

how on earth can I be getting different data to the 32 bit output of interrogator?

Integer in VB.NET is a signed 4 byte integer. You need a UInteger which is a 4-Byte unsigned integer. With signed integers, values greater than half the maximum value (in this case of a 4 byte integer, greater than 2147483647) are used for negative values (i.e. from 0 to -2147483647).

You need to do this:

Dim Heading As New Offset(Of UInteger)(&H580)

But this alone will not solve your heading difference problem. As Pete says you're probably not factoring in the local magnetic variation (see offset 02A0).

Paul

[Problem To Get Variables from FSUIPC]

Public FlagReadyToFly As Offset(Of Byte()) = New FSUIPC.Offset(Of Byte())(&H3364, 256)

Hi Tobias,

What you've declared here is an offset that will read 256 bytes into a byte array.

Offset 3364 is only 1 byte in length, so you should only declare it as a byte (not a byte array):

Public FlagReadyToFly As Offset(Of Byte) = New FSUIPC.Offset(Of Byte)(&H3364)

If you look in the UserGuide.htm in the docs folder, there is a section called "Registering your interest in an Offset" This explains what type of VB variable you should use in the offset declaration according to how the offset is described in the "FSUIPC for Programmers" document from Peter. The top line of the table says that offsets with size 1 should use Byte in VB.NET.

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

I'd like to be able to store the fuel amount shown in the textbox upon starting the app, save that into another text field that isnt updated with the timer so I can view the fuel at start and fuel on landing if that makes sense

No probs - here's what you do...

1. Create the textbox to hold the startup fuel amount

2. Find the sub called: Private Sub Form1_Load...

3. After the call to OpenFSUIPC() add a process() line

4. Get the value from your fuel amount offset, do any maths/formatting you need and put the result in your new text box.

5. That's it. The Form1_Load() only runs when you start the form. So it'll grab the startup fuel amount. After that the timer will update your current fuel amount as normal.

Here's an example of the same thing but I'm storing the Compass Heading at startup as I don't have fuel data in my test app....

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        OpenFSUIPC()
        FSUIPCConnection.Process()
        Me.txtHeadingAtStartup.Text = compass.Value.ToString("F2")
    End Sub

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Is it possible to store a value at startup, and place it into another textfield that is updated?

Can you explain a bit more - I'm not sure what you're trying to do.

Where do you want to store the value at startup? - are you talking about writing a value into Flight Sim or simply storing a value in a variable or form control?

What do you mean by "another textfield that is updated"? What information is being updated and where does it come from?

If you can give me the specific problem you're trying to solve I'll be able to tell you how to do it.

Paul

[VB.NET and Fsuipc]

Sascha,

Pete did answer your question. As long as all the individual reads are stacked up before a single process you will save no time at all by reading a large block and splitting out the individual variables manually.

However if you really must do it like this, here is what you would do...

The Token is merely a reference to the data you want. It's not the actual data. So regardless of the length of the data you are reading the token is always an integer. The token is peculiar to this poorly implemented FSUIPC SDK and is why I wrote my DLL that Pete referred to.

1. You set up the read as normal: You declare the start offset of the data block and the length of the entire data block (ie, the length of all the offsets added together). You get an integer token as normal.

2. Then you process.

3. Then you get your byte array back using the appropriate Get() overload, passing your integer token (which identifies the start of your data block) and the length of the entire data block again (dwSize). This will copy the raw bytes from FSUIPC into the byte array you passed into the Get() function.

4. So now you have an array of bytes which you must split up into individual variables. For this you need to use the BitConverter class. It has methods (e.g. ToInt32(), ToDouble() etc.) which take an array of bytes and a start address in that array where the variable starts. You can get an idea of how to use these by looking at the Get() methods in the source for the VB.NET SDK. Basically if the first variable in the data block is the latitude (64bit int (8bytes)) and the second is the Longitude (also 64Bits (8 bytes)) you would do this:

Dim myLat as Long
Dim myLon as Long
myLat = BitConverter.ToInt64(myArrayFromFSUIPC,0)
myLon = BitConverter.ToInt64(myArrayFromFSUIPC,8)

and so on for each variable in your large data block.

So that's how you would do it. But I assure you it's a complete waste of time.

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

I'm struggling to get any nav or com freq displaying correctly. Does anyone have a sample vbnet 2008 frequency code sample they wish to share?

Hi Hawk,

Take a look at page 1 of this thread - about 8 posts down I answer a similar question about COM2 from Devon. This should show you how to to it.

If this isn't sufficient let me know...

Paul

[getting FLOAT64 from C sharp]

It depends how you are talking to FSUIPC. I suspect you are using the C# SDK from the official FSUIPC SDK download. That doesn't support Float64s which is one of the reasons I wrote my FSUIPC Client DLL for .NET programmers.

You can read about it and download it in the sticky posting above:

http://forums.simflight.com/viewtopic.php?f=54&t=53255

If you're too far down the road of development to switch all your code then let me know and I'll see if I can provide you with a workaround for the original SDK or add float64 support to it.

I'll need to spend a bit of time on though so I'd prefer it if you use my DLL if at all possible.

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Hi Chris,

Sorry for the delay in replying - I still don't have an internet connection after 2 months!

It does look a very strange problem. Does it make any difference if you decalare the type as FSUIPC.Offset? eg.

Dim Offsetxxxx as FSUIPC.Offset(of Integer) = New FSUIPC.Offset(of Integer)(&Hxxx)

As you say it doesn't make sense that the compiler suddenly can't find the type after a few lines.

If the above doesn't work I'll investgate some more.

Paul

[Reading values from FS9 through FSUIPC]

Hi Ricardo,

TestConsoleForm is part of the old procedural-style C# SDK. You might also want to have a look at my Object-Oriented .NET Client DLL which has a number of advantages over the old SDK.

See the sticky at the top of the forum:

http://forums.simflight.com/viewtopic.php?f=54&t=53255

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Hi,

Sorry for the delay - I've just moved house and don't have any internet connection.

How can I get around this problem please? It seems that I need to completely destroy the objAircraft but cant figure out how.

Your objAircraft is destroyed as soon as you set all the references to it to Nothing.

What's probably causing the problem here is that your Offset objects that are created by the objAircraft object are still registered with the FSUIPCConnection class.

The FSUIPCConnection class holds its own references to the offsets. So even though you have released the references to the offsets held by the objAircraft object they are still left if memory because they are registered with FSUIPConnection.

What you need to do it disconnect them before you lose the references. So in your objAircraft objects I sugest you put a method called something like "ReleaseOffsets()". In there call DisonnectGroup() (or DeleteGroup() if you have v1.3 of the library) for all the groups you've declared. If you havn't used groups you'll need to call .Disconnect() on each offset. (I suggest you always use groups as it's easier to disconnect). This will make FSUIPCConnection give up it's references to the offsets.

Call this before setting objAircraft to nothing and you should be OK to create another instance of your aircraft object.

If you want more info on this read my reply to LordOfWings earlier in this thread.

By declaring objAircraft as public but not linking it to a class means when I do this

- objAircraft. I dont get the list of all the methods etc to choose from so I am having to type them in manually. Doing it this way also means that if I mispell anything then my app throws up the error in runtime and not design. Is there a better way around this?

Not really. If they have different methods etc then they are different classes. The closest you'll get is to pull out the common methods etc into a base class and inherit from that when you define your specialised aircraft classes. Then you can declare the variable as the base class type and some intellisense (the common methods etc) will come through.

The other way (or this can be used in combination with the above) is to cast into the specific aircraft object type once you know what type you're dealing with. Presumably you have to know in your code so you can call the special methods. e.g.

Dim objAircraft as Object
Dim acDefault as DefaultAircraft
Dim acLevelD as LevelD767
If objAircraft.Name = "LevelD767" then
   Set acLevelD = objAircraft
   ' Call methods on acLevelD here
else
  Set acDefault = objAircraft
  ' Call methods on default aircraft
end if

Hope this helps a bit.

Paul

[FSUIPC to Excel]

Hi Jörg,

No, I mean to connect via Excel VBA script directly to FSUIPC, so that I can, for example, start a VBA script (on a excel sheet) and read out any values from FSUIPC write them directly into the cells of the sheet.

VBA is pretty much the same syntax as VB6 so you might be able to use the source from the VB6 SDK. Try this:

1. Look in the FSUIPC SDK and open UIPC_SDK_VisualBasic.zip.

2. Open the FSUIPC.BAS file in notepad.

3. Create a new Module in your spreadsheet.

4. Copy and Paste the contents of FSUIPC.Bas into the new module.

5. Delete the top line beginning "ATTRIBUTE..."

You should then be able to use this library in the same way as the VB sdk. I've tried it really quickly and it compiled and the FSUIPC_open() seemed to work. (Told me it couldn't find FSUIPC or WideFS which was the right error message).

It's worth a try. I think there's a good chance it'll work.

Paul

[Delphi and $3380]

fsuipc.FSUIPC_Write(0x3380, datablock, ref a, ref dwResult);

I'm afraid I get the error "cannot convert from byte[] from byte"

That's the wrong overload. You need to use this one that accepts the byte array and also the length of the byte array:

fsuipc.FSUIPC_Write(0x3380, datablock.length, ref datablock, ref a, ref dwResult);

Try that.

Paul

[Delphi and $3380]

Hi James,

Convert.ToByte() is for converting a number string to a real byte. e.g. A string "255" is converted to a byte holding the value 255.

What you need to do is convert the string into an array of bytes.

To complicated things all .NET strings are unicode and FSUIPC wants the string in ASCII. .NET has some classes to do a conversion for you:

The following code will convert a string called "MyString" into a byte array called "datablock" and also do the unicode to ASCII conversion, and zero terminate it on the way.

byte[] datablock = new byte[MyString.Length + 1];

Encoding asciiEncoder = UTF7Encoding.ASCII;

asciiEncoder.GetBytes(MyString).CopyTo(datablock, 0);

You can then use the datablock with the FSUIPC_Write() overload that takes a byte array (byte[]). From memory I think there's an extra parameter on that one to tell it the length of the array.

Alternatively you could convert your code to use my .NET client DLL for FSUIPC. It has a number of advantages over the older SDK you are using, one being that it reads a writes .NET strings directly to and from FSUIPC. All of the above conversion is handled by the DLL. For details and downloads see the sticky post at the top of this forum:

http://forums.simflight.com/viewtopic.php?f=54&t=53255

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Hi John,

Only problem is that the supplied source code for VB.NET which came with .NET shell rev 2.004 is not quite 1 to 1 for the newer VB 2005 code and the built in conversion wizard just ends up with a big blank form

Sounds like you are using the VB.NET shell that is supplied with the FSUIPC SDK. If so, you might want to repost in a new thread as this thread is for my new object oriented .NET client dll. You might not be speaking to the correct audience here.

However, you might want to download my DLL and try it out (it's also free). It has many advantages of the one supplied in the SDK. Check out the first post on page 1 of this thread to download the package with documentation and sample projects.

There are also exmples of reading lon and lat with my DLL on the first page of this thread.

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Hi all,

Version 1.3 has been posted on page 1 of this thread.

Changes since the last 1.1 release are: (1.2 wasn't publically released).

* Fixed error in connection code where a failed connection could lead to never being

able to connect.

* Fixed error in string handling that could cause strings read from FSUIPC to be corrupted.

* Fixed error in string encoding where certain symbols were corrupted when writing to FS.

* Offsets are now written to the IPC file in the order they are created. This problem

will not have affected most people but some offsets (like the ones to send text to FS)

are sensitive to the order in which they appear in the IPC file.

* FSUIPCConnection.DisconnetGroup() has been deprecieated and replaced by

FSUIPCCOnnection.DeleteGroup(). DisconnectGroup was a bad name. From now on you cannot

compile a project that calls DisconnectGroup(). However, projects already compiled that

use this method will containue to function as before.

* Added a new property DLLVersion to FSUIPCCOnnection. This returns a version object

representing the version of the client DLL.

* Added FSX to the FlightSim enum so that you can now write apps that only connect to FSX.

There were other requests that havn't made this build. I've not got much time at the moment as I'm moving house. This release is mainly bug fixes with a couple of easy enhancements.

All requests are still on the list for future versions.

Paul

[Going back to MSFS98 ! (temporarily)]

Offset pitch = new Offset(0x0578);

double thePitch = ((long)pitch.Value;

not sure how to determine datatype for an Offset ?

Offset 0x0578 is marked as 4 bytes in the fsuipc programmers docs. You need to declare your offset as a 4 byte integer - 'int' in C#. A C# long is 8 bytes so at the moment you're also reading the Bank angle into the same variable.

The user guide that came with the .NET client dll has section called "Registering your interest in an Offset" which explains what .NET type to use given the types and lengths specified in the programmer's doc.

double thePitch = ((long)pitch.Value * 360 /(65536 * 65536));

You're casting is a bit wrong here. You need to cast the pitch into a double not a long. Also you should mark the literals as double type literals as well or the compiler will treat them as ints or longs.

double thePitch = ((double)pitch.Value) * 360d / (65535d * 65535d);

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Hi LordOfWings,

Unfortunately I seem to miss the obvious counterpart: ReconnectGroup() because some times you need to reconnect a group as a whole rather than going through each of the offsets programmatically.

I think this would be a nice addition to the next version (when is it coming out?) and should not be difficult to implement as you already have the DisconnectGroup() which simply iterates through the whole list and operates on the offsets matching that group.

The next update will be in July. I'm going on holiday for a couple of weeks soon. I won't be able to do anything until I get back.

About the groups - I don't think you're understanding the whole disconnection thing. It maybe because it's not explained as well as it should be in the docs. It may be because 'disconnection' is a very bad name for what's actually happening.

I'll try and explain a bit better here:

Disconnection for the entire group:

The ability to disconnect an entire group is there only so that you can release the references to the offsets held by the FSUIPC.Connection class.

The only reason you'd want to do that is if:

1. You don't need the offsets anymore, ever, for the rest of your program's lifetime, AND

2. Those offset objects are about to go 'out of scope' in your program, AND

3. You understand enough about .NET garbage collection to care about who's holding references to your objects.

If you're ever possibly going to need the offsets again then don't disconnect them. It's incorrect to disconnect a group of offsets if you want to use them later.

If you don't want offsets in a group updated then just don't call process() for that group.

Registering offsets in a group and never processing them does no harm at all. They just sit there doing nothing.

As for reconnecting the group as a whole: that's impossible. The act of disconnection removes the entire group object (and therefore all the offsets in the group) from the FSUIPC.Connection Class. That's the whole point of the disconnectgroup() method.

You can't then ask it to reconnect the offsets because it's lost all referencs to them.

I think I made a mistake calling it 'disconnectGroup'. On reflection it should have been something like 'UnregisterGroup' or 'DeleteGroup' or 'RemoveGroup'.

I might depreciate that method in the next version and rename it.

Disconnect/Reconnect individiual offsets:

This facility actually does the same thing as the groups but for individual offsets. Again, we are really unregistering or deleteing or removing the offset.

However, the offset can reconnect (re-register) itself becauase it remembers what group it used to be in.

I added this so you've got a very fine level of control and flexibility within the grouping system if you need it.

Again bad naming. Should have been something like MyOffset.UnRegister() and MyOffset.ReRegister().

So in summary: you shouldn't be disconnecting at all. You just don't need to. The control over which offsets are read or written is done by the grouping. Offsets never get updated unless you process the group they are in.

Within the grouping you can further control individual offsets with the Disconnct and Reconnect methods if you need to.

I hope this is much clearer now. I'm afraid I chose bad names for the methods.

If you need any more info I'll be happy to answer any questions...

Paul

[FSUIPC Client DLL for .NET - Version 2.0]

Hi,

There's two seperate problems here...

converted text (another problem)

Some characters (mainly punctuation) are getting converted wrongly.

This is due to the converter I'm using to translate the unicode (.net strings) into ascii (for flight sim). I'll fix this in the next version.

text-message in simulator is showing only at the second time

I've tracked down the reason for this. FSUIPC needs to have the text first and then the control code. When I say 'first' I mean the text must be before the control code in the IPC File that is used to communicate with FSUIPC.

I didn't realise that there was any such sensitivity (I'd never used the text offsets for example). My DLL lays out the IPC file in order of Offset address. This means the text control comes before the text at the moment because the offset address is lower.

Thus the control is being effectively sent before the text which explains what you are seeing.

This is something else I will need to fix. I'll have to preserve the order the local offsets are instantiated in and layout the IPC file in that order.

I'm on holiday for the last two weeks in June so it'll be July before I can get the next version out.

For now you can work around the problem (well the order one anyway) by declaring the Text and TextControl in two different groups. You then need to process() the Text group and then Process() the TextControl group.

This will force the correct order for now at the expense of an extra Process().

Paul