Visual Basic Question

[eviljonbob]

Hi Guys,

I have a small programming problem that I was hoping someone could help me with. I am playing around with the FSUIPC SDK and VB and experimenting with the parallel port. Basically I have written a small program that is supposed to turn on LED's connected to the port when the Marker lights are activated in the sim. I have everything working (cool) apart from a small glitch. This is when I am over the Inner marker. It de-activates the light too early. It is fairly consistant when it happens, it seems to be at the same point when the light turns itself off, even though the sim light is still on. I am not really a programmer, so it is probably something stupid I am not doing right. The code fragment for the relevant routine is below. You will note that it is an expansion of the example in the SDK. The PortOut Call turns the appropriate pin on or off.

Private Sub Timer2_Timer()

Dim dwResult As Long

Dim omiInnermkr() As Byte

Dim omiMiddlemkr() As Byte

Dim omiOutermkr() As Byte

ReDim omiInnermkr(2)

ReDim omiMiddlemkr(2)

ReDim omiOutermkr(2)

' As an example of retrieving data, we will get the Marker status.

' If we wanted additional reads/writes at the same time, we could put them here

If FSUIPC_Read(&HBAC, 2, VarPtr(omiInnermkr(1)), dwResult) Then

' "Read" proceeded without any problems

If FSUIPC_Process(dwResult) Then

' "Process" proceeded without any problems

If omiInnermkr(1) Then

shpInner.FillColor = &HFFFFF

Call PortOut(888, 1)

Else

If omiInnermkr(1) = False Then

shpInner.FillColor = &H0&

' Call PortOut(888, 0)

End If

End If

Else

Label7.Caption = "Processing: " & ResultText(dwResult)

End If

Else

' Unable to "Read"

Label7.Caption = "Reading: " & ResultText(dwResult)

End If

If FSUIPC_Read(&HBAE, 2, VarPtr(omiMiddlemkr(0)), dwResult) Then

' "Read" proceeded without any problems

If FSUIPC_Process(dwResult) Then

' "Process" proceeded without any problems

If omiMiddlemkr(0) Then

shpMiddle.FillColor = &HFF00&

Call PortOut(888, 2)

Else

If omiMiddlemkr(0) = False Then

shpInner.FillColor = &H0&

Call PortOut(888, 0)

End If

End If

If omiMiddlemkr(0) Then

If omiInnermkr(1) Then

shpMiddle.FillColor = &H0&

Call PortOut(888, 1)

Else

If omiMiddlemkr(0) = False Then

shpInner.FillColor = &H0&

Call PortOut(888, 0)

End If

End If

End If

Else

' Unable to "Process"

Label7.Caption = "Processing: " & ResultText(dwResult)

End If

Else

' Unable to "Read"

Label7.Caption = "Reading: " & ResultText(dwResult)

End If

If FSUIPC_Read(&HBB0, 2, VarPtr(omiOutermkr(0)), dwResult) Then

' "Read" proceeded without any problems

If FSUIPC_Process(dwResult) Then

' "Process" proceeded without any problems

If omiOutermkr(0) Then

shpOuter.FillColor = &HFF00&

Call PortOut(888, 4)

Else

' Call PortOut(888, 0)

shpOuter.FillColor = &H0&

End If

Else

' Unable to "Process"

shpMiddle.FillColor = &H0&

End If

Else

' Unable to "Read"

Label7.Caption = "Reading: " & ResultText(dwResult)

End If

End Sub

Any help would be appreciated.

Thanks!

E :wink:

[Pete Dowson]

when I am over the Inner marker. It de-activates the light too early.

I'm afraid I can't help with Visual Basic, but I can say that you should be checking your results with FSInterrogate, to see how long the Inner Marker is actually flagged as being received.

I've found that such signals tend to be very short-lived indeed. To start with there aren't actually many runways equipped with them these days, and secondly they are usually almost on or very near the runway threshold. By then you are so low that the passage through the "cone" of radio reception is very short indeed. Maybe you have nothing wrong -- certainly if your code is working for the other Markers, it seems unlikely to be broken in this one instance.

Regards,

Pete

[eviljonbob]

