Simple Sample vb.net code

[BUM]

Hello all,

I'm a newbie here trying to tie into FS2004 with vb.net. I find the best way to learn is by example. I have looked at the vb.net sample code with the SDK, but it is lacking somewhat. There is no description of what the parameters being passed are (i.e., dwOffset, token, dwSize, etc.). Also, the basics on how exactly to retrieve info is unclear. I assume this is legacy stuff whose explanation is "understood". As I prefer not to try to reinvent the wheel, does this forum have an area where sample code is posted by users? If not, could someone show me how to retrieve a peice of data by clicking a button (maybe bank?). I tried the following code after using the FSUIPC_Initialization and FSUIPC_Open in the form_load:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim t_Bank As Integer

Dim Bank As Integer

Dim dwResult As Integer

''try to read bank...

Dim Errcatch As Boolean

Errcatch = FSUIPC_Read(&H57C, 4, t_Bank, dwResult)

Errcatch = FSUIPC_Process(dwResult)

Errcatch = FSUIPC_Get(t_Bank, Bank)

TextBox1.Text = t_Bank

TextBox2.Text = Bank

TextBox3.Text = dwResult

End Sub

When I do this code repeatedly, t_bank counts up in 8 increments and bank and dwresult remain zero. Errcatch was always true. Also, when using FSinterrogate, there is an expression...*360/(65536*65536). Am I supposed to use this to actually calculate the bank after I get some number from FSUIPC_Get?

If anyone has some code and pointers they would be greatly appreciated.

Thanx!

[Pete Dowson]

I have looked at the vb.net sample code with the SDK, but it is lacking somewhat.

I hope someone who knows VB.Net will chime in and help, as i don't know it at all and some things about it seem positively weird. I guess most of the weirdness (for me) stems from it being a "managed" (interpreted) language rather than a true fully compiled one.

There is no description of what the parameters being passed are (i.e., dwOffset, token, dwSize, etc.).

Well, apart from "token" which is a puzzle to me and only seems to appear in the managed language versions, the others were certainly explained in my original notes for C programmers. I'm sorry if none of it came through in those voluntary contributions.

Anyway:

dwOffset is the offset as listed (in hexadecimal) in the main document with the long tables of variables. I think in VB you need to be careful of those greater than 7FFF since VB seems to assume 8000 and more are negative, and fills the rest with ones, making FFFF8000 etc. To stop that I think you have to postpend another $.

dwSize is simply the size of data (the number of bytes) you want to read or write. The FSUIPC interface can read or write as much as you like, up to the buffer size limitations, but usually, if you are reading into a single variable rather than an array or structure you would set this to the byte size of the variable you are using, such as 4 for a 32-bit integer.

The only other parameters defined in the FSUIPC interface are a pointer to where to place the result (your variable) -- or, for a write, where to get the value to write -- and a place to put an error number (result) should anything go wrong. You don't need to look at the result unless the function returns FALSE, to indicate a failure.

does this forum have an area where sample code is posted by users?

Not sure that Forums can have sub-forums like that, but there have been plenty of threads with examples, at least in VB. Some in VB.NET too, I'm sure. Sorry, but scanning or searching may be the only way to find them. Limiting your search to this Forum with VB.Net as a keyword should turn up something.

When I do this code repeatedly, t_bank counts up in 8 increments and bank and dwresult remain zero. Errcatch was always true.

The latter two sound okay, but I'm not sure what is going wrong, if anything, with the data. I'm afraid someone who knows VB.Net would have to help there, unless your compilation system comes with a debugger, in which case you should be able to trace it through. After all, all the source code is provided and is part of your program. FSUIPC (the bit I know) only gets involved in one SendMessageTimeout call within the Process routine.

Also, when using FSinterrogate, there is an expression...*360/(65536*65536). Am I supposed to use this to actually calculate the bank after I get some number from FSUIPC_Get?

Are you using FSInterrogate as your reference rather than the documentation, where it does tell you the units?

FS stores many angular values in 16 or 32 bit integers, making maximum use of the capacity of those bits. So, since the range of angles is only 360 degrees, the most accuracy is achieved by making the whole range of values possible in 32 bits represent those 360 degrees.

Thus 360 degrees would be represented by the maximum number possible, plus 1. The maximum number in 16 bits is 65536, the maximum in 32 bits is 65536*65536. Thus you can see how the formula is derived for converting the value you read into a proper angle in degrees.

For accuracy and ease, you should copy the value you read into a floating point variable (I assume VB.net WILL do the conversion as other languages do?), and only then multiply by 360 and divide by 65536*65536 (or just by 4294967296, which is the same thing but harder to remember ;-) ).

