Paul Henty

I recommend that you read the UserGuide.htm that came with the .NET client dll package. The section called "Registering your interest in an Offset" has a table in it that tells you what C# type to use according to the offset length and/or the type of data stored in it. Paul

If the offset is only 2 bytes long, why are you using an int and then converting it? You simply need to declare the offset as which is a 2 byte integer. Paul

I really can't help you learn how to program in VB.net on an internet forum. I can help you with specific questions about my DLL and getting data to and from FSUIPC. For general programming you need to get a book or look online for some tutorials. The best I can do is point you to the test application I included in the package. It shows exactly how to display the data from FSUIPC on a form. All the data from FSUIPC comes from 'offsets'. An offset is simply an address or index (expressed as Hexadecimal number) to the bit of data you want. You find the offset address by looking at the "FSUIPC for Programmers.pdf" document. This is found in the FSUIPC SDK which you need to download if you haven't already. (http://www.schiratti.com/dowson.html) When you find the offset address, that's the number you use when you declare the offset in VB. The TYPE of variable you use depends on the size of the offset. My "UserGuide.htm" document tells you what VB type to use depending on the information provided by the "FSUIPC for Programmers.pdf" document. If you are new to programming then I recommend you learn how to program a basic windows application in VB, without even worrying about FSUIPC yet. Getting data from FSUIPC and using it is not a simple thing. If you are trying to learn basic programming at the same time then it's going to be extremely confusing and frustrating. Paul

If you look at the top of the file where you copied the code from, you'll see the declaration: Private Const AppTitle As String = "FSUIPCClientExample_VB" Put this at the top of your file in the same place. Just under the "Public Class ..." line. Paul

If you have unzipped (extracted) the "FSUIPCDotNetClient1.3.zip" package then there is nothing more you need to do. Presumably you know where on your hard disk the files are? Just leave them there. When you add a reference to your VB project, you just need to tell Visual Studio where the DLL is on your disk. Which you already know. I can't tell you where you downloaded it to. The instructions for adding a reference to a VB project are set out step-by-step in the readme.txt file as I said in the last message. You find this under the DOCS folder where you unzipped the package. Paul

It doesn't matter where on the disk you put it. You can just leave it wherever you unzipped the package. The important step is to add a reference to it in your VB project. This is described step-by-step in the readme.txt file under the heading: "Installation (Step-by-Step for Visual Studio)". When you build your application a copy of the DLL will be placed in the output folder with your .exe file. If you want to deploy your app on other machine you just copy everything in the output folder, including my DLL. Paul

Hi Topdog, Everything you need is in my .NET FSUIPC Client DLL package, available in the sticky at the top of this forum: http://forums.simflight.com/viewtopic.php?f=54&t=53255 It contains the .NET DLL that any .NET language can use to read and write to/from FSUIPC, it has a user guide with example code in VB and an example application in VB. Paul

Hi Hawk, Yes. Declare the offset: Private SimRate As Offset(Of Short) = New FSUIPC.Offset(Of Short)(&HC1A) Then in your timer loop, put this after the process() call: If SimRate.Value <> 256 Then SimRate.Value = 256 256 = 1x (real time). Depending on how often your timer executes it'll allow the new rate for a fraction of a second before resetting it. Paul

That's really a question for me. With my DLL you can't do what Pete suggests like you can with the SDKs for all other languages. The DLL always writes the full size declared for string offsets, padding with 0s at the end. I will modify the DLL to only write the length of the actual text for a future release, but for now there's nothing to worry about. It's very slightly inefficient like it is at the moment, but it's not doing any harm. (As long as you declare the correct length of course ;-) ). Paul

Hi Omer, It's a bit late where I am so I'll check this out properly tomorrow. But an obvious mistake I can see at the moment is: Offset 32FA is only 2 bytes long and therefore should be declared as Short not Integer. By declaring it as Integer you're accidentally overwriting the next 2 byte offset as well (32FC). Similarly, 0366 should also be a Short. I don't know if this will fix your problem though. Dim fsuipc_TextDelay As Offset(Of Short) = New FSUIPC.Offset(Of Short)(&H32FA) Dim fsuipc_ground As Offset(Of Short) = New FSUIPC.Offset(Of Short)(&H366) Also your fsuipc_writeTxt offset should really be declared as write-only otherwise you're reading the text back in each time you process(). Dim fsuipc_writeTxt As Offset(Of String) = New FSUIPC.Offset(Of String)(&H3380, 256, True) That's what instantly leaps out at me - I'll look more closely tomorrow. Paul

Hi Omer, I've tried to recreate what you're doing but I can't make it crash. I've setup a project that reads data from FSUIPC regularly. I then have a button to write a message to the FS screen for 2 seconds. I run the program and press the button. The message appears on the screen. Then I change the aircraft and everything is fine. Can you post some code in here so I can see exactly what you're doing? I especially need to the see the relevant offset declarations and the code that writes the string. It may be useful if you can post in a small bit of code that will reproduce the error for me. Also the FSUIPC log (see Pete's post above) would also be useful. @Pete: The disconnect is a concept within the DLL. It allows you to 'turn off' offsets you've declared so that they are not read or written in subsequent 'Process' calls until you 'reconnect' them again. Paul

