fsuipc vs VB.Net

[PhilippeV8]

Hi Pete,

I am having problems again with the .Net code for fsuipc.

When using my own code I can write my program and make it do nothing but read the nav and com etc values. Nothing but that: all goos well.

I can set up my code such that it does nothing but write the "virtual joystick button presses". Nothing but that: all goos well.

Now as soon as I do both in my code, the readings go wild after .. lets say 1.5 to 2 minutes.

When trying to use the code from Bob Scott which comes straight from the FSuipc SDK, it doesn't even want to 'render' because there are 2 errors into his code.

One is a ";" somewhere. Which is an unrecognised character.

And the other is "t_FSUIPC_Lib_Version" which is not declared.

Maybe you can help .. if not you can maybe forward me an address where I can contact Mr Scott via E-mail.

Tnx

[Pete Dowson]

Now as soon as I do both in my code, the readings go wild after .. lets say 1.5 to 2 minutes.

Please use the logging tools provided in FSUIPC to help you resolve such problems. You can log all IPC reads and writes and see exactly what you are doing.

When trying to use the code from Bob Scott which comes straight from the FSuipc SDK, it doesn't even want to 'render' because there are 2 errors into his code.

One is a ";" somewhere. Which is an unrecognised character.

And the other is "t_FSUIPC_Lib_Version" which is not declared.

Which ZIP and which file, please?

Regards,

Pete

[PhilippeV8]

With logging tools you mean "fsinterrogate.exe" from the SDK ?

Which zip, which file ?

Obviously the zip with the .Net code in it.

Go to this site:

http://www.schiratti.com/dowson.html

Scroll down to the bottom. Download the "fsuipc sdk 21st release".

Inside you'll find "UIPC_SDK VB .Net Shell Revision 2.003.zip".

Inside the files are .Net project. When opened in VisualStudio.Net one can not compile this project due to the 2 failts into the code.

I wish you could have someone with good knowledge of VB and VB.Net look at this part of the SDK because it simply does not work.

[Pete Dowson]

Which zip, which file ?

Obviously the zip with the .Net code in it.

Er ...there's some misunderstanding here. ".Net" is not a language, it is a suite of language compilers and development aids sold by Microsoft. I myself use Microsoft .Net 2003, but I only use the C and ASM parts of it. There are also C++, C#, VB, Java and maybe other parts I don't have or hanen't looked at!

Inside you'll find "UIPC_SDK VB .Net Shell Revision 2.003.zip".

Ah, you mean VB.Net! Thank you.