Regards

Pete

[BUM]

Pete,

Thanx for the post and shedding a little light on the variables! Yes I tried to do a search on vb.net and got 43 pages worth of posts. Haven't had time to go through all, but it's on the todo list. :wink:

Yes, I was looking at FSinterrogate as a reference to the Hex numbers, variable type, and "size". It seems like an easy way to sort through what you need.

Hopefully someone a little more versed in vb.net (or VB 6.0 for that matter) will help out. I know how it is to have a "favorite" language and stick with it. Personally, I can't stand C (only b/c I'm not good at it)!

thanx Pete and i'll keep digging!

B

[Paul Henty]

Hi,

Your code looks fine. I've copied and pasted it from your post and I get a proper value back in the Bank variable.

Must be something wrong somewhere else.

Have you got a registered copy of FSUIPC? I remember a similar post not so long ago where the problem was an unregistered version.

Paul

[Paul Henty]

I guess most of the weirdness (for me) stems from it being a "managed" (interpreted) language rather than a true fully compiled one.

Hi Pete,

.Net code is not 'interpreted' like BASIC or a scripting language.

Any program written in a .net language gets compiled to native machine code before they are run. They're as 'fully compiled' as any C or C++ program.

The only thing that isn't 'native' about them is that they can't be run directly by the operating system (as of WindowsXP) as they're not programmed against the Win32 API. They have to sit on top of a framework that does talk to the OS and Win32.

This will all change in Vista as the Win32 API is being replaced with the WinFX API which is written in .net. So .net will become the native code (both in terms of being compiled to machine code and also being run directly by the OS).

Paul

[Pete Dowson]

.Net code is not 'interpreted' like BASIC or a scripting language.

Any program written in a .net language gets compiled to native machine code before they are run. They're as 'fully compiled' as any C or C++ program.

The only thing that isn't 'native' about them is that they can't be run directly by the operating system (as of WindowsXP) as they're not programmed against the Win32 API. They have to sit on top of a framework that does talk to the OS and Win32.

So what stops them containing calls to the main Windows API DLLs? What stops them doing standard memory allocations and using memory pointers, the lack of which appears to be the reason behind the "token" stuff in the .NET FSUIPC implementations? Everything I've read points to a lot of "protection" imposed on these prograns by the 'framework' layer that smells exactly like interpretation to me.

Evidently I've not understood what I've read about them, but I also don't understand how they can be so restrictively "managed" with something very like what I call interpretation.

Regards,

Pete

[scruffyduck]

So what stops them containing calls to the main Windows API DLLs?

Nothing actually, but generally it is not done that way - it is just a different language, and as mentioned above it is certainly not interpreted. In fact the NET framework is just a set of DLLs like the win32 API is but we 'call' them instead of the API directly. I use C# and VB interchangeably in some cases the program constructs are easier in one than the other but in a lot of cases they are pretty much identical apart from case sensitivity, curly braces and semi colons :D :D

Managed code refers to the fact that the NET languages manage things like garbage collection and disposal of variables and objects when they are not needed. It also means that NET langages are less likely to have memory leaks etc You can get past all that and work unmanaged, and in some instances it is important to dispose of objects yourself, but to be honest there is no point

I have just made my .NET dll available on my web site - http://www.scruffyduckscenery.co.uk and I am putting a new forum up for VB.NET and FS

[Paul Henty]

Hi Pete,

So what stops them containing calls to the main Windows API DLLs?

As scruffy said, nothing. You can call any Win32 DLL if that's the platform you're running on. In fact the .net FSUIPC SDK code does just that. It calls User32.dll and Kernel.dll just like your C example.

This is a useful thing to be able to do the moment as we're still running on Win32 OS. For example, the FSUIPC client uses windows messages which do not exist in .net. It's essential that we can call Win32 dlls for legacy reasons like this.

If one was to imaging a version of FSUIPC written in .net, you'd use the Remoting Services to exchange data between different processes instead of IPC.

Interestingly, the remoting services also work between different machines on a network. So if FSUIPC was written in .net there'd be no need for a seperate WideFS program as any FSUIPC client program could access the FSUIPC server on the same machine or a networked one. They wouldn't care. There would also be no need to write any networking code either - that's all handled by the framework.

What stops them doing standard memory allocations and using memory pointers

Standard memory allocations arn't required because you don't manage your own memory - the framework does it for you and cleans up after you. Explicit memory allocations are a Win32 concept.

