VB.NET Arithmetic operation resulted in an overflow (088C)

[KHBO]

Hi All,

I am trying to make the throttle lever ENG 1 working using VB.NET. I wrote following code and it works, however...

------------------

(088C) -> Between -16384 and 16384

------------------

Private Sub Button4_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button4.Click

Dim Result As Integer

If FSUIPC_Open(SIM_ANY, Result) = True Then

Dim ThrottleToken As Integer

Dim ThrottleValue As Integer = TbTH1.Value

Label1.Text =TbTH1.Value

FSUIPC_Write(&H88C, 64, ThrottleToken, Result)

FSUIPC_Process(Result)

FSUIPC_Close()

End If

End Sub

When you push Button4 on the form the throttles are advanced a little bit. However when I try to replace the '64' in

FSUIPC_Write(&H88C, 64, ThrottleToken, Result) to '8000' FSUIPC_Write(&H88C, 8000, ThrottleToken, Result), I'am getting following message : Arithmetic operation resulted in an overflow

This is probabely because I use wrong variables. We want to try out the throttle by using a slider on a form. Does anyone has any idea how to avoid the overflow?

In the future We will replace the number with a voltage value.

[Pete Dowson]

Dim ThrottleValue As Integer = TbTH1.Value

Label1.Text =TbTH1.Value

FSUIPC_Write(&H88C, 64, ThrottleToken, Result)

FSUIPC_Process(Result)

FSUIPC_Close()

End If

End Sub

When you push Button4 on the form the throttles are advanced a little bit.

I don't understand VB.NET. Why have you defined a "ThrottleValue" variable and not referred to it in the FSUIPC_Write? The FSUIPC interface which I programmed has a pointer to data in memory, the only literal (numeric) value is the number of bytes being transferred. Your code doesn't seem to match anything FSUIPC might understand.

Where in your Write is the size of the value being written? How does the system know whether you want to write one byte, 2, 3, 4 or 5000?

Surely your value "64" should be in your variable "ThrottleValue"?

BTW it is extremely (EXTREMELY) inefficient to use FSUIPC_Process for one variable at a time. You should collect all the things you want to read or write and do them all in one process.

However when I try to replace the '64' in

FSUIPC_Write(&H88C, 64, ThrottleToken, Result) to '8000' FSUIPC_Write(&H88C, 8000, ThrottleToken, Result), I'am getting following message : Arithmetic operation resulted in an overflow

What arithmetic operation is going on? Maybe whatever your "FSUIPC_Write" routine does, it only handles one byte, in which case, obviously, 8000 won't fit. As I said above, you have no length. How does it know?

This is probabely because I use wrong variables.

But you are not using variables. "64" and "8000" are NOT variables! You have declared a variable, but you are not even using it!

Please have a look in your VB.NET system and see if there is a Debugger you can use to trace through. It should tell you immediately where your overflow is. Debuggers are very useful when developing programs.

Also, take a look at FSUIPC options. Check the "Logging" tab. If you enable IPC read and write logging you will be able to see EXACTLY what you are achieving over the FSUIPC interface. IUt will show the data actually being sent. You may be surprised.

Regards,

Pete

[KHBO]

How can we pass this size in a vb.net FSUIPC_Write statement?

There are only 2 possibilities in the SDK:

- FSUIPC_Write (ByVal dwOffset as Integer, ByVal Param As Integer, ByRef Token As Integer, ByRef dwResult as Integer) As Boolean

- FSUIPC_Write (ByVal dwOffset as Integer, ByVal dwSize As Integer, ByVal Param As Byte(), ByRef Token As Integer, ByRef dwResult as Integer) As Boolean

I'am currently using the first possibility, without the size tag. However when I use the second one, what do I have to fill in 'ByVal Param As Byte()' ? Example?

[Pete Dowson]

How can we pass this size in a vb.net FSUIPC_Write statement?

There are only 2 possibilities in the SDK:

- FSUIPC_Write (ByVal dwOffset as Integer, ByVal Param As Integer, ByRef Token As Integer, ByRef dwResult as Integer) As Boolean

- FSUIPC_Write (ByVal dwOffset as Integer, ByVal dwSize As Integer, ByVal Param As Byte(), ByRef Token As Integer, ByRef dwResult as Integer) As Boolean

I'am currently using the first possibility, without the size tag. However when I use the second one, what do I have to fill in 'ByVal Param As Byte()' ? Example?

