C# problems

[story]

Hi!

I'm currently rewriting an old application in C#.Net and I'm having some difficulties with FSUIPC (using Scott McCrorys 1.1 library).

Sometimes I get odd responses from FSUIPC when trying to retrieve heading or altitude (heading 360 or altitude 0).

These almost always happens when I do a lot of reads after one another.

It gets quite annoying when cruising at 39000 ft and suddenly FSUIPC says I'm at the ground...

I would like to hear if anyone else have had these problems or have a solution to them?

Regards

Rickard Nord

[airforce2]

If you are using the C# API from a version of the FSUIPC SDK prior to version 19, there was a bug in the buffer wraparound that would cause reads to fail and return 0 or other low values when the data buffer wraparound occurred.

That has been corrected in the latest version.

Regards

[story]

I was using 1.0 version of the library earlier and you might be right that this is the problem. I'll check it out. It might have went away...

I discovered a bug in the latest version (1.1) of FSUIPC_Write (the overload that takes a byte array as parameter). I don't think it could ever have worked...

Your code:

int idx;
for ( idx = (Token + 4) ; i < (Token + dwSize + 3); i++) 
{
	IPC[idx] = param[idx];       //xfer byte array to IPC managed FifO buffer
}

I've fixed it so it works:

int idx;
int startidx = Token + 4;
for ( idx = (Token + 4) ; idx < (Token + dwSize + 3); idx++) 
{
	IPC[idx] = param[idx - startidx];       //xfer byte array to IPC managed FifO buffer
}

[ali]

Hello everyone,

I have similar problem but in VB.Net. My code reads some values from FS every second, in the first 8-10 minutes everything is normal, but then most values go crazy (for example, reading 10 digit number for ground speed). I really wonder that can there be bug in VB.Net as in C#. If so, how to fix it? I made changes according to Story's last post but result is the same :(

There is one more topic about that problem in VB.Net but either there is no exact result out there.

Any ideas? I will highly appriciate any kind of help. Thanks in advance.

Ali YIlmaz.

[airforce2]

Rickard--You're correct...looks like an error in the translation from VB .net to C#. I'll send Pete a corrected version for the next SDK update.

Ali--the buffer wraparound bug was present in only the very first release of the VB .net API. Make sure you're using the one from the current FSUIPC SDK (v19).

Cheers

[airforce2]

Ali;

To check for the buffer wraparound bug, look in procedure FSUIPC_Process at the first case in the while loop.

("Case FS6IPC_READSTATEDATA_ID")

Within that case statement there's an If...should be

If(Hdr(2) <> 0) Then

If it's more complex (can't remember what it used to be), then you have the bugged version. You might try to cut-and-paste the corrected procedure code from the new SDK.

Regards

[ali]

Hello Bob,

I have checked that i am using the SDK 19 th release. And wraparound code correction exists on that code.

Making too much read every second lead that? (Although I don't think that is too much, around 20 reads?!) May be I am doing something wrong. I am gonna recheck my code, by the way any suggestions will be accepted :?:

Look forward to hearing from you, thanks.

Ali.

[chazzie]

I've had similar experiences in VB6, which I traced back to either wrong declarations (ie. Integer instead of Long) or erroneous processing of the returned value.

Might not be your problem, but every thought could be the key, no :D

[rickalty]

Making too much read every second lead that? (Although I don't think that is too much, around 20 reads?!) May be I am doing something wrong. I am gonna recheck my code, by the way any suggestions will be accepted :?:

20 is a small number of reads. I don't remember the actual possible read buffer max off the top of my head, but it's fairly big. I have over 40 reads per process in my FSPanel, and that's on a timer that fires every 50ms.

Richard

[ali]

I've had similar experiences in VB6, which I traced back to either wrong declarations (ie. Integer instead of Long) or erroneous processing of the returned value.

Hi,

seems like I'm gonna use the same way, although backtracing is a little bit harder in timer-used system. By the way, first I read an integer type value and then some long (4 or 8 bytes) values, when values go crazy, that first integer type value stills remain. May be that can be a clue.

Another thing is, while program is running, I look at the task manager and see that, every second size of program increases 8 KB. is that normal?

May be asking silly questions, sorry for that. and thanx for bearing me,

Ali.

[rickalty]

I know nothing about writing in C, but that ever increasing program size is a giveaway - somehow, variables are using up more and more space instead of being overwritten each time around - a "memory leak". I don't know enough C to know how to track that down, but that's the problem.

Richard

[ali]

Hello,

I want to say one interesting thing that might be helpful to understand what the problem is. While testing today I realized that if I do test in constant environment (I mean no wind, no speed or heading change, just go direct without changing anything) code works fine. I started test, for about 30 minutes everything was perfectly normal. But when I changed my speed, all values, again :evil: , gone crazy. As an example I get the values like that:

IAS : 134218052 knots | TAS : 134218219 knots | 17179899784 feet

Since I thought that may be my code had problem, I made this test with the code which I'd taken from one of my friends.

That's really quite interesting and annoying situation. any ideas??

Thanx in advance.

Ali.