Paul Henty
-
Posts
1,654 -
Joined
-
Days Won
74
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Paul Henty
-
-
Hi cyberconin
There is only one 'pool' of offsets stored in the DLL. If you try and create an offset more than once (in the same group) then you'll get this error.
Each time you're creating a new instance of class 'c' you're trying to create the same offsets again.
I could modify the DLL to accept these 'duplicates' and return a reference to the offset that's already there.
There's an extra complication where I would have to check that all the attributes are the same. For example if one class wanted an int from 0x1234 and another wanted a short from 0x1234 then this would have to still throw an error.
When I wrote the DLL I decided against this approach because I could lead to confusion if the programmer didn't realise he/she was getting a reference to the existing offset instance rather than a new instance of that offset.
With the current 1.3 version you can share offsets between classes (or instances of the same class) by creating another class that just handles your offsets. This could be a static class or a proper class that you only create one instance of. You would then need to pass a reference to this single instance into all the instances of other classes that need the data (probably in the constructor).
So it goes something like this (Not real code or offset values!)
Class FSUIPCData { public Offset airspeed = new offset(0x1234); public Offset altitude = new offset(0x5678); } Class c { private FSUIPCData data; public c (FSUIPCData Data) { data = Data; } private void doSomething() { int currentAirspeed = data.airspeed; } }In your main program you'd do something like this:
FSUIPCData data = new FSUIPCData(); c c1 = new c(data); c c2 = new c(data); c c3 = new c(data); c c4 = new c(data);
You'll need to manage the Process() calls in your main program loop or timer. You don't want all your instances of class c calling Process() for example.
With this method it's very clear that each instance of class 'c' is referencing the same instance of the offset. That is, not each instance of class 'c' has it's own instance of the offset.
I prefer this approach for it's clarity but I could be persuaded to go the other route where it's handled the in DLL as described at the top.
Which method would you prefer?
I'm intending to release 1.4 in the next month or so, so I could squeeze this change in.
Let me know if you need any more explanation...
Paul
-
... which doesnt deal with data types or bytes or bits and things like that, so offsets
and specific data types is a new thing to me.
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
-
I have used an read. What could be wrong here?
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
-
How can I echo the information begin get on my vb.net app.
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.
Also I kind of still don't understand how to get information with the bytes and everything
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
-
How can I declared AppTittle please forgive me I am new to the vb.net language.
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
-
May you please give me an example on where it should go?
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
-
I am confused where do I put the dll file at I am using Visual Basics 2008 Express
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
-
Is it possible to write to FS / disable time acceleration by detecting a change in the number and setting it straight back to 1x.
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
-
Pete, Another question with your permission: You had mentioned I should specify the string length but I can't see how if the declaration of the offset is in the declaration area and if I put it everytime I use the offset I get an error: offset already exists.
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:
Dim fsuipc_TextDelay As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&H32FA)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
-
Is it really a bug or i'm doing something wrong?
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
-
sorry I see now. The other bytes are in the preceeding offset numebrs such as 3000, 3001 etc
I will put it in an array and use strConv when needed
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
-
Is it possible to use the DLL as well in VC++ like in C#?
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
-
the altitude has alot of numbers after the "." is there anyway to make that not appear?
You can round the altitude after the conversion like this:
altFeet = altitude.Value / (65536.0 * 65536.0) * 3.28084altFeet = Math.Round(altFeet, 0)
The second parameter of the round function specifies how many digits to keep after the decimal point.
Paul
-
Also for the altitude how would I convert it?
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
-
I have looked for the offsets and have tryed but all I get is random numbers for the altitude. If I try to landing rate I get a rate but most of the time it is 0.0 or -1.0.
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 NextYou'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 NextThis 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
-
Also the data output in interrogator looks nothing like 29.92.
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
-
But my heading is 224, but my code reads -117,735343845561
What am i doing wrong?
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 SubI 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,
Processing twice per tick with a read only offset doesn't seem to work. I tried also this as a test, I am setting the old value into the new value.
give an erratic behaviour Yaw increases very quickly, while it should stay the same as before.
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
FSUIPC Client DLL for .NET - Version 2.0
in FSUIPC Client DLL for .NET
Posted
Hi Pat,
I've never tested it in a 64bit environment. At the moment the project is set compile to a duel 64/32 bit binary. On your 64bit system it will be running as a 64bit DLL. This could be causing a problem. Are there any specific errors you can give me?
I could just try compiling the DLL to force it to run on the 32bit compatibility layer. That might solve the problem but I'm not too sure what the problem is at the moment.
Paul