Jump to content
The simFlight Network Forums

Recommended Posts

Posted
There has got to be an easier way.... to set the AUTOPILOT_ALT with an encoder

I've no idea what you are trying to do there. What on Earth is that great long list of value conditions for?

Just set the ALT by writing the value to 07D4. Convert feet to the units required by (value * 65536.0)/3.28084.

Do your calculations in floating point first to avoid losing fractions then convert to a normal 32-bit integer (fixed point) before writing to 07D4.

If you want to keep to multiples of 100 feet you'd need to increment your original feet value in 100's, or, if you are deriving the value from something else, convert it to the nearest multiple of 100 by something like 100 * ((value + 50) / 100) using fixed point values.

Regards,

Pete

Posted

I've no idea what you are trying to do there. What on Earth is that great long list of value conditions for?

Just set the ALT by writing the value to 07D4. Convert feet to the units required by (value * 65536.0)/3.28084.

Do your calculations in floating point first to avoid losing fractions then convert to a normal 32-bit integer (fixed point) before writing to 07D4.

If you want to keep to multiples of 100 feet you'd need to increment your original feet value in 100's, or, if you are deriving the value from something else, convert it to the nearest multiple of 100 by something like 100 * ((value + 50) / 100) using fixed point values.

Regards,

Pete

I used the long list of values to decrement the alt (computed the points on the way up) I got the multiplier from FSUPIC inter.... (My spelling is terible). I tried to keep the alt in the sets of 100 just like the knobs in FS do. When I would go up or down I would run into points where the numbers would go up by 101 or 99. (Didnt think to move that dec point. Thanks sorry bout the length of that post. What I would really like is a way to turn the ENCODER and have FS do the inc up or down.

Thanks

Robg

Posted

When I would go up or down I would run into points where the numbers would go up by 101 or 99.

That's rounding. The problem is that internally FS works in metres even for the altitude. You should be able to get the metres value accurate enough, though. The A/P Alt value measures down to 1/65536th of a metre, after all.

What I would really like is a way to turn the ENCODER and have FS do the inc up or down.

I don't know what the encoder is doing, but if it produces button presses why not simply program them to do that?

If you want to send FS controls from your VB program, check offset 3110. I even included the list of FS2004 controls in the latest FSUIPC package, and you can also use the FSUIPC-added controls listed in the Advanced User's document (all except the offset ones, for which of course there's no need in any case).

Regards,

Pete

Posted

That's rounding. The problem is that internally FS works in metres even for the altitude. You should be able to get the metres value accurate enough, though. The A/P Alt value measures down to 1/65536th of a metre, after all.

I don't know what the encoder is doing, but if it produces button presses why not simply program them to do that?

If you want to send FS controls from your VB program, check offset 3110. I even included the list of FS2004 controls in the latest FSUIPC package, and you can also use the FSUIPC-added controls listed in the Advanced User's document (all except the offset ones, for which of course there's no need in any case).

Regards,

Pete

The vb program just reads the ENCODER and updates the register. I tried to follow your info in the ADVANCED section, and failed to my own dismay. So I hard coded some of the info your functions handed me. Checking offset 3110? Never tried. However your math answer will probally clean up my code. I will be repairing the code later this evening. I noticed that you list several registers that you use in your docs about AP_ALT_INC, I just could not figure out how to access those registers thru the sample vbcode you supply. (Which btw helped me more than you will ever know thanks!)

Robg

Posted

Checking offset 3110? Never tried.