You can't normally use pointer arythmatic in .net because you could get into a mess like corrupting the stack or you might try to read or write memory that you isn't yours.

Having said that - if you're using C++.net or C# these do have full pointer functions available, but if you use them you have to declare your code as 'unsafe'. It's only really useful for porting existing code. There's no reason to use such techniques in .net. Ponter arythmetic is simply not required to write a .net program.

the lack of which appears to be the reason behind the "token" stuff in the .NET FSUIPC implementations?

The token stuff is not nessasary. I suspect it's only there because the author was from a win32 background and didn't know enough about .net at the time. There are much tidier ways it could have been done without pointers or the token system.

I also don't understand how they can be so restrictively "managed" with something very like what I call interpretation.

The managing is not done by interpreting the code, or running it inside a 'proper' Win32 process and looking over it's shoulder. It's done by inserting calls to the various framework libraries at compilaton time.

Paul

[Paul Henty]

I have just made my .NET dll available on my web site - http://www.scruffyduckscenery.co.uk and I am putting a new forum up for VB.NET and FS

Out of interest - Is this a wrapper around the VB.Net code that's in the SDK at the moment, or have you written the whole thing from scratch?

Thanks,

Paul

[scruffyduck]

Out of interest - Is this a wrapper around the VB.Net code that's in the SDK at the moment, or have you written the whole thing from scratch?

It started as a wrapper for the vb stuff in the SDK. It still uses API calls since I havent had time to sit down and change it, but I have modified the way they are used in some places. It is a half way house in that it makes reading of some offsets easier by making the result available via properties - I plan to make all offsets read/wriable via properties or similar at some point - I'd like to get away from explicitly calling offsets and use structures or enumerations instead. Other than that it is still using tokens but I want to get rid of that when I find the time :D

[Pete Dowson]

If one was to imaging a version of FSUIPC written in .net, you'd use the Remoting Services to exchange data between different processes instead of IPC.

Interestingly, the remoting services also work between different machines on a network.

That sounds like it uses TCP/IP routing, then, even on the same PC. Similar maybe to remote DDE.

So if FSUIPC was written in .net there'd be no need for a seperate WideFS program as any FSUIPC client program could access the FSUIPC server on the same machine or a networked one. They wouldn't care. There would also be no need to write any networking code either - that's all handled by the framework.

Yes, but such data exchanges would be far less efficient than direct exchange using shared memory, which is what FSUIPC's IPC uses -- the same technique as used in Debuggers for dealing with process memory. There is really nothing more efficient than sharing memory for transferring data in one PC.

And having all of FSUIPC's offsets universally accessible across the network without specific data requests would represent a huge amount of traffic compared to the efficiency with which WideFS is able to run, supplying as it does only changed data for those programs specifically requesting it. To judge how it would be, try putting FSInterrogate on a Client, select ALL offsets and have it regularly reading them. And that's with WideServer sending only changes -- imagine if everything was sent all the time.

Believe me, a lot of thought went into the design of my programs.

You can't normally use pointer arythmatic in .net

I wasn't thinking of pointer arithmetic, but simply the apparent problem in passing data by reference (i.e. pointers), as is needed in the FSUIPC interface. I had been led to believe that all this "token" business and the need for an extra "Get ..." after the FSUIPC Process was needed because of this inability. Otherwise, why aren't the values being read directly into the variables as in non-managed languages?

The token stuff is not nessasary. I suspect it's only there because the author was from a win32 background and didn't know enough about .net at the time. There are much tidier ways it could have been done without pointers or the token system.

Ah, in that case, would you like to volunteer a more efficient, more friendly, solution for the SDK, pretty please? ;-)

Regards

Pete

[Paul Henty]

Ah, in that case, would you like to volunteer a more efficient, more friendly, solution for the SDK, pretty please? ;-)

:-) I did volunteer back in February but I didn't do it because a guy called Pelle was already doing one.

I'll have another look at it though.

Paul

[Pete Dowson]

:-) I did volunteer back in February but I didn't do it because a guy called Pelle was already doing one.

For VB.net? I thought he was a Delphi programmer. I'll ask him next time he's around -- I think he has very busy periods work-wise.

I'll have another look at it though.

Thanks! You're a star! ;-)

Pete

[BUM]

Paul,

Thanx for looking at my code. The problem probably is that I have not registered it yet. I bought a key, but I am not an admin where I'm using FSUIPC and am having to wait for the IT guys. Thanx! I don't feel like a total idiot now! LOL Hopefully the IT will come down today and register it for me then I'll know for sure.