I have no idea about how you'd use either of them, including the second one, but in FSUIPC all data is simply an array of bytes, exactly that.

I don't know VB.NET, but I assume you can use the first one for INTEGERS (it does say "Param As Integer"), which are 32-bit (4 byte) -- but this offset is a "short" (16-bit integer). Aren't there any other choices? I should think it would be a bit like C++ with 'overloaded' procedures, the compiler choosing the correct one by the type of parameters.

However, if you use a constant like 64 or 8000 how can it tell what type?

Did you check the logging? Did you try debugging?

I'm sure there must be some references for VB.NET that explain how to use the language?

Regards,

Pete

[KHBO]

Hi again,

I checked the logs, it seems that it wrote only 1 byte (8 bits) (so that explains why 64 works as I can have any number between 0 and 255). The variable is an integer or S16 (16 bits) so i'am missing one byte.

Here is a brief overview of all VB.NET variables: http://en.wikibooks.org/wiki/Visual_Basic_.NET/Variables#Short

The problem is that it's not clear to me how to specify the size in the FSUIPC_Write sentence.

Possibility N°1

----------------

Using Short --> Short: 16 bits (2 bytes), stores integer values from -32,768 to 32,767. It seems perfectly suited.

Code:

Private Sub Button4_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button4.Click

Dim dwOffset As Integer

Dim Param As Short

Dim ThrottleToken As Integer

Dim Result As Integer

If FSUIPC_Open(SIM_ANY, Result) = True Then

dwOffset = &H88C

Param = 245

FSUIPC_Write(dwOffset, Param, ThrottleToken, Result)

FSUIPC_Process(Result)

FSUIPC_Close()

End If

End Sub

It works perfectly, however it has an overflow for Param values > 255. The log files show a change from 0x0 to 0xF5 for the offset 088C.

15664344 Monitor IPC:088C (S16) = 0x0

15667759 Monitor IPC:088C (S16) = 0xF5

Log:

16909715 WRITE0 [P3728] (failed, read-only!) 330A, 4 bytes: 02 00 00 00

16909815 WRITE0 [P3728] (failed, read-only!) 330A, 4 bytes: 02 00 00 00

16909916 WRITE0 [P3728] 088C, 2 bytes: F5 00

16915053 WRITE0 [P3728] (failed, read-only!) 330A, 4 bytes: 02 00 00 00

16915153 WRITE0 [P3728] 088C, 2 bytes: F5 00

I don't kow what the 330A offset does here, i never called it. The 08C offset now works with 2 bytes, however, it still had an overflow for values greater than 255. For example 256 in hex this would mean 100 (255= FF).

The VB.NET debugging gives nothing.

[Pete Dowson]

It works perfectly, however it has an overflow for Param values > 255. The log files show a change from 0x0 to 0xF5 for the offset 088C.

I really have no idea how you get an overflow. You need to debug your code to see where it is occurring. It is nothing whatsoever to do with FSUIPC.

Your code shows a Subroutine in which, everytime it is called, Opens a link to FSUIPC (this involves seriously heavy calls to Windows to create a memory mapped file and set a unique Atom for it), writes just one value, with one Process call, then closes the link, which closes the memory maped file.

I really do hope this is not indicative of how you are programming, as yours will be the most inefficient program ever to interface to FSUIPC! :-(

I don't kow what the 330A offset does here, i never called it.

If the VB.NET code you are using (presumably from the examples in the SDK) follows the C source examples I provide, then the only purpose of writing to 330A (a read-only location) is to make sure I get an entry in the log showing the Version number of my original C source code in the SDK.

The reason you get several is because you are repeatedly re-opening the link to FSUIPC. See above.

The VB.NET debugging gives nothing.

The VB.NET debugger doesn't even show you the line which gives the overflow error? Are you sure? It must be the worst debugger in the world then, or you are seriously misusing it! If it won't point to the line, try single stepping through. Surely it supports single stepping?

You have all the source code, and the error is occurring in your program.

Sorry, I have to give up helping at this point. It really sounds like you have chosen the wrong language altogether if it is so bad as you make out. :-(

Regards,

Pete

[airforce2]

You might try changing var names...you are using same vars as defined in the functions (i.e. "Param"). The scopes look OK at first inspection, but could be a var is being mis-cast...in particular, Param cast as type Byte could have this effect.

Also, given that these are defined as functions, calling them as subroutines looks strange to me...

Agree with Pete that you'll need to engage in some more involved debugging to see more precisely where this overflow is occurring.

Regards