Jump to content
The simFlight Network Forums

Flaps Not Retracting VB.Net


pbayley

Recommended Posts

I've got a problem that someone might be able to help me resolve.

I'm trying to get the flaps to retract after takeoff and the code works .......... sort of.

 

 

 Dim flaps As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&HBDC) 'Flaps Control

                   

If flaps.Value > 0 Then flaps.Value = 0

 

I have a test flight set up for repetition testing.

Starting FSX and running the test flight for the first time, I set the flaps manually for T/O, and after takeoff the flaps retract as required by the program.

However on subsequent flights I set the flaps manually and after takeoff, whilst the flaps.value is set to 0, the flaps fail to retract on the aircraft.

 

I setup a test button to set the flaps programatically and after setting the flaps in this way they are retracted each and every flight as required.

 

Any thoughts?

Link to comment
Share on other sites

The FSUIPC docs suggests that the reading of values from offset 0BDC is not always accurate.

 

I suggest only using this offset for writing (declare it as Write-Only and in it's own group so you can control exactly when it gets sent):

Dim flaps As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)("FlapsControl", &HBDC, True) 'Flaps Control

Then use another offset to determine the position of the flaps. Maybe 0BE0 or 0BFC (see docs).

 

e.g.

Dim flapsPos As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&H0BE0) 
FSUIPCConnection.Process()
If flapsPos.Value > 0 Then 
   flaps.Value = 0
   FSUIPCConnection.Process("FlapsControl")
End If

If you still have problems I'll probably need to see a bit more of your code; especially where your Process() calls are.

 

Paul

Link to comment
Share on other sites

Thanks for that Paul.

I tried your suggestions and the results were the same. 

 

There seems to be an anomaly with the operation of the flaps which seems to be at the root of the issue.

 

As I described in my post above, after setting the flaps manually the code (whichever version) operates as required if it is the first flight after starting FSX.  Any subsequent flights and the flaps don't retract if they have been set manually.

 

As a test, I set up two buttons to set and retract the flaps with the code:

 

 

    Private Sub btnFlapsUp_Click(sender As System.Object, e As System.EventArgs) Handles btnFlapsUp.Click
        flaps.Value = 0
        FSUIPCConnection.Process("FlapsControl")
    End Sub

    Private Sub btnFlapsDown_Click(sender As System.Object, e As System.EventArgs) Handles btnFlapsDown.Click
        flaps.Value = 8192
        FSUIPCConnection.Process("FlapsControl")
    End Sub

 

The results of testing with the buttons:

 

After starting FSX:

  • I set the flaps manually and click on the flaps up button and the flaps retract.
  • I set the flaps manually again, click on the flaps up button and the flaps don't retract.
  • With the flaps still set down, I click on the flaps down button, then clicking on the flaps up button the flaps retract.

This behaviour is mirrored when the program runs, for the first flight OK but subsequent flights only work if the flaps are set with the button before takeoff and not manually.

For what it's worth the landing gear operation works every time.

 

 

            If GearUp = False Then
                If Alt - RwyAlt > 75 Then
                    My.Computer.Audio.Play("C:\Users\Paul\Desktop\FSUIPC_Wav\GearUp.wav")
                    gear.Value = 0
                    GearUp = True
                End If
            End If
            If FlapsUp = False Then
                If Alt - RwyAlt > 450 Then
                    My.Computer.Audio.Play("C:\Users\Paul\Desktop\FSUIPC_Wav\FlapsUp.wav")
                    flaps.Value = 0
                    FSUIPCConnection.Process("FlapsControl")
                    FlapsUp = True
                End If

 

At the moment I'm experimenting with the above code using a modified version of your FSUIPCClientExample_VB and the above code is in the Sub Timer1_Tick.

 

Cheers

Paul

Link to comment
Share on other sites

Hi,

 

that will be because the offset is set to write only, so internal it will not be updated and the dll doesn't write the value from last writing again if it didn't change.

Use the offset as read/ write, that should solve your problem, as long it did read the new position before the next write process.

Link to comment
Share on other sites

Thomas: The dll doesn't check for changed values if the offset is write-only, it writes on every process. The problem does look like the DLL isn't writing when the value is the same, but it seems FSUIPC is doing this filtering.

 

Paul: I've done some testing here and I get the same results as you. I've used the logging in FSUIPC to check the 0 is getting written by the DLL and it is. It seems that FSUIPC is ignoring values here where they are the same as the last value written. I don't know if that's be design or an oversight. I'll clarify with Pete in the main support forum.

 

Currently you can work around this by sending two writes with close values so that FSUIPC sees changing values:

  Private Sub btnFlapsUp_Click(sender As System.Object, e As System.EventArgs) Handles btnFlapsUp.Click
        flaps.Value = 1
        FSUIPCConnection.Process("FlapsControl")
        flaps.Value = 0
        FSUIPCConnection.Process("FlapsControl")
    End Sub

    Private Sub btnFlapsDown_Click(sender As System.Object, e As System.EventArgs) Handles btnFlapsDown.Click
        flaps.Value = 8191
        FSUIPCConnection.Process("FlapsControl")
        flaps.Value = 8192
        FSUIPCConnection.Process("FlapsControl")
    End Sub

Paul

Link to comment
Share on other sites

The problem does look like the DLL isn't writing when the value is the same, but it seems FSUIPC is doing this filtering.

 

Yes, I've explained what is going on in my reply to you in the main forum. Your solution is the same one I proposed, but I can probably also improve FSUIPC in this area as I also said. Not sure yet though.

 

Pete

Link to comment
Share on other sites

Thanks Pete,

 

I've just tried this using the Flaps Handle offset at 0x0BFC instead and that doesn't have this problem.

 

Maybe it's better to use that offset rather than disturbing your code for 0xODBC.

 

I suggest that Paul (OP) swtiches to 0x0BFC. As far as I can tell he's just looking to raise the flaps so this would be sufficient.

Dim flaps As Offset(Of Byte) = New FSUIPC.Offset(Of Byte)("FlapsControl", &H0BFC, True) 'Flaps Control
    Private Sub btnFlapsUp_Click(sender As Object, e As EventArgs) Handles btnFlapsUp.Click
        flaps.Value = 0
        FSUIPCConnection.Process("FlapsControl")
    End Sub

    Private Sub btnFlapsDown_Click(sender As Object, e As EventArgs) Handles btnFlapsDown.Click
        flaps.Value = 1
        FSUIPCConnection.Process("FlapsControl")
    End Sub

Paul

Link to comment
Share on other sites

I've just tried this using the Flaps Handle offset at 0x0BFC instead and that doesn't have this problem.

 

Yes, that's new in FSX. It's the SimConnect "FLAPS HANDLE INDEX" variable which unusually is both read and write enabled.  (Most are read only, writes being rejected). FSUIPC just sends it directly when you change it.

 

Pete

Link to comment
Share on other sites

Thank you all for responding to my post, it's really much appreciated.

 

Thank you Paul for coming up with the solution and confirmed by Peter.

It's working just as required and now I can move on to the next problem :-)

 

Cheers

Paul

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.