Jon,

Still looking for that dll (I e-d ya yesterday). Thanx again.

BTW - does anyone know what the maximum "update rate" for this dll is? I have a motion table that MUST update at 256 Hz and I was hoping to put the Read/Process/get statement inside the update loop.

Thanx,

Brad

[scruffyduck]

Brad

I mailed you yesterday to say that you can download it from my website (http://www.scruffyduckscenery.co.uk).

I think you will find that FSUIPC operates at the frame rate so you cannot get data faster than that, but Pete will obviously be able to confirm that (or not if I have it wrong :D )

[BUM]

Didn't get the email yet, but I just saw the link above. Thanx!

Brad

[BUM]

Jon,

FYI...If the program was written with VS2005 it won't work with earlier versions. It'll give an error saying "Not a valid solution" or something like that. There is a workaround...Basically open a new project with whatever earlier version you have, import the modules used along with any other code. It sounds a little silly but it works.

Brad

[Pete Dowson]

I have a motion table that MUST update at 256 Hz and I was hoping to put the Read/Process/get statement inside the update loop.

256 Hz? That's allowing less than 4 milliseconds for each double process switch (switching to FS to ask for the data and back to you to process it). I don't think Windows is capable of that on any PC yet, at least not consistently and allowing for any work to be done by either party. It is in the process switching where most of the time is spent. The rest is then mostly taken up with message queuing in Windows. All this is outside FSUIPC's control, which does things as fast as it possibly can once it gets the request.

In any case, for most values you will want, FS is only updating them at a frame rate -- not necessarily the visual frame rate, but not much different from it. If I were you I'd regulate FS to a frame rate you can always sustain (say 25 fps) then interpolate for the other 9 values you need per frame.

Regards,

Pete

[scruffyduck]

FYI...If the program was written with VS2005 it won't work with earlier versions. It'll give an error saying "Not a valid solution" or something like that. There is a workaround...Basically open a new project with whatever earlier version you have, import the modules used along with any other code. It sounds a little silly but it works.

Well I am not going to have more than one version around - it becomes a configuration nightmare and I only work in VS2005 so it will not be of any use to you if you are using an earlier version. You can still get a free copy of the VS2005 express editions which are absolutely fine but if your shop has not upgraded and you are required to work in an older version................ :(

[BUM]

Pete,

I know its fast (especially for visuals), but that's the way the table's activeX interface works. I suppose I could keep passing redundant values, I'm just worried about the funciton calls "slowing down" the loop. I guess I'll find out when I get an IT down here to register the dll!

Jon,

I've been begging for 2005 since it came out in November, but to no avail. :cry: But thanx for the sympathy! :lol:

Have you gents done any motion base work? I'm just curious if there are any "tricks" I should be aware of (you know, like tilt left to feel right g forces) anything crazy like that.

Brad

[Pete Dowson]

I'm just worried about the funciton calls "slowing down" the loop.

Sometimes they will, sometimes they won't -- you can't tell. Windows has loads of other things to do. The Process call (not the others) is not only relinquishing control to FS, but also to anything else that wants to run. You cannot guarantee your 256 Hz in any case unless you have a tight loop in a thread which is set to high priority and shares only with a Sleep(4), say, to regulate it to 250 Hz.

You would have to get the FS values in a separate thread, or the main program, probably on a timer tick call (SetTimer) every 55 mSecs (the normal tick resolution), and have your fast driver loop just picking up the last value from wherever the FSUIPC access part dumps it. It may be better to do some interpolation as well, if you can.

Have you gents done any motion base work? I'm just curious if there are any "tricks" I should be aware of (you know, like tilt left to feel right g forces) anything crazy like that.

I haven't done any, but I should think it is all based on the accelerations, not on the pitch/bank and heading values. Then you have to slowly bring the base back to centre before you run out of tilt capability. Only accelerations are felt -- you can add the thump of the gear coming down and the landing too of course. And a continuous gentle vibration (probably easier done with a bass woofer).

Regards,

Pete

[BUM]

I agree that Acceleration and other cues from the sim are necessary, but I thought bank and pitch would be a good place to start.

For added realism in the future I'm thinking of giving these a try as opposed to/ along with the standard subwoofer...

http://www.crowsontech.com/go/crowsontefault.aspx

Thanx again and I'll let you know how things work when I get an IT down here!

Brad

[BUM]

All,

It appears that registering the dll was the problem. Everything works perfectly now! Unfortunately my motion base is down til next week so I won't be able to try the values out on it yet, though. I'll post how things go and thanx again!

B