The values from FSUIPC differs

[frazer84]

Hi!

I have a problem when programming my application to interact with FSUIPC.

It works fine on my computer, but when I tried it on anther computer It didn't. After some debugging I found out that the values given by FSUIPC on the other computer isn't the same as the values my FSUIPC is sending out.

For example is the ground-flag (Offset 0366) and Engine 1 fireing (Offset 0894).

My computer gives the correct values (1 and 1 if the ac is on the ground with engine number 1 running). On the other computer I get the values 262145 instead in the same situation.

Any ideas why? It's quite hard to develop applications when they only work on one computer :?

Regards,

Daniel

[Pete Dowson]

It works fine on my computer, but when I tried it on anther computer It didn't. After some debugging I found out that the values given by FSUIPC on the other computer isn't the same as the values my FSUIPC is sending out.

You mean via WideFS, or are you talking about two completely separate installations of some Microsoft Flight simulator (FS98, 2000, 2002 or 2004)?

My computer gives the correct values (1 and 1 if the ac is on the ground with engine number 1 running). On the other computer I get the values 262145 instead in the same situation.

Aha! 262145 is hex 00040001. It is too large a value for the 16 bit values you are reading -- the maximum 16 bit value is 65535.

It sounds like you are reading 2 bytes into a 4 byte variable which you have not previously initialised to zero. The higher 16 bits will be unpredictable. This is an elementary programming error which you should easily find by the part of the programming process known as debugging.

In any case, please use the tools provided to check things. FSUIPC has extensive logging and real-time Monitoring facilities (see the Logging page in the Options), and there's a program called FSInterrogate supplied in the SDK. These things are there to help you. ALWAYS but always check things against something separate, such as these, first. That's why I provide them.

It's quite hard to develop applications when they only work on one computer :?

If you are not initialising values which you are only partially loading into you must expect them to vary considerably, as they will pick up any rubbish left in memory on that PC. That could happen on any PC, it just depends on what happened before.

As I said, please use the tools you have to find out what you have done wrong. Even think of using the debugger which presumably comes with your compiler.

If you really still need my help, I need more information, like logging results, actual version numbers, and even simple things like whether you are talking about a WideFS configuration, a version of FS or CFS, and actual version numbers of my own modules.

Regards,

Pete

[frazer84]

Now I have tried most things, with some success. The values gets allright most of the time, but sometimes, for example when FS has been paused for a longer time, the values gets very large like the ones i described in the first post. If i restart my application, the values get all right again.

A little more information about my system:

I'm using FSUIPC version 3.4.8.0 on MSFS 2004 without the 1.1 patch.

The application is developed in C# using Microsoft Visual Studio.net 2003.

This is how i declare the variables used in the FSUIPC-calls:

int dwOffset = 0;

int dwSize = 0;

int Token = 0;

int dwResult = 0;

int Result = 0;

This is done before every call to FSUIPC is done.

Thank you for your help!

[Pete Dowson]

The values gets allright most of the time, but sometimes, for example when FS has been paused for a longer time, the values gets very large like the ones i described in the first post. If i restart my application, the values get all right again.

You have errors in the program still then. You need to debug your program further. Pausing makes no difference whatsoever to FSUIPC nor the interface.

Please always check all your results with FSInterrogate (that is why it is provided). Also you can use FSUIPC IPC read/write logging to see exactly what you are reading and writing, and even the Monitoring to have values displayed for you on the FS screen. There is really no need to ever have anything wrong! You can fix it all.

Regards,

Pete

[frazer84]

I have checked with FSInterrogate, which shows the correct values (as well as the logs), so I'm sure that it is a programming-fault, but I don't know what. I have done as you said earlier, to set the integers to 0 before every read, which made it work better, but not every time. I have debugged this application for weeks, as well as rewritten it from scratch.

I don't know how familiar you are with C#-programming, but is the declarations I wrote in the previous post the way you told me to do in your first answer in the thread? I'm not a programming-genious, but I'm learning...

[Pete Dowson]

I have done as you said earlier, to set the integers to 0 before every read, which made it work better, but not every time. I have debugged this application for weeks, as well as rewritten it from scratch.

It isn't just a matter of setting integers to zero, it is a matter of setting unused parts of areas you read into to something predictable, zero being a good choice. I don't remember the earlier details (there have been far too many other messages), but it was likely that you were reading a 2 byte value into a 4 byte location and hadn't set the two unused bytes, so you got rubbish.

But the same can apply to anything of unequal lengths. You have to do it intelligently! In your code snippet above you say:

int dwOffset = 0;

int dwSize = 0;

int Token = 0;

int dwResult = 0;

int Result = 0;

but (a) I have no idea what you are using some of those for, and (b) there's no point in initialising things to zero if they are all going to be set in any case. For example, the Offset is always a 32-bit value so you will be setting that, and the "dwResult" value is always set as a 32 bit value too.

You seem to have misunderstood your original errors and compensated by incorrect changes. Just think about what is going on. If you understood a little more about what you are doing you wouldn't make so many errors.

If you read 1 byte into a 32-bit value, only the bottom 8 bits of those 32 will be set. The other 24 bits will retain whatever value they had before.

The same goes for any other sizes. Just think, each time, about what you are doing. When programming you must attend to this level of detail!

After all that, you should find a thing called a "Debugger" somewhere in your development system. If you compile your code in Debug mode you should be able to trace through it, step by step, examining all these values as you go. You can even set breakpoints which makes it stop at selected points so you can examine things.

All this is part of programming and an essential step to getting any new program fully working. Please try it.

Regards,

Pete

[frazer84]

After converting the 32-bits integer to a byte-array, I could access the 4 bytes and pick the first two, if that was the length I had requested from FSUIPC. This works fine and I get the correct results every time, with one exception: The vertical speed.

In FSinterrogate, I can get negative values, but not when I try to access the same values. I get a small value in the first byte, and a large one in the 2nd byte. Adding these makes a value about 40000-50000 in a descend. The rest two bytes are empty (0). Any idea why I can't get negative values from FSUIPC, when FSinterrogate can?

[Pete Dowson]

Adding these makes a value about 40000-50000 in a descend. The rest two bytes are empty (0). Any idea why I can't get negative values from FSUIPC, when FSinterrogate can?

In a 16 bit value there is no such thing as a value as big as 40000-50000. you are interpreting these incorrectly. They are negative. The range of signed values possible in 16 bits is -32768 to +32767. You are treating a signed 16-bit number as if it were unsigned (its range is then 0 to 65535).

It is all in the interpretation. I think you fundamentally misunderstand numbers in computers. This is really something you need to learn something about if you are to be a programmer.

For now just subtract 65536 if the number is greater than 32767. But please go and do some reading.

Regards,

Pete