My DLL will let you read a write ASCII strings to/from FSUIPC. Just define the offset as String and specify the length (in this case 6). It'll handle all the conversion to a .net string for you. Paul

Hi Thomas, I don't know anyone who has tried it, but as far as understand the answer is 'yes' with Visual Sudio C++ 2005 and onwards. The DLL is a standard .NET class library so C++ should be able to reference it like any other part of the .NET framework and use the classes inside it. All my documentation has examples in VB.NET and C#, so as long as you can translate one of those into C++ you shouldn't have any problems. I can't really help you on that because I don't know C++ at all. If you're used to programming for the .NET framework in C++ then I'm sure you'll have no trouble. I'd be interested to know if you get it working... Paul

You can round the altitude after the conversion like this: The second parameter of the round function specifies how many digits to keep after the decimal point. Paul

You mean to feet? Just multiply by 3.28084. Dim altFeet As Double altFeet = altitude.Value / (65536.0 * 65536.0) * 3.28084 For the touchdown rate, the conversion is this for feet per second: Dim touchrate As Double = (touch.Value /256.0) * 3.28084 Or this for feet per minute: Dim touchrate As Double = (touch.Value /256.0) * 3.28084 * 60.0 Paul

It would really help if you could paste the relevant bits of your code in here. It's difficult to help without seeing what you're doing. I need to see the declaration of the offsets and where you are using the values for the altitude and landing rate. Anyway - here is how to get the altitude using the DLL. It gives a result in metres. You'll need to convert to feet if you want feet. I've had to assume you're using VB. Private altitude As Offset(Of Long) = New FSUIPC.Offset(Of Long)(&H570) ... FSUIPCConnection.Process() Dim altMetres As Double altMetres = altitude.Value / (65536.0 * 65536.0) I can't help on the landing rate because I don't know what offset you're trying to use for that. Paul

I think I've just seen the problem... For n = 0 To stations - 1 dblarr(0) = cargoArray(n) Buffer.BlockCopy(BitConverter.GetBytes(CDbl(cargoArray(n))), 0, test, 0, Buffer.ByteLength(BitConverter.GetBytes(CDbl(cargoArray(n))))) myPayload(n).Value = test Next You're always copying new values into the 'test' byte array and then setting that object as the value of the offset. However, all your offsets are getting set to the same byte array. You just keep changing its value with every loop. You need to make a new byte array for each one: For n = 0 To stations - 1 dblarr(0) = cargoArray(n) test = New .... (Whatever you declared it as) Buffer.BlockCopy(BitConverter.GetBytes(CDbl(cargoArray(n))), 0, test, 0, Buffer.ByteLength(BitConverter.GetBytes(CDbl(cargoArray(n))))) myPayload(n).Value = test Next This wouldn't be a problem with doubles as they are Value types in VB.net and not Reference types like Byte Arrays(). You always get a new copy of value types automatically. Paul

Slopey, If there any reason you're using a Byte array and then converting the bytes to doubles yourself? The DLL supports reading and writing of Doubles directly. It would save you a lot of trouble in the code if you just made an array of Offset(Of Double). It may fix your problem. It sounds like the DLL is having a hard time tracking which data have been changed and therefore which to write back to FS. Paul