[Duh! Only now do I see you said "VB.Net" in the subject -- problem is the subject isn't repeated in each message of the thread. Sorry]

I wish you could have someone with good knowledge of VB and VB.Net look at this part of the SDK because it simply does not work.

I am assured that it was working and tested before submission. I will ask around, but perhaps if you know what is wrong you could tell me? Or at least point me in the right direction. To start with, which file inside the ZIP contains the errors?

Regards,

Pete

[PhilippeV8]

Ok, in the meantime I had filtered out some faults myself, still no joy though. Then I got Scott L Fausel's code .. again no joy.

So it must be that I am doing something wrong elswhere ...

Ok on the errors in the code file "FSUIPC Shell.vb" that is in the SDK zip:

At one part there is a ";" sign which VB.Net does not want to recognise so removing that one works fine.

Then there is a section:

            ' write our Library version number to a special read-only offset
            ' This is to assist diagnosis from FSUIPC logging
            ' But only do this on first try
            Dim t_FSUIPC_Lib_Version As Integer
            If (i < 2) And (Not FSUIPC_Write(&H330A, 2, t_FSUIPC_Lib_Version, dwResult)) Then
                FSUIPC_Close()
                FSUIPC_Open = False
                'Console.WriteLine("Stopped line 455")
                Exit Function
            End If

That is missing.

It should come in front of the line:

            ' Actually send the request and get the responses ("process")

Which you can find using a search.

These 2 changes make it possible for the code to be compiled. However it does not link to fsuipc. So in Bob's code the initial function calls to open fsuipc, if it doesn't work it "End"s the program so by removing that you can actually get the GUI to show and stay on your screen. Adding a button which calls the fsuipc_open command and shows a msgbox stating "ok" or "not ok" gives me the info if connected or not.

So this is how I know that this mod doesn't make the code connect to fsuipc.

I don't know where there is something different still but I got Scott L Fausels code working (connecting to fsuipc). However as said, still it goos funny after a minute or 5.

Values (like Nav and XPDR) are read every 100ms. When they go weird they stay to that weird value. Then when I hit a btn in my (hardware) cockpit so to send a "virtual joystick button" or else .. to trigger a "write" command that weird value changes. Maybe this gives a clue ...

What I do is:

I have a timer going round in 100ms. First it will call "ReadFromFS" and pass an address and a length to that function. Inside that function first the read is called, then the process, then the get, then it will return the value (xpdr or whatever). Same thing over and over again untill I got all my values (maybe 8 or 9 I need). After that still in the timer I got a code which will call a "WriteToFS" function IF a variable it true. So whenever I press a switch it is sensed by the Photon scanning code and will set that variable true and provide a number. The code into the timer will notice the true state of that variable and get the number. Then it will set the variable back to false and use the number to go look into 2 arrays for both the correct offset to write to and the value to write.

Then it will call that "WriteToFS" and provide it with the offset and the value. The WriteToFS will do first a write, followed by a process.

Then the timer tick starts over again.

Maybe you see something wrong in this ?

[Pete Dowson]

Ok on the errors in the code file "FSUIPC Shell.vb" that is in the SDK zip:

At one part there is a ";" sign which VB.Net does not want to recognise so removing that one works fine.

Okay, I'll see to that for the next update.

Then there is a section:

...

That is missing.

Actually, that code is really redundant. It is in the C version so most folks have copied it. All it does is ensure that a Write error is logged in FSUIPC -- the data it tries to write (to a read-only location) was intended to give the library and language versions, for better diagnosis of errors from logs sent to me. But unfortunately I never enforced either the version number nor language ID system I had devised, so it is worthless.

These 2 changes make it possible for the code to be compiled.

I see the line

            VersionGet = FSUIPC_Get(t_FSUIPC_Lib_Version, FSUIPC_Lib_Version)

a little later. That is wrong -- it seems to be reading something which it should have (or could have) actually written. It is a nonsense line -- I'd remove that AND the redundant block above if I were you. I'll do that here.

However it does not link to fsuipc. ...

So this is how I know that this mod doesn't make the code connect to fsuipc.

Please use FSUIPC's IPC read/write logging to check it -- you can see then exactly what it is trying to do and maybe why it is failing.

I don't know where there is something different still but I got Scott L Fausels code working (connecting to fsuipc). However as said, still it goos funny after a minute or 5.

Values (like Nav and XPDR) are read every 100ms. When they go weird they stay to that weird value. Then when I hit a btn in my (hardware) cockpit so to send a "virtual joystick button" or else .. to trigger a "write" command that weird value changes. Maybe this gives a clue ...

Not to me, I'm afraid. I've no idea what it is doing. Please chack things from the FSUIPC end to see if you can figure it out. Use the logging.

I have a timer going round in 100ms. First it will call "ReadFromFS" and pass an address and a length to that function. Inside that function first the read is called, then the process, then the get, then it will return the value (xpdr or whatever). Same thing over and over again untill I got all my values (maybe 8 or 9 I need).

That is VERY inefficient. Do all the Reads/Writes you need, then one Process call. Each process call can pass a huge stack of read/write requests in one transaction. All the read/write calls do is build up the request in your own memory -- in other words all that is completely defined in the code you have. The ONLY connection to FSUIPC is the "SendMessageTimeout" in the Process call. Do only one of those per cycle.

I suspect most of the trouble with VB.NET is that is is "managed" code (isn't it?), so you've probably got little control over what really happens.

I've asked Bob if he can look at all this, but I don't know when he'll be able to respond.

Regards,

Pete

[PhilippeV8]

Actually, that code is really redundant.

Could be indeed, I have to say .. I do not understand ANY of the fsuipc code anyway. I just hope I can put it in there and that it works, nothing more, nothing less.

But the thing is, if you take that code out which I posted, then the thing won't compile simply because it contains the ...

Dim t_FSUIPC_Lib_Version As Integer

... to say the least.

But indeed if I take the other line where 't_FS..etc' is actually used out as well .. then the program can compile again without errors.

Concerning how I do my "inefficient" code, I found both this:

' BASIC USAGE GOES LIKE THIS: 
' - call FSUIPC_Initialization() to initialize important vars at beginning 
' of program. 
' - call FSUIPC_Open() to connect with FSUIPC if it's available. 
' - call a series of FSUIPC_Read and/or FSUIPC_Write and/or FSUIPC_WriteS (be careful when 
' combining these in the one transaction, for your own sanity). 
' - call FSUIPC_Process() to actually get/set the data from/to FS. 
' - For reads, call FSUIPC_Get to retrieve data read from FSUIPC (New for VB .Net) 
' - repeat steps 3, 4, and 5 as necessary

(Bob's comments from inside his code)

And this:

The pesky FSUIPC_Get was written to allow VB.Net to place the results of FSUIPC_Read operations into a managed data structure which is compatible with the .net memory management system. The basic approach is to pass the FSUIPC_Read a reference to a table offset token, and the function returns the offset into the local, .net-managed buffer which will contain the result after the FSUIPC_Process call. The FSUIPC_Get function retrieves the value at the specified offset from the local r/w buffer.

This was necessary because just passing FSUIPC_Read a pointer to a variable as in previous versions will not work with the .Net heap manager moving things around. The referenced variable may be moved by the heap manager in the interval between when the FSUIPC_Read and the FSUIPC_Process calls are made, leaving one with a nasty dangling pointer problem.

In any event, some of the previously posted difficulties came from trying to read the offset token as data...the first param in the FSUIPC_Get call is the integer offset token returned by FSUIPC_Read, the second param is a reference to the var where the actual result will be passed. The overloaded function defs will pass the correct size/type of data based on the type of the second param used in the call, except for passing of arrays where number of bytes to return must be explicitly coded.

Clear as mud?

Regards

_________________

Bob Scott

(Bob's comments on a previous topic on the same problem here in the forum)

http://forums.simflight.com/viewtopic.php?t=14236&start=0&postdays=0&postorder=asc&highlight=

Either way could it be that this way I work is the reason why it goos wrong ? If I do not manage to get my fault out of the code, I hope I can send my entire code to Bob and have him have a look at it and tell me what goos wrong.

[Pete Dowson]

Could be indeed, I have to say .. I do not understand ANY of the fsuipc code anyway. I just hope I can put it in there and that it works, nothing more, nothing less.

Aren't you using a language you are familiar with then? The original SDK was merely a definition of the interface (no code) and the list of offsets. I eventually did the C code with both a library and a source of the library, and even a silly little example, just so C programmers could understand it and do their own thing. I actually never expected this to be a learning ground for new programmers, so it is very hard to know how to proceed in such cases. Many apologies for this, I would help here if I could.

Concerning how I do my "inefficient" code, I found both this:

...

' - call a series of FSUIPC_Read and/or FSUIPC_Write and/or FSUIPC_WriteS (be careful when 
' combining these in the one transaction, for your own sanity). 
' - call FSUIPC_Process() to actually get/set the data from/to FS. 
' - For reads, call FSUIPC_Get to retrieve data read from FSUIPC (New for VB .Net) 
' - repeat steps 3, 4, and 5 as necessary

Yes, exactly. Only one "Process" call for any number of Reads and Writes, as I said.

In any event, some of the previously posted difficulties came from trying to read the offset token as data...the first param in the FSUIPC_Get call isClear as mud?

It is certainly as clear as mud to me. All that "Get" stuff is totally alien to me, it's that "managed code" business getting in the way! :wink:

I hope you find your answers.

Regards,

Pete

[PhilippeV8]

1) forgot to ask .. you speak of fsuipc's IPC read/write logging

what's that ? is that a function I can call in the software ? or is that something I find in the GUI in FS ? Or is that a tool I need ? I don't think I've ever heard of anything like that.

Then 'bout using a language I am familiar with .. yes I am familiar with VB.Net though I have only had 2 years of programming in school. Twice the same year that is. With half a year being Java and half a year being VB.Net.

So yes I can manage writing my own program and my own software. And NO I do not have any clue what most code of the fsuipc is doing. Also I know certain terms like arrays and hashtables and functions and librarys etc .. but then there are things you talk about like accessing memory and pfffff .. don't know. Sometimes it goos way over my head still.

So what the ideal scenario for me would be is just copy paste the "fsuipc-code"-block into my program so that the link exists between my soft and the dll. From there off, I write my software like I want. That's it.

So don't expect me to be able to do any bug fixing into that fsuipc code block :)

So as you see .. I only use VB.Net because I got only 2 languages to chose from. And I kinda hate Java and I kinda like VB.Net because it's easy coding in the Visual Studio IDE.

Then on the part where you say:

Yes, exactly. Only one "Process" call for any number of Reads and Writes, as I said.

That's not what Bob sais in his comment. He tells us to do:

(timer tick) read / process / get / read / process / get

(timer tick) read / process / get / read / process / get

(timer tick) read / process / get / read / process / get

(timer tick) read / process / get / read / process / get

or at least thats how I understand it.

Is that wrong you think ?

Should I interprete that line "repeat steps 3, 4 and 5 as necessary as this:

(timer tick) read read read process get get get

(timer tick) read read read process get get get

(timer tick) read read read process get get get

(timer tick) read read read process get get get

that would make more sence from what you (Pete) say .. however he sais "repeat steps 3, 4 and 5" where step 4 is the process item which he thus sais to repeat ....[/code]

[Pete Dowson]

1) forgot to ask .. you speak of fsuipc's IPC read/write logging

what's that ? is that a function I can call in the software ? or is that something I find in the GUI in FS ? Or is that a tool I need ? I don't think I've ever heard of anything like that.

FSUIPC always produces a Log file. There are facilities in FSUIPC for logging all sorts of things, and the controls for this are documented in the User Guide. Run FS, use ALT M F to go to FSUIPC's options (have you never been there yet?) and select the Logging page.

you talk about like accessing memory and pfffff .. don't know.

Surely any course in programming deals with memory? This is a fundamental part of any computer. Memory is where the program is stored, and its data. It's what you need 512 Megabytes of in order to run Windows XP and FS2004. Accessing memory is accessing data.

So don't expect me to be able to do any bug fixing into that fsuipc code block :)

Oh dear. I do think you are going to have to give up on your ideas for FS programming then, because whatever you are doing you will need to be able to track things though when debugging.

That's not what Bob sais in his comment. He tells us to do:

...

or at least thats how I understand it.

Is that wrong you think ?

Absolutely wrong! You are not even reading his comments properly! I'll requote the relevant part yet again:

call a series of FSUIPC_Read and/or FSUIPC_Write and/or FSUIPC_WriteS

Don't you see the words "series of"? Surely you must understand a "series of" is not just "one of"???

Should I interprete that line "repeat steps 3, 4 and 5 as necessary as this:

Step 3 is the "series of". Please refer to your own quotes!! This is going in circles! :roll:

however he sais "repeat steps 3, 4 and 5" where step 4 is the process item which he thus sais to repeat ....

Yes, and where step 3 is the "series of" reads, writes, whatever. Please PLEASE read things more carefully!

Regards,

Pete

[PhilippeV8]

Omg indeed I saw it all wrong :oops:

So in the meantime I was changing my code to give that second example I made (which now turns out to be correct indeed) a try.

(timer tick) read/read/read/read/write/process/get/get/get/get

(timer tick) read/read/read/read/write/process/get/get/get/get

(timer tick) read/read/read/read/write/process/get/get/get/get

This seams to work.

However ..

I am doing 5 reads at this time. The IAS (02BC), the altimeter in feet (3324), the xpdr (0354), the nav1 (0350) and the nav1sby (311E). Then I do 2 writes. Geat up (0BE8) and gear down straight after. Then I do the process and then the a get for every read.

I get the IAS perfect. I get the Alt perfect. I get the xpdr perfect IF I put a 4 instead of the 2 indicated in the "fsuipc for prog.doc" file. I get the nav1 sby perfect. And I get the nav1 all wrong.

Now as a test, i put the read values in labels on my form without converting them first. (e.g. XPDR = 4660, which is 1001000110100 in binary, which is 1234 if you look at the binary in the BCD way. Which is correct for the xpdr)

On the nav1 I get 135264, which is 100001000001100000 and if converted with the BCD way .. that makes 21060. If I would take the leading 2 off, than the value is perfect (nav1=110.60).

The writing only happens on the initial startup of the program and then every time I hit a button. If I do not press the button on my form there is no FSUIPC_Write action. Now when I do press the button and thus trigger the write event, the nav1sby changes!

The direct read value becomes 266288, which is 1000001000000110000 and if converted with the BCD way .. that makes 41030. Again if we drop the leading number that makes a perfet nav1sby=110.30

So at least now I know for sure that I am doing the "procedure" in a right order. Also I get my xpdr read perfect all the time. That's a good thing.

Also I assume I am doing something wrong with the write. When I disable the write part however, the nav1 still reads wrong.

FS, use ALT M F to go to FSUIPC's options (have you never been there yet?) and select the Logging page.

Sure I've been in the GUI of fsuipc :P But I somehow never looked at the "logging" page so I didn't know it was there, what it did, etc ..

[PhilippeV8]

If I use the logging, I end up with a long list of READ 3364 ..

none of my reads show, none of my writes show.

[PhilippeV8]

I've put the value which is to long a BDC trough a substring from the right (16 long). Seems to work. Isn't the most beautifull sollution but it seems to work now.

Also when I do a write, nav, navsby and xpdr all stay correct now.

If only now the com and comsby and adf read without errors, I can let you rest here :D

[Pete Dowson]

Then I do 2 writes. Geat up (0BE8) and gear down straight after.

Gear down and gear up in one process may not accomplish anything noticeable, excepting getting the gear up if it started as down, depends on the timing of those inside FS.

I get the xpdr perfect IF I put a 4 instead of the 2 indicated in the "fsuipc for prog.doc" file.

The transponder most certainly only occupies 2 bytes -- it is 4 hex digits, so 7777 = 0x7777. Something is wrong somewhere if you are reading 4 bytes for it -- the two high bytes will receive the Extended part of the ADF frequency.

I get the nav1 sby perfect. And I get the nav1 all wrong.

This is all stuff which I'm afraid you will have to debug by yourself. Use FSInterrogate to see what you should be getting. It's a superb tool, I'm always amazed no one seems to even notice it. You can write to offsets with it too. Always compare what you get with what FSInterrogate shows.

On the nav1 I get 135264, which is 100001000001100000

This absolutely proves you have it wrong. There are only 2 bytes for each frequency. 2 bytes contain only 16 bits -- a maximum decimal value of 65535 (unsigned). You cannot possibly get 135264 if you are using the correct lengths!

The writing only happens on the initial startup of the program and then every time I hit a button. If I do not press the button on my form there is no FSUIPC_Write action. Now when I do press the button and thus trigger the write event, the nav1sby changes!

That's something in your program too, then, and there is absolutely nothing in the FSUIPC interface which is in anyway dependent on any buttons.

I think it is about now that you need to learn how to use the debugger in your compiler suite -- it does have a debugger, doesn't it? The one I use, part of Microsoft .NET 2003, is superb.

Regards,

Pete

[Erups]

Philippe, Peter advice to use FSI is good, but be warned: FSI may be vicious.

Assuming that any offset occupies AT LEAST 2 bytes (which is true for the majority of values, but there are exceptions) every row of FSI is a 2 bytes offset.

Then the columns do support I64 values and other big things.

This all contrast as you may end up looking at a value in a raw, and see something change in the row above and getting confused.

It's because there is no clear division in FSI, everything is read and not categorized.

There are no 2 bytes offsets, or 8 bytes offsets.

The longest offsets (like file pointers, or coordinate values) do not exist: they are simply splitted in a number of words.

So it's up to you to keep this in mind and not be fooled by some of the FSI shows.

My 2 cents :)

[PhilippeV8]

I have checked FSI a few times in the past. Then a few days ago I had a breef look at it again. Still I have no idea what I can do with this to improve my code ...

All I see I can do is check if what I read is the same as what FSI reads.

Either way, if all what I've come up with from test results and such don't help to find what is going wrong in my case, then I'll just stick to what I have made of it nowa cure for an ill situation.

I'd rather have it 100% correct first time around and not have to send the read values trough a "debugger" function before using them but if no one has a clue what's going wrong, I'll be more than happy to keep it the way it is. It does work and that's not thanks to a good SDK or clear manuals.

I am sorry to say Pete, but I feel kinda bad 'bout your line where you disencourage me to program any further. Quiting is not a good option and if I am only half as determined to do this as the president of US is determined to do bad things, then I too will provail.

Maybe you don't realise but each time it seems to me like you want to make me feel as if I were stupid.

I guess you're very good into programming. Who knows, maybe you can do assembler. But then again, I guess that you've got long period of experiance with all sorts .. While I just got started with VB.Net. Sure I am a newbie, but that doesn't mean I should quit or find something easyer to do. I did manage to write the software to use with an easy to build hardware interface which is connected to the LPT port. Had I learned anything 'bout coding to LPT ? No I had not. Had I learned anything 'bout going this kind of "low level" in VB.Net ? No I had not. Did I know anything at all about the LPT port at all ? No I did not.

But I came up with the idea, I did my research on my own, I asked a few questions and I worked on it untill it worked. I did come across situations where I didn't know where to go to next, but I managed in the end and I learned much doing so.

This time as well I am determined to write my own interfacing software for my sim. It is the best way to keep maximum control of the situation. And I can tell you that no matter how n00b I am with coding .. it works at the moment with this "debugger" function. So I can't be that bad, can I ?

And sure I know that pc's work with memory and that software runs on it. Only when I write software, I declare a variable and I put data in it. Where it is put or how is none of my concern. The way fsuipc works with data, I still do not understand. And to be honest, I do not want to either.

All I think we should have is a clear SDK with not only the fsuipc block code but also with clear examples. If we would have that, there would be lot less "stupid" questions asked.

Do I aks for too much here ? :?:

[Pete Dowson]

I'd rather have it 100% correct first time around and not have to send the read values trough a "debugger" function before using them

You have the wrong idea. A debugger helps you get your code correct in the first place. You shouldn't have to add "debugger" functions. You compile your code in Debug mode and run it under debug control. That way you can do things like single step line by line and see exactly what is going on, where you are going wrong.

If you really thing that you are so good that you can get code 100% right first time and therefore don't need to use such facilities then I think you should go back to programming school and learn more realistic programming techniques.

I am sorry to say Pete, but I feel kinda bad 'bout your line where you disencourage me to program any further.

I just think you should learn programming before you attempt to program rather more intricate things than the simple "hello world" examples. I am not trying to tell you not to program, but your unwillingness to even try to understand the code that folks like Bob have volunteered makes it seem as if you need to retreat a little and bone up on the language you've chosen to use.

The way fsuipc works with data, I still do not understand. And to be honest, I do not want to either.

This is really your problem. You completely misunderstand what you are attempting to use. You do not see FSUIPC. There is no "working with data" in FSUIPC. It is all in the VB code which you have and which is provided by Bob. You can throw all that away and write your own if you like. None of it is fixed or essential, it is there to help, not hinder.

The ONLY part of the FSUIPC interface which is in that code is the call to the SendMessageTimeout function, which is a Windows API, and the data format to which it refers, which is primarily defined in the C headers, as they have been since FS95 about 10 years ago.

All of the rest is code to manage YOUR data, not FSUIPC's, and it was developed and supplied voluntarily by Bob and others to help. That's all.

All I think we should have is a clear SDK with not only the fsuipc block code but also with clear examples. If we would have that, there would be lot less "stupid" questions asked.

Do I aks for too much here ?

Folks have contributed what they can, and their contributions have helped very many folks over the years. You are the first to have been so ungrateful for their efforts. It would be different if the SDK was a commercial effort with rewards for contributions, but it isn't.

I think we should end this thread here and now, as it is obviously not helping you, and frankly it is now wasting too much of my time. As it is I can only attend to the computer for short periods until my eyes repair, and I should be helping others who are possibly a little more receptive.

Sorry I couldn't help you more. I did try, honest. Good luck,

Pete