By "check offset 3110" I meant read it upthrough that offset you can easily send your AP ALT INC and AP ALT DEC controls from your program. The offset is designed to allow any FS controls to be used through the FSUIPC interface. Since version 3.40 you can also send FS-added controls which include the accelerated ALT Inc/Decs (in 1000's).

I noticed that you list several registers that you use in your docs about AP_ALT_INC

Registers? I list nothing about "registers"? Where are you looking? Are you confusing FS control numbers with offsets and calling them registers? Please clarify.

I just could not figure out how to access those registers thru the sample vbcode you supply.

I don't think any code in any language provides any access to machine registers, if that's what you mean. The VB code isn't mine, of course, I don't know VB.

Regards,

Pete

Posted

I don't think any code in any language provides any access to machine registers, if that's what you mean. The VB code isn't mine, of course, I don't know VB.

Regards,

Pete

I am talking about your FSUIPC for Advanced Users. Page 24, you list from 1001 to 2999. I call them registers an I was mistaken. I ment offset. the sample code I got from your SDK. I noticed you did not write the VB code however it is baised on your

' Copyright © 2000 Chris Brett. All rights reserved.

' e-mail: chris@formulate.clara.net

'

' FUNCTION LIBRARY FOR FSUIPC

' based on C code supplied by Pete Dowson

Posted

I am talking about your FSUIPC for Advanced Users. Page 24, you list from 1001 to 2999. I call them registers an I was mistaken. I ment offset.

But they are neither registers nor offsets!! Where do you get that idea from? They are control numbers, extensions to the FS controls. Surely the heading for that section makes it perfectly clear:

Additional “FS” Controls added by FSUIPC

All the true FS controls are represented by numbers above 65536. They are listed in my FS-version specific documents called “FSxxxx Controls …”. FSUIPC has augmented these with its own set, programmable for both Button and Keys, and these utilise lower numbers, currently in the 1000–3000 range.

You really need to read these thing a little more carefully, especially when programming. When you program computers every little detail has to be correct. Just scanning a document too fast and automatically assuming a list of numbers equates to a list of offsets is rather a serious error.

FS controls existed since FS5 days, probably before. They are not an FSUIPC invention. FS uses them to assign buttons and keys in its Options-Controls-Assignments dialogues. They appear in the DEVICES.CFG and other FS CFG files. All FSUIPC does is allow you to exploit more of them in more ways.

On the http://www.schiratti.com/dowson page you will see lists of FS2000, FS2002 and FS2004 controls. I included an up to date list of FS2004 controls in the FSUIPC.ZIP, for folks to use when programming keys and buttons. However, they can also be used through the FS interface via offset 3110 as I already mentioned.

You missed the easy ways of doing things and proceeded to do something which is obviously far more work. Maybe next time it will be easier, eh? :wink:

Regards,

Pete

Posted
Additional “FS” Controls added by FSUIPC

All the true FS controls are represented by numbers above 65536. They are listed in my FS-version specific documents called “FSxxxx Controls …”. FSUIPC has augmented these with its own set, programmable for both Button and Keys, and these utilise lower numbers, currently in the 1000–3000 range.

I did miss the reading of the header and the mention of the seperat CFG's where Got the offset ides is that on page 29

x0100zzzz Offset Byte Set (offset = zzzz), hexadecimal

x0200zzzz Offset Word Set (offset = zzzz), hexadecimal

x0300zzzz Offset Dword Set (offset = zzzz), hexadecimal

x0500zzzz Offset Byte Setbits (offset = zzzz), hexadecimal

x0600zzzz Offset Word Setbits (offset = zzzz), hexadecimal

x0700zzzz Offset Dword Setbits (offset = zzzz), hexadecimal

x0900zzzz Offset Byte Clrbits (offset = zzzz), hexadecimal

x0A00zzzz Offset Word Clrbits (offset = zzzz), hexadecimal

x0B00zzzz Offset Dword Clrbits (offset = zzzz), hexadecimal

x0D00zzzz Offset Byte Togglebits (offset = zzzz), hexadecimal

x0E00zzzz Offset Word Togglebits (offset = zzzz), hexadecimal

x0F00zzzz Offset Dword Togglebits (offset = zzzz), hexadecimal

x1100zzzz Offset UByte Increment (offset = zzzz), hexadecimal *

x1200zzzz Offset UWord Increment (offset = zzzz), hexadecimal *

x2100zzzz Offset UByte Decrement (offset = zzzz), hexadecimal *

x2200zzzz Offset UWord Decrement (offset = zzzz), hexadecimal *

x3100zzzz Offset SByte Increment (offset = zzzz), hexadecimal *

x3200zzzz Offset SWord Increment (offset = zzzz), hexadecimal *

x4100zzzz Offset SByte Decrement (offset = zzzz), hexadecimal *

x4200zzzz Offset SWord Decrement (offset = zzzz), hexadecimal *

x5100zzzz Offset Byte Cyclic Increment (offset = zzzz), hexadecimal *

x5200zzzz Offset Word Cyclic Increment (offset = zzzz), hexadecimal *

x6100zzzz Offset Byte Cyclic Decrement (offset = zzzz), hexadecimal *

x6200zzzz Offset Word Cyclic Decrement (offset = zzzz), hexadecimal *

* The increment/decrement values operate on Unsigned (U) or Signed (S) values, and have a parameter with the unsigned or signed limit in the upper 16 bits and the increment/decrement amount (always unsigned) in the lower 16 bits.

You really need to read these thing a little more carefully, especially when programming. When you program computers every little detail has to be correct. Just scanning a document too fast and automatically assuming a list of numbers equates to a list of offsets is rather a serious error.

I had assumed these were refs to the offsets due to the heading not changing. I had noticed that these were buttons and keys which is why when I tried to ref that section of offsets via

Function FSUIPC_Write(dwOffset As Long, dwSize As Long, pSrce As Long, ByRef dwResult As Long) As Boolean

I could not get the buttons to push which is when I turned to the hard way.

On the http://www.schiratti.com/dowson page you will see lists of FS2000, FS2002 and FS2004 controls. I included an up to date list of FS2004 controls in the FSUIPC.ZIP, for folks to use when programming keys and buttons. However, they can also be used through the FS interface via offset 3110 as I already mentioned.

You missed the easy ways of doing things and proceeded to do something which is obviously far more work. Maybe next time it will be easier, eh? :wink:

Regards,

Pete

You are right I did do it the hard way and once I get the hard way recoded with your corrections to my code (get rid of the hardcodeing for dec alt) I will post the update. I appricate all the help here. Thanks

Robg

Posted

Got the offset ides is that on page 29

Those are controls for accessing offsets, where the offset is embedded into the control number. There's really no need to use any of those from a program which can access offsets in any case, and, in fact, there is no way provided for you to use them that way. As with all the controls they are for using directly with buttons and keypresses via FSUIPC 's Buttons and Keys pages on screen in FS -- you don't need VB or any other programming language for that.

I had assumed these were refs to the offsets due to the heading not changing.

Oh, I give up! :( :( How can you have possibly assumed that? A list of controls which happen to allow you to access offsets and which never otherwise mentions offsets (let alone headings)? I am really at a complete loss here. I spend hours toiling over these documents and yet you manage to get things so completely twisted like this? How? Just because a word "offset" appears some place in a section doesn't mean the whole thing is a list of offsets. This is crazy! :cry:

THE OFFSET LIST FOR FSUIPC IS IN THE PROGRAMMERS GUIDE, which is part of the FSUIPC SDK. It is the SDK you want. The advanced users guide is an extension to the User's Guide and does not list offsets at all, it is not its job!

Pete

Posted

Oh, I give up! :( :( How can you have possibly assumed that? A list of controls which happen to allow you to access offsets and which never otherwise mentions offsets (let alone headings)? I am really at a complete loss here. I spend hours toiling over these documents and yet you manage to get things so completely twisted like this? How? Just because a word "offset" appears some place in a section doesn't mean the whole thing is a list of offsets. This is crazy! :cry:

THE OFFSET LIST FOR FSUIPC IS IN THE PROGRAMMERS GUIDE, which is part of the FSUIPC SDK. It is the SDK you want. The advanced users guide is an extension to the User's Guide and does not list offsets at all, it is not its job!

Pete

Pete please dont get upset, I did screw up when I was reading the docs back and forth. I combined the SDK and the users guide in my head (I have been working on this for a week solid.) :oops: I have yet to implement your correction to my code. Once it is done I will be able to use the VB code correctly to update the offset. I am sorry for the confusion. :( I did missread the docs, and I did confuse the offsets in the users guide with the offsets in the SDK. :oops: I will repost the corrections to my code with your math and will reduce my code to about 10 or 15 lines vs the current hundreds of lines. Please I have said this more than once your assistance in this has been great. :) Thanks.

Robg

Posted

I will repost the corrections to my code with your math and will reduce my code to about 10 or 15 lines vs the current hundreds of lines.

Okay. I hope you get it sorted okay.

Regards,

Pete

Posted

Okay. I hope you get it sorted okay.

Regards,

Pete

Here is the repaired code with your math fix in thanks for your help, :) sorry about the confusion.:oops:

Dim ALT_IN As Long
Dim dwResult2 As Long
'NOTICE THE TWO ARE ON SEPERATE LINES, IF YOU 
'COMBINE SOMETIMES VB DOES NOT GIVE YOU REAL LONGS
'TWO POSITION ENCODER
If WHICHWAY = 2 Then
    If EncoderDisplacement = 1 Then
'DEC ALT
        Call FSUIPC_Read(&H7D4, 4, VarPtr(ALT_IN), dwResult2)
        Call FSUIPC_Process((dwResult2))
        ALT_OUT = PROCESS_ALT((ALT_IN), False)
'CANT HAVE A NEG ALT
        If ALT_OUT <= 150 Then ALT_OUT = 0
        Call FSUIPC_Write(&H7D4, 4, VarPtr(ALT_OUT), (dwResult2))
        Call FSUIPC_Process((dwResult2))
    End If
    If EncoderDisplacement = -1 Then
'INC ALT
        Call FSUIPC_Read(&H7D4, 4, VarPtr(ALT_IN), dwResult2)
        Call FSUIPC_Process((dwResult2))
        ALT_OUT = PROCESS_ALT((ALT_IN), True)
'FS TAKES CARE OF MAX ALT FROM WHAT I HAVE SEEN
        Call FSUIPC_Write(&H7D4, 4, VarPtr(ALT_OUT), (dwResult2))
        Call FSUIPC_Process((dwResult2))
    End If
End If
End Sub

Function PROCESS_ALT(INVAL As Long, ADDALT As Boolean) As Long
Dim LOCAL_PROC As Long
LOCAL_PROC = Round(((CCur(INVAL) * 328084) / 65536) / 100000, 0)
'VB HAS ISSUES WITH LONGS AND MULTIPLYING DONT ASK ME IT JUST DOES
If Not ADDALT Then
    INVAL = LOCAL_PROC - 100#
Else
    INVAL = LOCAL_PROC + 100#
End If
If INVAL = 0 Then Exit Function
'CHECK FOR 0 FIRST, DOING DIVISION AND HATE THAT DIVIDE BY ZERO ERROR

'WHICH WAY ARE WE GOING UP OR DOWN NOTICE THIS HANDLES INC BY 100
ROUND_OFF_ERROR = Fix(INVAL / 1000)
If ROUND_OFF_ERROR < 10 Then ROUND_OFF_ERROR = 10
'DONT KNOW WHY BUT WHEN I FEED JUST THE NUMBER IN I GET ROUND OFF
'BY FS SO I START WITH 10 AND WORK MY WAY UP, CHECKED
'ALL THE WAY THRU HOWEVER YOUR RESULTS MAY DIFFER SO CHECK MY MATH
PROCESS_ALT = ((INVAL * 65536#) / 3.28084) + ROUND_OFF_ERROR
'FEED IT BACK AN POST TO THE OFFSET.
End Function

Thanks once again Pete

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.