The offset gives the pressure in Millibars, the 29.92 you're seeing in FS is the pressure in Inches of Mercury. 29.92 inHg = 1013.25 mb So the conversion is like this: Dim pressureOffset as Offset(of UShort) = new Offset(of UShort)(&H0330) ... Dim pressureInHg as Double = pressureOffset.value / 16.0 / 33.8653 Unfortunately, I can't help on why the value in interrogator isn't changing, but Pete's back tomorrow. Paul

Firstly, offset 0580 is the heading in Degrees TRUE. You're probably seeing the heading in Degrees Magnetic. You need to get the Magnetic Variation from Offset 02A0 (see the FSUIPC Programmer's Guide). The negative heading is because you are using an signed Integer. Try using an UInteger for the offset. Dim hdg As Offset(Of UInteger) = New FSUIPC.Offset(Of UInteger)(&H580) But, you'll still need to correct -tve headings (and headings over 360) after doing calculations with headings, by adding or subtracting 360. So your code needs to do something like this: Dim hdg As Offset(Of UInteger) = New FSUIPC.Offset(Of UInteger)(&H580) Dim magvar As Offset(Of Short) = New FSUIPC.Offset(Of Short)(&H2A0) Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick FSUIPCConnection.Process() Dim hdgTrue As Double = hdg.Value * 360.0 / (65536.0 * 65536.0) Dim hdgMag As Double = hdgTrue - (magvar.Value * 360.0 / 65536.0) If hdgMag < 0 Then hdgMag += 360 ElseIf hdgMag > 360 Then hdgMag -= 360 End If Label1.Text = hdgMag End Sub I can't test this at the moment but you get the idea... Most people write a little function to 'normalise' the headings to between 0 and 360 to save writing the same code every time you do some maths on a heading. Paul

Hi BoXon, There are two problems here. First, your specific error. The VB.NET compiler checks for overflows with literals at compile time, unlike VB6. What's happening here is that because hdg.Value is an Integer and so is 360 it's treating (65536 * 65536) as an Integer type. But 65536 squared is outside that range of a signed Integer in VB.NET. So it won't let you compile because the code will produce an overflow error at runtime. The solutions is to enter the literal values as Double type literals by adding a .0 on the end like this: Dim hdg2 As Double = hdg.Value * 360.0 / (65536.0 * 65536.0) This will force the calculations to be done as doubles (the hgd.Value will automatically be cast into a Double by VB). The second problem is that you're creating an Offset each time the timer ticks. You should only create the Offset once. The FSUIPC Client will throw an error if you try to create the same offset twice. The easiest way is to make them class-level private variables (See my example VB.NET app). So they go under the 'CLASS' statement at the top of your class, but above the first Sub or Function. Hope that helps... If you have any more questions just ask. Paul

You could use my FSUIPC Client DLL for .NET languages. See the sticky at the top of this forum: http://forums.simflight.com/viewtopic.php?f=54&t=53255 It has extensive documentation and sample projects for Visual Studio 2005 in C# and VB (I'm pretty sure it'll load into 2008). If you're porting an exiting project and need the old 'procedural' style FSUIPC interface, then the current FSUIPC SDK has a zip in it called: UIPC_SDK VB .Net Shell Revision 2.004 This contains a VB.NET project that can be used in a similar way to the old VB6 one. It works but it's not pretty. Paul

Hi Fred, I also tried this and I didn't find the same problem. Here is my code: Offset oYaw = new Offset(0x30B8); Offset oYawWO = new Offset("WO",0x30B8,true); private void timer1_Tick(object sender, EventArgs e) { double yaw; FSUIPCConnection.Process(); yaw = oYaw.Value; oYawWO.Value = yaw; FSUIPCConnection.Process("WO"); } I believe this is the same as your test, but you didn't post your real code. Running this has no effect on the sim at all, as expected. If I change the yaw velocity between the read and write then it does affect the yaw. If you post your real code in here or send it via PM I'll have a look at it and see if I can see what's wrong. I'm pretty sure it's possible to do what you want with this method though. Paul

Hi Fred, 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. 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

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