How to connect to FSUIPC automatically

[Hans Zeng]

Hi,

   I am developing a new ACARS with detailed QAR, but there is a problem which puzzled me a lot.

   I use some timers to execute the QAR in VB, but when I run the ACARS, I have to click a button to connect to FSUIPC, and before submit the flight, I have to click to disconnect, too. It's unconvenient. Even worse, when FS crashed with some error, like "A FATAL ERROR OCCURRED....", my ACARS will be in a "not responding" status. I have to use taskmgr to close it.

   So, I wonder if there is a way to disconnect/connect to FSUIPC automaticaly.

   Sorry for my poor English.

 

Hans

[Pete Dowson]

I moved your Support question to the Support Forum so it can be answered. You posted in the "FAQ" subforum, which is a repository for information, not support.

 

I use some timers to execute the QAR in VB, but when I run the ACARS, I have to click a button to connect to FSUIPC, and before submit the flight, I have to click to disconnect, too. It's unconvenient.

 

I don't know what "QAR" is, but why program it to wait for a button click if that is not what you want? Surely, as the programmer, it is up to you how you do things?

 

Even worse, when FS crashed with some error, like "A FATAL ERROR OCCURRED....", my ACARS will be in a "not responding" status. I have to use taskmgr to close it.

 

It sounds like you are either not using the standard code supplied by the FSUIPC SDK, which includes a timeout on requests, or you are ignoring the error reports when the requests do time out.

 

So, I wonder if there is a way to disconnect/connect to FSUIPC automaticaly.

 

Well, all the programs I know of do so easily enough. Connection and Read and Write requests all include timeouts, and return errors upon no response. Simply take notice of the errors, wait a little while, ad try again. On a read/write error if the connection is not okay within a few seconds of retries, assume the connection is lost, close it and try reconnecting -- again with timeouts, short waits and retries. It is all simple error detection and correction.

 

Regards

Pete

[Hans Zeng]

Ok, I will refer to the standard code later.

I have tested out some issues last night.

    'GND-SKY
    Dim strGND As Integer
    
    dwOffset = (&H366)
    dwSize = 2
    
    If FSUIPC_Read(dwOffset, dwSize, VarPtr(strGND), dwResult) Then
       If FSUIPC_Process(dwResult) Then
         GND = strGND
       End If
    End If
    
    'VS on Touchdown
    Dim strLDGVS As Long
    
    dwOffset = (&H30C)
    dwSize = 4
    
    If FSUIPC_Read(dwOffset, dwSize, VarPtr(strLDGVS), dwResult) Then
       If FSUIPC_Process(dwResult) Then
         LDGVS = strLDGVS * 60# * 3.28084 / 256#
       End If
    End If

    'G-Force on Touchdown
    Dim strLDGGF As Double
    
    dwOffset = (&H11B8)
    dwSize = 2
    
    If FSUIPC_Read(dwOffset, dwSize, VarPtr(strLDGGF), dwResult) Then
       If FSUIPC_Process(dwResult) Then
         LDGGF = strLDGGF / 625
         LDGGF = Format(LDGGF, "0.00")
       End If
    End If

'Timer1 is enabled by other code, and interval is 100ms
Private Sub Timer1_Timer()
    If LDGVS <> "0" And GND = 1 Then                'When touchdown
      Debug.Print "VS:" & LDGVS & " GForce:" & LDGGF
    End If
End Sub

Here is a part of my code, the VS is always accurate but not G-Force, in fact, G-Force sometimes will be 0. Edited August 6, 2013 by Hans Zeng

[Pete Dowson]

Here is a part of my code, the VS is always accurate but not G-Force, in fact, G-Force sometimes will be 0.

 

First off, a general comment on your code. It is extremely inefficient. The whole point of separating the build up of read/write requests from their processing was to reduce as much as possible the process switching and message queing. You should do ALL the reads and writes you want to do in a batch, then call the Process function, one Process call per cycle.

 

On the question about G-Fprce, why are you reading the offset 11B8? The documented offset for G-Force is 11BA. You should check these things.

 

Regards

Pete

[Hans Zeng]

First off, a general comment on your code. It is extremely inefficient. The whole point of separating the build up of read/write requests from their processing was to reduce as much as possible the process switching and message queing. You should do ALL the reads and writes you want to do in a batch, then call the Process function, one Process call per cycle.

It is my first time to develop a VB program, I am just a php coder before, and I will take your advice. :razz:

 

On the question about G-Fprce, why are you reading the offset 11B8? The documented offset for G-Force is 11BA. You should check these things.

The FSUIPC4 Offsets Status.pdf told me that "11B8 G-Force: copy of 11BA on touchdown."

So I use it....

Hans

[Pete Dowson]

It is my first time to develop a VB program, I am just a php coder before, and I will take your advice. :razz:

 

The FSUIPC4 Offsets Status.pdf told me that "11B8 G-Force: copy of 11BA on touchdown."

So I use it....

Hans

 

Ah, sorry, you did not mention it was the 'on touchdown' G-Force.  So you ARE using FSUIPC4? What version? You should always say. Only one now supported is 4.91.

 

All that happens is that  when FSUIPC detects "on ground" it copies 11BA to 11B8. 11B8 is set directly from a SimConnect value computed by FSX. If you bounce it could well be zero for a fraction , at the top of the bounce! ;-)

 

I don't know VB much, but this seems odd:

 

Dim strLDGGF As Double

 

You read the offset value into a "double" (which is presumably a 64-bit floating point value), whilst the offset is a 2-byte (16 bit) integer!

 

I don't see a definition for LDGGF, but surely that should be the "double", and strLDGGF should be an integer initialised to zero (because you only read 2 bytes and an integer is 4 bytes.

 

You are only just learning VB? I don't think an FSUIPC application is the best way to learn. You need some easier projects first I think

 

Regards

Pete

[Hans Zeng]

Yeah, I should check it because I want to support FS9.

I think I will have much work to do tomorrow, and thanks for your patient answer.