Thanks for the reply Pete, I will try FSInterrogate as you suggest. This was an exercise initially to get it working, I now want to get some eyebrow lights working for my helo sim. The next experiment is to get the warning lights going. (low rpm, oil, fuel etc). Thanks for your help and your work (without which I wouldn't be doing any of this) !

[Chris Brett]

Eviljonbob,

From my initial glances at your code, it would seem you would want to be using omiInnermkr(0) passed to VarPtr in your _Read call, instead of omiInnermkr(1) (assuming Option Base is 0 which it would appear to be given your other marker reads appear to work).

Change this:

If FSUIPC_Read(&HBAC, 2, VarPtr(omiInnermkr(1)), dwResult) Then

to this:

If FSUIPC_Read(&HBAC, 2, VarPtr(omiInnermkr(0)), dwResult) Then

I've not programmed in VB for quite some time and I've not been able to check this, but I suspect this is your problem. You have been reading the FS values for inner marker into your innermkr byte elements one byte out-of-sink, so to speak, and hence your problem with the early light extinguish.

(You'll also need to change all other references to omiInnermkr(1) to (0) in the rest of your code.)

Let me know if this helps,

Regards,

Chris Brett

(FSUIPC SDK Contributor)

[eviljonbob]

Hi Chris,

Thanks for looking at it. I changed the figures and it was still the same behaviour. I looked at FSInterrogate as Pete suggested and noticed that the 32 bit and Float64 parameters change at the exact moment the light goes off on the parallel port. The sim light remains lit. I also noticed that the middle marker 8 bit "1" stays on for a little while after the inner marker goes on, I took care of this in my code by saying that if the middle marker light comes on and the inner marker goes true, then the inner marker has priority.

I am not quite sure how to handle the 32 bit and Float64 parameters within the code. It seems that these changing is the cause of my problems. If I can get the program to ignore these and only turn off when the 8bit parameter goes low then it will work.

E

[Pete Dowson]

I looked at FSInterrogate as Pete suggested and noticed that the 32 bit and Float64 parameters changeI am not quite sure how to handle the 32 bit and Float64 parameters within the code.

What 32 bit and Float64 parameters? The Marker values in the IPC interface are as documented, 16-bit (short or WORD) values at 0BAC, 0BAE and 0BB0, respectively. In fact you only need read one byte (8 bits) for each, at 0BAC, 0BAE and 0BB0, as it is that which will be non-zero for "true". It sounds as if you are misinterpreting the FSInterrogate display completely. Please check the documentation and use the appropriate columns for the different values.

You are making it MUCH more cdomplicated that it really is. Effectively only one bit will be changing, forget all that 32-bit and Floating point nonsense. It isn't applicable. If yur FSInterrogate display is showing these columns then you are not loading the FSUIPC FSI file into it to define the vlaues correctly.

Regards,

Pete

[eviljonbob]

I had another look at FSInterrogate and the parameters are quite interesting. I think I know what is going on now. I knew that there was an overlap when I was getting both the inner and middle markers showing true so I handled that by saying in my code that if the inner marker is on and the middle marker is on, the inner marker has priority.

As I fly over, I get to a certain point over the inner marker (0BAC), when the middle marker (0BAE) goes low and the 32 bit (4 Byte?) column in the 0BAA offset shows 65536. (See the second attached image). At this point, the lights on my parallel port start going wonky.

I obviously need to do some logic to handle this event. It would be great to get access to that 4 byte area to see if it was anything but 0 and the inner marker light was on, then it is on until 0BAC is false. I was sort of assuming that because FSInterrogate can read these figures, that I could as well.

If this isn't possible, then I can live with the inner marker light acting up. I hope that this will help other people in any case. It is an exercise to allow me to understand this better even if the OMI lights aren't used often.

E :?

[Pete Dowson]

I had another look at FSInterrogate and the parameters are quite interesting.

I think you'd find the FSInterrogate display MUCH more useful and informative if you loaded the FSUIPC.FSI file I provide with it, in the SDK. This has all of the values in the tables in the Programmers Guide pre-defined so that the display becomes much more meaningful. Is is VERY disheartening to see you ignoring all this work!!

I was sort of assuming that because FSInterrogate can read these figures, that I could as well.

Please go and do all that research again using the proper definition files provided, then come back if you still don't understand.

It is an exercise to allow me to understand this better even if the OMI lights aren't used often.

The OMI values are used in many cockpit situations perfectly. I have them here both on the PFC avionics and on the flightLink KR-1. There is no problem with them. PLEASE go find the FSUIPC.FSI file supplied specifically for use with FSInterrogate, load it up and look again. NEVER EVER try to interpret a 16 bit value as 32-bit or Float64. you are only confusing yourself more and more!

Pete

[Chris Brett]

Eviljonbob,

I'm not sure I quite follow what your problem is with the inner marker. I've reproduced below an adaption of the hello program supplied in the VB SDK for your interest. I used the B777 at KJFK 04R to test this, and you can see from the screenshots that the results work.

If you are using a different airport or aircraft, perhaps try it with the B777 and KJFK as I have done as a control test.

Modify the Timer event in the example with this:

Private Sub Timer1_Timer()
Dim dwResult As Long

Dim oMkr As Byte
Dim mMkr As Byte
Dim iMkr As Byte

Call FSUIPC_Read(&HBB0, 1, VarPtr(oMkr), dwResult)
Call FSUIPC_Read(&HBAE, 1, VarPtr(mMkr), dwResult)
Call FSUIPC_Read(&HBAC, 1, VarPtr(iMkr), dwResult)
Call FSUIPC_Process(dwResult)

lblClock.Caption = "OM:" & oMkr & "   MM:" & mMkr & "  IM:" & iMkr

End Sub

...and let us know how you get on. (I've taken Pete's suggestion of reading only 1 byte at the marker locations for this, but it works reading words as well).

Chris

[eviljonbob]

Hi Chris,

Thanks for your constructive assistance. I changed aircraft and tried your code with mine. It still gave both inner and middle as true at the same time, however with the addition of:

If iMkr Then
    If mMkr Then
    mMkr = False
    End If
End If

The markers behaved correctly. If it works on your system without this code, then it must be a glitch in mine. Your code is a lot simpler and works. I have learnt a lot from this exchange (some good, some bad). Thanks for your time.

E

[Chris Brett]

E,

Glad it worked.

Perhaps this is a scenery issue - I was using the default MS scenery for KJFK 04R. If you have addon scenery then there may be a rogue copy of the middle marker close to the inner marker, or perhaps 2 different scenery layers conflicting. Not sure, worth investigating perhaps.

Chris