Scaling Localiser and Glideslope Needles for HSI

[Boeing 747 Flyer]

Hi everyone,

After the completion of the code for the range counter (thanks so much Nico!!!), I have just two final things left to do (in terms of motors) on my HSI Unit.

These two things are the Localiser and Glideslope Needles.

Unfortunately, I have had a hard time thinking of a way to scale these two needles. They are both driven by a standard DC motor controlled by the USBDCMotors Card. These Motors are then on the same shaft as a potentiometer which provides feedback for the position of the needles.

The reason it is hard for me to scale them is for two reasons:

- Firstly, they are not controlled by the USBServos Card, but by the Motors card. This means that I cannot provide precision needle control directly through SIOC. I must use a calculation based on the potentiometer position.

- Secondly, the "0" point of the needles are not "0" potentiometer value. This is obvious, because what exactly is the "0" point? The lowest point, or the middle? Furthermore, the localiser and glideslope needles pass both forward and backwards from a central point, so I must take this into account.

I previous developed a script for my Course pointer, but it is rather inefficient (30,000 lines of code for the full 360 degrees). Also, this script cannot provide the backward and forward motion required by a localiser or glideslope.

If you have any ideas on what particular methods/calculations I can use to script these needles, it would be most appreciated.

Kindest regards,

Jack;)

[fordgt40]

Jack

The OC card only has 8 bit resolution, hence your difficulty in getting consistent accuracy. Why not try the Leo Bodnar card which you can still interface with SIOC through a FSUIPC offset and use a quality pot. See this link

http://www.mycockpit.org/forums/showthread.php/21881-Using-BU0836X-and-other-BU0836-cards-with-SIOC-scripts?p=114560&highlight=#post114560

Re the coding, I think that you need to write out the sequence of what you want to achieve and then try to code it. There is no shining light of truth, just logic and hard work:(

Confucius, he say, longest journey starts with first step. Honestly, try to break down the elements of the problem and match that against the commands available in SIOC to develop a solution. Doubtless your 30,000 lines of code on the earlier exercise could be condensed considerably by using a subroutine and passing the changing arguments to it. You have learnt a lot on your last exercise with Nico, so go for it

Regards

David

[Boeing 747 Flyer]

Hi David,

My problem is the actual difference between the potentiometer values and the FSUIPC Offset values.

Regardless of any sort of scripting logic, the first obstacle is that when the Offset reads 0, the Pot reads 57. As you know, there is no number that you can divide a positive integer by to get 0.

Previously, in the CRS thread, I manually assigned each potentiometer value to an FSUIPC value. I am looking for a way to assign/match/"scale" these values in a single calculation, not by doing it one-by-one.

I have, however, done as you said. The principals of the logic are as follows:

- If X is GREATER than Y, the motor moves backwards

- If X is SMALLER than Y, the motor moves forwards

- If X = Y, then the motor stops

(Where X = Offset and Y = Pot)

As you can see, it is quite a simple logic. However, we meet a massive problem in the fact that the FSUIPC Localiser offset ranges from -117 to +117. This means that SIOC will think that X is greater than Y when it is infact smaller, and vice versa, because the Offset value both grows and shrinks when approaching the 0 (centre) mark.

I'm sorry if that is confusing, but I hope you could understand the general jist.

Regards,

Jack

[fordgt40]

Jack

Probably too simplistic but based on your logic flow

Offset value of 0 is same position as pot reading 57

If X is GREATER than Y + 57, the motor moves backwards

- If X is SMALLER than Y + 57, the motor moves forwards

- If X = Y + 57, then the motor stops

(Where X = Offset and Y = Pot)



"As you can see, it is quite a simple logic. However, we meet a massive problem in the fact that the FSUIPC Localiser offset ranges from -117 to +117. This means that SIOC will think that X is greater than Y when it is infact smaller, and vice versa, because the Offset value both grows and shrinks when approaching the 0 (centre) mark".

Why not do a test for a negative offset value, if so, then use the ABS function to make it positive and code the movement accordingly to recognise that it is negative
If the offset value is positive then code it as a normal positive value

This is based on limited knowledge of your problem but hopefully is a "starter for ten"

Regards

David

[Boeing 747 Flyer]

Hi David,

Great idea about the +57; that's the type of scaling advice I am looking for.

One thing: for every "FSX" degree the pot will move approx 2 values. This is because the pot ranges approximately from about 1-57-110, whilst the FSUIPC Offset has a greater range. This means that, as a ratio, the pot moves more than the FSX.

Regards,

Jack

[fordgt40]

Hi David,

One thing: for every "FSX" degree the pot will move approx 2 values. This is because the pot ranges approximately from about 1-57-110, whilst the FSUIPC Offset has a greater range. This means that, as a ratio, the pot moves more than the FSX.


Jack

So scale it the same way you would with a servo.

Programming in SIOC is not rocket science, it is about finding a way to use the available tools. You should now have sufficient knowledge and experience to take this to the next stage and impress Nico :)

Regards

David

[mndless]

Jack... If u can plot the output then you can derive an equation for a line through that output... May well be non linear.. Or you might need two or three equations to represent two or three differing data zones... Just thinking out loud... :)

But I have no idea the constraints of SOIC...

[Boeing 747 Flyer]

Hi David,

This was the data I collected:


MOTOR:

Top = 171

1st Dot = 161

2nd Dot = 148

Middle Line = 130

3rd Dot = 119

4th Dot = 103

Bottom = 97

////////////////

FSX:

Top = 138

1st Dot =

2nd Dot =

Middle Line = 254

3rd Dot =

4th Dot =

Bottom = 119

The FSX GS needle moves from 138 (TOP) to 254 (MIDDLE). The next value after 254 is 0, and it starts counting up again from 0.

138 -> 254 -> 0 -> 119

The MOTOR results are the potentiometer readings for my GS needle. The FSX results are what SIOC reads when the FSX GS needle is at various points (namely middle, top and bottom).

My GS needle has 4 dots, and the FSX one has just 2. So, I am thinking of just using the top, middle and bottom results from both readings as these are the only ones that are common.

As you can see, the FSX needle resets to 0 at the middle, so I need to make the top value (138) slowly increase linearly from top to bottom.

What I mean is, instead of,

138 -> 254 -> 0 -> 119

This:

138 -> 254 -> 255 -> 373

As you can see, the second value goes up equally. The first resets to 0, which will make the scaling much more difficult.

I am wondering how to achieve such a goal. Unfortunately it's not a simple case of adding a number.

Regards,

Jack

[fordgt40]

Jack

This is a moving feast :roll:

You say

"As you can see, it is quite a simple logic. However, we meet a massive problem in the fact that the FSUIPC Localiser offset ranges from -117 to +117"

Now you say that the FSX values go from 138 to 254 and then count back up again to 119" that is different but not insurmountable.

I suggest, again, that you write out the logic in simple text of what you want to happen ie

Read FSX value
Is FSX value more than 138 and less than 254
If yes then we are in stage 1

Else we are in stage 2

Stage 1 move motor to ??
How? work out ramping to match scale
Is the scaling linear ie Do we need one ramp or do we need more
Move motor
Have we got there yet yes or no
if no then repeat

Stage 2 move motor to ??
How? work out ramping etc etc

Just initial crude first thoughts, but ESSENTIAL for you to solve this. Break down the problem into little units, test, amend etc etc.

Try this, it is not as difficult as you may think.

Regards

David

[Boeing 747 Flyer]

Hi David,

I have had a go and this is the fruit of my labour for the scaling.

Please note, I am scaling the glideslope needle first, not the localiser:


Var 100 link FSUIPC_IN Length 1 Offset $023A // seconds of FS time (0 - 59)
{
CALL &Value_Calc
CALL &Position // Call our variables that control the motor
}

Var 0005, name GS, Link FSUIPC_IN, Offset $0C49, Length 1 // FSUIPC GS Source

Var 30, name Calc // Calculation holding variable

Var 58, name Pot, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer

Var 3, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot - &GS
&Calc = L0 + &Pot
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 0002, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &GS >= 138
{
IF &GS <= 254
{
IF &Calc > &GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc < &GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc = &GS
{
&Motor_1 = 128
}
}
}
}
}
}

As you can see, the variable "Calc" holds the value that "translates" between the FSX and Potentiometer values.

This is for STAGE 1 ONLY, ie from the top to middle.

Regards,

Jack

[fordgt40]

Jack

I was expecting you to outline your logic flow and not rush into coding. I will repeat yet again, as others have tried to tell you, that firstly you must look at the overall picture and write down the sequence, conditions, parameters etc of what you want to achieve for the ENTIRE programme. If you do not do this then:-

1) You keep having to amend code that you have written as things happen that you did not take the time to identify or consider
2) You get bogged down writing code with no clear idea of the end result
3) Your final code will look and work horribly - 30,000 lines of code? :)

Turning to your code above, leaving the syntax error aside, have you done a dry run in your mind to check if what is happening meets your requirements? I suspect not, as it does not look correct to me. Take a known set of pot values and GS values at a certain point and work through your code to check.

Again, I strongly counsel you to avoid the compulsive urge to start coding and concentrate on the overall logic flow. Keep at it . No pain no gain:)

Regards

David

[Boeing 747 Flyer]

Hi David,

I spent just under an hour last night, interestingly with a pen and paper, planning this out.

I appreciate there may be problems with it but the point is this is the result of my hard work.

Firstly, I planned out what I wanted to do. Secondly, I wrote out the scripting.

In brief, this was my plan:

- Scale between GS and Pot
- If this value is too low, move up. And vice versa
- If the values are equal, don't move the motor

Of course, what I actually wrote was much longer than this; it is just a brief.

I appreciate there are problems but please, if you can, improve it, and point out my errors. The Value_Calc subrutine is wrong, I know. I couldn't find a scale that would work.

Regards,

Jack

[fordgt40]

Jack

I am not doubting your effort, just the direction:) You really need to write out your requirements etc for the whole "programme" not part of it. It is only then that you can see how to structure the code.

A gripe if I may - why present something for me to look at if you know that the scaling is wrong, that is inconsiderate and wastes my time:mad:

Moving on, you know both the pot and G/S values from top to middle, so it is a ratio, similar to work you have done with servos on other threads.
I suggest you look at these previous servo codings, 737NUT gave some examples and links etc. Rightly or wrongly, I do not think the best way of helping is to write or closely peruse/troubleshoot the code for you, assuming I had the time, it is for you to learn, try, amend, correct, try again etc etc. That is the way to get to grips with SIOC. If you demonstrate this, then I will gladly help on any future stumbling blocks, assuming I have the competence

Regards

David

[Boeing 747 Flyer]

Hi David,

No problem, I managed to figure everything out.

This is correct:


Var 100 link FSUIPC_IN Length 1 Offset $023A // seconds of FS time (0 - 59)
{
CALL &Value_Calc
CALL &Position // Call our variables that control the motor
}

Var 0005, name GS, Link FSUIPC_IN, Offset $0C49, Length 1 // FSUIPC GS Source

Var 30, name Calc // Calculation holding variable

Var 58, name Pot, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer

Var 3, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Motor_1 * 2.83
L0 = &Motor_1 - 621.86
&Calc = L0 * -1
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 0002, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &GS >= 138
{
IF &GS <= 254
{
IF &Calc > &GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc < &GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc = &GS
{
&Motor_1 = 128
}
}
}
}
}
}



This code perfectly scales the top half of the GS motor. The bottom half is identical; it's just that it uses a different multiplier and negative value in the calculation of Var 3.

Tell me what you think.

Regards,

Jack

[fordgt40]

Jack

Excellent - see you can do it ! Just one error that has missed your quality check :)

In your scaling calcs you are using variable &motor_1 when it should be &pot.

I will not criticise this too much, given that I wasted 2 hours last night trying to make a pot recognised by SIOC. I had cut and pasted code from another script without noticing that there are two commands for reading analogue ports. IOCARD_ANALOGIC from a USB expansion card and USB_ANALOGIC from a servo or dc motors card. I had the wrong one !!

Regards

David

[Boeing 747 Flyer]

Hi David,

I have ran the following script with some sucess:


// *****************************************************************************
// * Config_SIOC ver 3.7B1 - By Manolo Vélez - www.opencockpits.com
// *****************************************************************************
// * FileName : Glideslope.txt
// * Date : 6/10/2011



Var 0100, Link FSUIPC_IN, Offset $023A, Length 1 // seconds of FS time (0 - 59)
{
CALL &Value_Calc
CALL &Value_Calc2
CALL &Position // Call our variables that control the moto
CALL &Position2
}

Var 0005, name GS, Link FSUIPC_IN, Offset $0C49, Length 1 // FSUIPC GS Source

Var 0030, name Calc // Calculation holding variable

Var 0031, name Calc2 // Calculation holding variable (2nd)

Var 0058, name Pot, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer

Var 0003, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 2.83
L0 = &Pot - 621.86
&Calc = L0 * -1
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 0002, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &GS >= 138
{
IF &GS <= 254
{
IF &Calc > &GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc < &GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc = &GS
{
&Motor_1 = 128
}
}
}
}
}
}

Var 0009, name Position2, Link SUBRUTINE // The Calculations for driving the motor (
{
IF &GS >= 0
{
IF &GS <= 119
{
IF &Calc2 > &GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc2 < &GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc2 = &GS
{
&Motor_1 = 128
}
}
}
}
}
}

Var 0561, name Value_Calc2, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 3.6
L0 = &Pot - 468.2
&Calc2 = L0 * -1
}



The Calc2 variables are so forth are to cover the bottom half of the GS offset, from 0 to 119.

The sucess was that, when the GS needle was at the top of the HSI in FSX, my needle rose top the top.

But... That was it. Even though the GS value changed, I did not see the motor move. Looking in IOCPConsole, it is clear that the Calc variable is not changing value at all, which explains the stationary motor. The position variable also does not change value.

Why is this happeneing? The ValueCalc variables should detect the difference between the GS offset and my pot, and should start to move the motor.

Unfortunately, they don't for some strange reason!:p

Regards,

Jack

[fordgt40]

Jack

It is unclear from your post which sections are not happening correctly!

A quick perusal, I could be wrong, but you need to re-examine your coding for the calc2 section. Earlier you said that at the "middle" section then FSX read 254 and the pot read 130. Try a dry run through your coding and I think that you will find there is an error as the result of your coding should be that at those respective positions the motor should be at zero speed ie calc2 and GS should be equal

Also, why are you calling both calc subroutines each time? I though my earlier text logic flow suggested identifying which section of "movement " you were in and calling the appropriate and different subroutine

Regards

David

[Boeing 747 Flyer]

Hi David,

At Pot = 130, FSX could either be at 254 or 0.

It should be made clear that 254 and 0 are almost the same thing. The gap between the two values is negligable, and they both pretty much represent the middle. The Pot = 130 at the middle.

EG:

FSX = 0

Calc = 130 * 3.6
Calc = 468 - 468
Calc = 0 * -1
Calc = 0

Pot and FSX are equal, so nothing happens

FSX = 254

Calc = 130 * 2.83
Calc = 367.9 - 621.86
Calc = -253.96 *-1
Calc = 253.96 ROUND = 254

As you can see, the calculations allow a smooth transition over the middle point.

When I meant it was not working, I meant...

When the FSX GS needle was at the very top, my needle moved all the way to the top.

But... That was it. When the FSX needle moved down, my needle stays still. This meant that the needle was being governed by the TOP (Calc, not Calc 2) formula.

Regards,

Jack

[fordgt40]

Jack

Thanks for the explanation, though it is difficult to comment on the code - it is a bit like reading a page through a microscope when you have no external references :)
Have you tried using the iocpconsole log function - that will show when the motor stops and should give you a pointer as to why

Regards

David

[Boeing 747 Flyer]

HI David,

I have looked in the IOCPConsole and it is weird...

Basically, whenever FSX is started, the GS value always reads 0. As a result, the motor moves to the 0 position (middle)... But keeps on going until it hits the bottom. From here, no matter what the value of GS, the motor remains motionless on the bottom of the glideslope.

Interestingly, in IOCPConsole, SIOC is reporting values of "Calc" incorrectly. See here:


58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
100=0 - seconds of FS time (0 - 59)
3=0 - Value_Calc
30=451 - Calc
561=0 - Value_Calc2
31=297 - Calc2
2=0 - Position
9=0 - Position2
1=120 - Motor_1
5=0 - GS

With the Pot at 171, how on earth can Calc be 451?

Calc = 171 * 2.83
Calc = 483.93 - 621.86
Calc = -137.93
Calc = -137.93 * -1
Calc - 137.93 ROUND = 138

Clearly, something is wrong. How is SIOC getting 451, it should be 138.

Regards,

Jack

[fordgt40]

Jack

I do not believe that SIOC cannot do maths :)

In your code here

L0 = &Pot * 2.83
L0 = &Pot - 621.86
&Calc = L0 * -1

Change to

Try

L0 = &Pot * 2.83
L0 = L0 - 621.86
&Calc = L0 * -1

Regards

David

[Boeing 747 Flyer]

Hi David,

Still no luck.

What do you make of this though (IOCPConsole Log):


5=183 - GS
58=171 - Pot
58=172 - Pot
5=178 - GS
5=174 - GS
5=170 - GS
100=56 - seconds of FS time (0 - 59)
5=165 - GS
5=161 - GS
5=157 - GS
5=153 - GS
100=57 - seconds of FS time (0 - 59)
5=149 - GS
5=145 - GS
5=141 - GS
100=58 - seconds of FS time (0 - 59)
5=138 - GS
100=59 - seconds of FS time (0 - 59)
100=0 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=1 - seconds of FS time (0 - 59)
100=2 - seconds of FS time (0 - 59)
100=3 - seconds of FS time (0 - 59)
100=4 - seconds of FS time (0 - 59)
100=5 - seconds of FS time (0 - 59)
58=171 - Pot
100=6 - seconds of FS time (0 - 59)
30=138 - Calc
31=-147 - Calc2
1=128 - Motor_1
58=172 - Pot
100=7 - seconds of FS time (0 - 59)
30=135 - Calc
31=-151 - Calc2
1=250 - Motor_1
100=8 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=9 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=10 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=11 - seconds of FS time (0 - 59)
100=12 - seconds of FS time (0 - 59)
100=13 - seconds of FS time (0 - 59)
100=14 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=15 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=16 - seconds of FS time (0 - 59)
58=171 - Pot
100=17 - seconds of FS time (0 - 59)
30=138 - Calc
31=-147 - Calc2
1=128 - Motor_1
58=172 - Pot
100=18 - seconds of FS time (0 - 59)
30=135 - Calc
31=-151 - Calc2
1=250 - Motor_1
100=19 - seconds of FS time (0 - 59)
100=20 - seconds of FS time (0 - 59)
100=21 - seconds of FS time (0 - 59)
100=22 - seconds of FS time (0 - 59)
100=23 - seconds of FS time (0 - 59)
100=24 - seconds of FS time (0 - 59)
100=25 - seconds of FS time (0 - 59)
100=26 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=27 - seconds of FS time (0 - 59)
100=28 - seconds of FS time (0 - 59)
100=29 - seconds of FS time (0 - 59)
100=30 - seconds of FS time (0 - 59)
100=31 - seconds of FS time (0 - 59)
100=32 - seconds of FS time (0 - 59)
100=33 - seconds of FS time (0 - 59)
100=34 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=35 - seconds of FS time (0 - 59)
100=36 - seconds of FS time (0 - 59)
100=37 - seconds of FS time (0 - 59)
100=38 - seconds of FS time (0 - 59)
100=39 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=40 - seconds of FS time (0 - 59)
58=171 - Pot
100=41 - seconds of FS time (0 - 59)
30=138 - Calc
31=-147 - Calc2
1=128 - Motor_1
58=172 - Pot
100=42 - seconds of FS time (0 - 59)
30=135 - Calc
31=-151 - Calc2
1=250 - Motor_1
100=43 - seconds of FS time (0 - 59)
100=44 - seconds of FS time (0 - 59)
100=45 - seconds of FS time (0 - 59)
100=46 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
100=47 - seconds of FS time (0 - 59)
100=48 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
100=49 - seconds of FS time (0 - 59)
100=50 - seconds of FS time (0 - 59)
100=51 - seconds of FS time (0 - 59)
100=52 - seconds of FS time (0 - 59)
100=53 - seconds of FS time (0 - 59)
100=54 - seconds of FS time (0 - 59)
100=55 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
100=56 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=57 - seconds of FS time (0 - 59)
100=58 - seconds of FS time (0 - 59)
100=59 - seconds of FS time (0 - 59)
100=0 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=1 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=2 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=3 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=4 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
100=5 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=6 - seconds of FS time (0 - 59)
100=7 - seconds of FS time (0 - 59)
100=8 - seconds of FS time (0 - 59)
100=9 - seconds of FS time (0 - 59)
100=10 - seconds of FS time (0 - 59)
100=11 - seconds of FS time (0 - 59)
100=12 - seconds of FS time (0 - 59)
100=13 - seconds of FS time (0 - 59)
100=14 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
100=15 - seconds of FS time (0 - 59)
100=16 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=17 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
100=18 - seconds of FS time (0 - 59)
5=139 - GS
100=19 - seconds of FS time (0 - 59)
5=140 - GS
5=141 - GS
100=20 - seconds of FS time (0 - 59)
5=142 - GS
5=143 - GS
100=21 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
5=144 - GS
5=145 - GS
100=22 - seconds of FS time (0 - 59)
5=146 - GS
5=147 - GS
5=148 - GS
100=23 - seconds of FS time (0 - 59)
5=149 - GS
5=150 - GS
100=24 - seconds of FS time (0 - 59)
5=151 - GS
5=152 - GS
5=153 - GS
100=25 - seconds of FS time (0 - 59)
5=154 - GS
5=155 - GS
100=26 - seconds of FS time (0 - 59)
5=156 - GS
5=157 - GS
100=27 - seconds of FS time (0 - 59)
5=158 - GS
5=159 - GS
5=160 - GS
5=161 - GS
100=28 - seconds of FS time (0 - 59)
58=171 - Pot
5=162 - GS
58=172 - Pot
5=163 - GS
5=164 - GS
100=29 - seconds of FS time (0 - 59)
5=165 - GS
5=166 - GS
5=167 - GS
100=30 - seconds of FS time (0 - 59)
5=168 - GS
5=169 - GS
5=171 - GS
100=31 - seconds of FS time (0 - 59)
5=172 - GS
5=173 - GS
5=174 - GS
100=32 - seconds of FS time (0 - 59)
58=171 - Pot
58=172 - Pot
5=175 - GS
5=176 - GS
5=178 - GS
100=33 - seconds of FS time (0 - 59)
5=179 - GS
5=180 - GS
5=181 - GS
100=34 - seconds of FS time (0 - 59)
5=183 - GS
5=184 - GS
5=185 - GS
100=35 - seconds of FS time (0 - 59)
5=187 - GS
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot

I know it's alot to read, but it is pretty much the same thing repeated.

As you can see, as GS changes value, and as FS seconds (time) go on, the Calc and Position Subroutines are not called at all.

Apart from the "Calcs" near the top, it is never called anywhere else. Why?

Regards,

Jack

[fordgt40]

Jack

Can we deal with one thing at a time. What happened when you made the correction to your code presumably that solved the "incorrect calculation" ie you got the correct value for &calc? If not then what did you get?

Regards

David

[Boeing 747 Flyer]

Hi David,

Yes, as you can see we now get:

Pot = 171
Calc = 138

As it should be. We get a weird, useless Calc2 value, but this is because 171 Pot is NOT in Calc2's range, so it can't calculate it properly.

Jack

[Boeing 747 Flyer]

Hi David,

Interestingly, I called the subroutines (the calculating ones) from the GS offset itself.


// *****************************************************************************
// * Config_SIOC ver 3.7B1 - By Manolo Vélez - www.opencockpits.com
// *****************************************************************************
// * FileName : Glideslope.txt
// * Date : 6/10/2011



Var 0100, Link FSUIPC_IN, Offset $023A, Length 1 // seconds of FS time (0 - 59)
{
CALL &Position // Call our variables that control the moto
CALL &Position2
}

Var 0005, name GS, Link FSUIPC_IN, Offset $0C49, Length 1 // FSUIPC GS Source
{
CALL &Value_Calc
CALL &Value_Calc2
}

Var 0030, name Calc // Calculation holding variable

Var 0031, name Calc2 // Calculation holding variable (2nd)

Var 0058, name Pot, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer

Var 0003, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 2.83
L0 = L0 - 621.86
L0 = L0 * -1
&Calc = ROUND L0
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 0002, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &GS >= 138
{
IF &GS <= 254
{
IF &Calc > &GS
{
&Motor_1 = 120
}
ELSE
{
IF &GS >= 138
{
IF &GS <= 254
{
IF &Calc < &GS
{
&Motor_1 = 250
}
ELSE
{
IF &GS >= 138
{
IF &GS <= 254
{
IF &Calc = &GS
{
&Motor_1 = 128
}
}
}
}
}
}
}
}
}
}

Var 0009, name Position2, Link SUBRUTINE // The Calculations for driving the motor (
{
IF &GS >= 0
{
IF &GS <= 119
{
IF &Calc2 > &GS
{
&Motor_1 = 120
}
ELSE
{
IF &GS >= 0
{
IF &GS <= 119
{
IF &Calc2 < &GS
{
&Motor_1 = 250
}
ELSE
{
IF &GS >= 0
{
IF &GS <= 119
{
IF &Calc2 = &GS
{
&Motor_1 = 128
}
}
}
}
}
}
}
}
}
}

Var 0561, name Value_Calc2, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 3.6
L0 = L0 - 468.2
L0 = L0 * -1
&Calc2 = ROUND L0
}


Weirdly, the Calc and Calc2 variables were only called at random times. According to the script, they should be called every time GS changes value; of which tyey certainly do not.

Regards,

Jack

[fordgt40]

Jack

Try removing the var 100 timing routine and see what happens. I strongly counsel you to reduce the code to smaller sections eg bracket out the second cals/position routines and get that working - then add other sections building upon a sound base. If you keep changing the logic flow then you will lose track and reference points.

Regards

David

[Boeing 747 Flyer]

HI David,

If I remove the Var 100 routine what will be there to call the subroutines?

Also, I'm not sure whart you mean regarding the "reduce coding".

Jack

[fordgt40]

Jack

I mean simplifying your code to get the basic building blocks working and then progress. You do not need the timer routine to check movement against the glideslope - do you? Also get calc 1 working first before introducing calc2. This avoids potential cross corruption and makes troubleshooting easier. This is basic programming :)

Regards

David

[Boeing 747 Flyer]

Do you mean just checking the values of the Calc variables against the GS one? Nothing to do with the position vars?

Jack

[kiek]

Hi Jack,


Weirdly, the Calc and Calc2 variables were only called at random times. According to the script, they should be called every time GS changes value;

Please be more precise in your wording ....

In programming Subroutines are called but Variables are assigned values...
So Calc and Calc2 are not 'called', but may get a new value when Value_Calc and Value_Calc2 subroutines are called.

I think the log file only shows variables that have been assigned a NEW value!
The fact that you do not see Calc and Calc2 anymore in the log tell us that they have not changed since...

regards,
Nico

[fordgt40]

Jack

I mean splitting your code into seperate functional elements, testing and when satisfied add the next function. Test that and so on. If you encounter a problem then you can identify the area. I would deal with the calc variables v gs first and then and positioning - it is up to you but please do not radically change your logic flow when something does not work - that is a recipe for anarchy

Regards

David

[Boeing 747 Flyer]

Hi David,

I removed the position part of the code, and also added a switch trigger to move the motor (and, therefore, the Pot) up and down.

This is essential because, should the Pot not ever change value, Calc/Calc2 will always be the same number and therefore impossible to test.

So, I did a test of my flying around the glideslope whilst moving the motor up and down. This was the results:


12=1 - Switch
1=120 - Motor_1
58=98 - Pot
12=0 - Switch
58=97 - Pot
58=98 - Pot
13=1 - Switch2
1=250 - Motor_1
13=0 - Switch2
58=99 - Pot
58=100 - Pot
58=101 - Pot
58=102 - Pot
58=103 - Pot
58=104 - Pot
58=105 - Pot
58=106 - Pot
58=107 - Pot
58=108 - Pot
58=109 - Pot
58=110 - Pot
58=111 - Pot
58=112 - Pot
58=113 - Pot
58=114 - Pot
58=115 - Pot
58=116 - Pot
58=117 - Pot
58=118 - Pot
58=119 - Pot
58=120 - Pot
58=121 - Pot
58=122 - Pot
58=123 - Pot
58=124 - Pot
58=125 - Pot
58=126 - Pot
58=127 - Pot
58=128 - Pot
58=129 - Pot
58=130 - Pot
58=131 - Pot
58=132 - Pot
58=133 - Pot
58=134 - Pot
58=135 - Pot
58=136 - Pot
58=137 - Pot
58=138 - Pot
58=139 - Pot
58=140 - Pot
58=141 - Pot
58=142 - Pot
58=143 - Pot
58=145 - Pot
58=146 - Pot
58=147 - Pot
58=148 - Pot
58=149 - Pot
58=150 - Pot
58=151 - Pot
58=152 - Pot
58=153 - Pot
58=154 - Pot
58=155 - Pot
58=156 - Pot
58=157 - Pot
58=158 - Pot
58=159 - Pot
58=160 - Pot
58=161 - Pot
58=162 - Pot
58=163 - Pot
58=164 - Pot
58=165 - Pot
58=166 - Pot
58=167 - Pot
58=168 - Pot
58=169 - Pot
58=170 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot
5=117 - GS
30=135 - Calc
31=-151 - Calc2
58=171 - Pot
58=172 - Pot
5=115 - GS
5=114 - GS
5=112 - GS
5=111 - GS
5=109 - GS
5=108 - GS
5=107 - GS
5=106 - GS
5=105 - GS
5=104 - GS
12=1 - Switch
1=120 - Motor_1
12=0 - Switch
58=171 - Pot
58=170 - Pot
58=169 - Pot
58=168 - Pot
58=167 - Pot
58=166 - Pot
58=165 - Pot
58=164 - Pot
58=163 - Pot
58=162 - Pot
58=161 - Pot
58=160 - Pot
58=159 - Pot
58=158 - Pot
5=105 - GS
30=175 - Calc
31=-101 - Calc2
58=157 - Pot
58=156 - Pot
58=155 - Pot
58=154 - Pot
58=153 - Pot
58=152 - Pot
58=151 - Pot
58=150 - Pot
58=149 - Pot
58=148 - Pot
5=106 - GS
30=203 - Calc
31=-65 - Calc2
58=147 - Pot
58=146 - Pot
58=145 - Pot
58=143 - Pot
5=107 - GS
30=217 - Calc
31=-47 - Calc2
58=142 - Pot
58=141 - Pot
58=140 - Pot
58=139 - Pot
58=138 - Pot
58=137 - Pot
5=108 - GS
30=234 - Calc
31=-25 - Calc2
58=136 - Pot
58=135 - Pot
58=134 - Pot
58=133 - Pot
58=132 - Pot
58=131 - Pot
5=109 - GS
30=251 - Calc
31=-3 - Calc2
58=130 - Pot
58=129 - Pot
58=128 - Pot
58=127 - Pot
58=126 - Pot
58=125 - Pot
58=124 - Pot
5=110 - GS
30=271 - Calc
31=22 - Calc2
58=123 - Pot
58=122 - Pot
58=121 - Pot
58=120 - Pot
58=119 - Pot
58=118 - Pot
58=117 - Pot
5=111 - GS
30=291 - Calc
31=47 - Calc2
58=116 - Pot
58=115 - Pot
58=114 - Pot
58=113 - Pot
58=112 - Pot
58=111 - Pot
58=110 - Pot
5=112 - GS
30=311 - Calc
31=72 - Calc2
58=109 - Pot
58=108 - Pot
58=107 - Pot
58=106 - Pot
58=105 - Pot
58=104 - Pot
58=103 - Pot
58=102 - Pot
58=101 - Pot
58=100 - Pot
5=113 - GS
30=339 - Calc
31=108 - Calc2
58=99 - Pot
58=98 - Pot
5=114 - GS
30=345 - Calc
31=115 - Calc2
58=97 - Pot
58=98 - Pot
5=113 - GS
5=112 - GS
13=1 - Switch2
1=250 - Motor_1
13=0 - Switch2
5=111 - GS
58=99 - Pot
58=100 - Pot
58=101 - Pot
58=102 - Pot
58=103 - Pot
58=104 - Pot
58=105 - Pot
58=106 - Pot
58=107 - Pot
58=108 - Pot
58=109 - Pot
58=110 - Pot
58=111 - Pot
58=112 - Pot
58=113 - Pot
58=114 - Pot
58=115 - Pot
5=110 - GS
30=296 - Calc
31=54 - Calc2
58=116 - Pot
58=117 - Pot
58=118 - Pot
58=119 - Pot
58=120 - Pot
58=121 - Pot
58=122 - Pot
58=123 - Pot
58=124 - Pot
58=125 - Pot
58=126 - Pot
58=127 - Pot
58=128 - Pot
58=129 - Pot
58=130 - Pot
58=131 - Pot
5=109 - GS
30=251 - Calc
31=-3 - Calc2
58=132 - Pot
58=133 - Pot
58=134 - Pot
58=135 - Pot
58=136 - Pot
58=137 - Pot
58=138 - Pot
58=139 - Pot
58=140 - Pot
58=141 - Pot
58=142 - Pot
58=143 - Pot
58=145 - Pot
58=146 - Pot
58=147 - Pot
58=148 - Pot
5=108 - GS
30=203 - Calc
31=-65 - Calc2
58=149 - Pot
58=150 - Pot
58=151 - Pot
58=152 - Pot
58=153 - Pot
58=154 - Pot
58=155 - Pot
58=156 - Pot
58=157 - Pot
5=107 - GS
30=178 - Calc
31=-97 - Calc2
58=158 - Pot
58=159 - Pot
58=160 - Pot
58=161 - Pot
58=162 - Pot
58=163 - Pot
5=106 - GS
30=161 - Calc
31=-119 - Calc2
58=164 - Pot
58=165 - Pot
58=166 - Pot
5=105 - GS
30=152 - Calc
31=-129 - Calc2
58=167 - Pot
58=168 - Pot
58=169 - Pot
5=104 - GS
30=144 - Calc
31=-140 - Calc2
58=170 - Pot
58=171 - Pot
58=172 - Pot
5=103 - GS
30=135 - Calc
31=-151 - Calc2
58=171 - Pot
58=172 - Pot
5=101 - GS
5=100 - GS
5=98 - GS
5=96 - GS
5=93 - GS
5=91 - GS
5=89 - GS
5=86 - GS
58=171 - Pot
58=172 - Pot
5=83 - GS
5=80 - GS
5=77 - GS
58=171 - Pot
58=172 - Pot
5=74 - GS
5=71 - GS
5=68 - GS
5=67 - GS
58=171 - Pot
58=172 - Pot
58=171 - Pot
58=172 - Pot

The Calc variables are only active when GS changes value, so I shall pick certain times from the above test to comment on...

- When GS = 117 (That's right at the very, very bottom of the GS needle)
Pot = 172
Calc = 172*2.83 = 486.76 - 621.86 = -135.1 * -1 = 135.1 = 135
Calc2 = 172*3.60 = 619.2 - 468.2 = 151

Now, you'll notice these are both nonsense readings; due to a problem I tried to explain earlier but couldn't explain correctly.

Pot = 172 means that my GS needle is at the very top

But... GS = 117 means that the FSX needle is at the very bottom.

Therefore, Calc2, which handles the bottom half, is getting its information from a Pot that is not in its zone. Calc, however, is getting information from the correct zone, but cannot reference it to the FSX needle as the "GS" variable is in Calc2's half.

Here, we have a contradiction. Both Calcs are trying to do each other's job.

In other words, Calc is trying to scale my Pot to a FSX needle ABOVE the middle line (of which it isn't), and Calc2 is trying to scale my Pot to a FSX needle BELOW the middle line (which it is, but my Pot is above the top line).

Jack

[fordgt40]

Jack

"Here, we have a contradiction. Both Calcs are trying to do each other's job."

That is why I suggested a long way back that you do a test to see which calc or calc2 that you need. Not both together

Regards

David

[Boeing 747 Flyer]

Hi David,

We obviously need two different calculations, as FSX has two segments.

The first, from 138 to 254, and then from 0 to 119.

Jack

[737NUT]

If it were me, i would try this, but not knowing the actual numbers this is a guess. Docs say output for glideslope is -127 to 127. Is this what SIOC see's? If so, easy, add 127 to the fsuipc output so now you have a range of 0 to 254 with 127 being the middle. Lets say GS Pos 0=40 Pot pos and 127 GS Pos = 155 Pot and GS Pos 254 = 220 Pot pos Now you have enough info to do some slope and intercept math to get an "adjusted" number to drive your motor's just like a servo. Make sense? Here is the site explaining the math for this. i used this method when driving all the real gauges I have/had. Your method is a little harder due to extra coding for the motor position but it is do-able. http://www.baron58.com/Servo_Calc.htm

Rob

[Boeing 747 Flyer]

HI Rob,

Indeed, whatever SIOC sees is not what the FSUIPC SDK manual says.

The GS offset seems to go from 138-254, and then from 0 to 119. I am using offset $0C49.

The manual says it should go from -119 to +119. Maybe you're thinking of the localiser offset? That definitely runs from -117 to +117.

Jack

[Boeing 747 Flyer]

Hi Rob,

I have posted on Pete Dowson's forum and asked him about the glideslope offsets.

Jack

[Boeing 747 Flyer]

I am getting similar results with the localiser needle offset, 048C.

The SDK states that they should range from -117 to +117... But my results are nothing like that. Instead, I get 138-254, and 0-119.

Weird.

Jack

[737NUT]

I am getting similar results with the localiser needle offset, 048C.

The SDK states that they should range from -117 to +117... But my results are nothing like that. Instead, I get 138-254, and 0-119.

Weird.

Jack

Then it has to be how FSUIPC is interpreting it or the docs are wrong. Will be interesting to see what pete says.

[Boeing 747 Flyer]

HI everyone,

Fantastic news.

I have managed to get the GS needle fully working.

I had to do two things...

Firstly, I had to define Offset 049C as Type 1. Without this definition, I get nonsense results which make it impossible to work with.

Secondly, I had to rework the potentiometer values. As the GS values increase as it goes down, my Pot does the opposite. So, I rectified this, and now they both increase as they move down.

This is the script:


Var 0005, name GS, Link FSUIPC_IN, Offset $0C49, Length 1, Type 1 // FSUIPC GS Source
{
L0 = &GS + 119
&New_GS = L0
}

Var 0097, name Potentiometer, Link SUBRUTINE
{
L0 = &Pot_Orig * -1
L0 = L0 + 171
&Pot = L0
CALL &Value_Calc
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 0058, name Pot_Orig, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer
{
CALL &Potentiometer
}

Var 9991, name New_GS

Var 8754, name Pot

Var 0003, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 3.260
&Calc = L0
CALL &Position
}

Var 0030, name Calc // Calculation holding variable

Var 0002, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &Calc > &New_GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc < &New_GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc = &New_GS
{
&Motor_1 = 128
}
}
}
}

It may be a little messy but I am so pleased that it works.

Thank you so much,

Jack

[kiek]

Hi Jack,
Congratulations!

For other readers wondering what did the 'trick':

Some FSUIPC offsets contain as well negative as positive values, or in other words, they contain 'signed' values. Eg a byte can then hold values between -127 and + 127. While an 'unsigned' byte can hold values between 0 and 255.

However a Variable in SIOC is by default treated by SIOC as 'unsigned'. If you want SIOC to treat a variable as signed you have to add the attribute Type 1.
More here (http://www.lekseecon.nl/howto.html#readFSUIPC)

regards,
Nico Kaan

[fordgt40]

Jack

Glad you got there in the end

David

[Boeing 747 Flyer]

Hi everyone,

I have just noticed a problem due to how FSX handles this offset.

Whenever the GS needle is not on the scale, GS = 0, which means the needle is in the centre. Clearly, however, if the GS needle is not on the scale, it is not in the middle.

I am wondering on what is the best way to tackel this issue.

Jack

[737NUT]

Isn't there an offset for GS Active? If so, when that active, center needle, when not, deflect off of scale.

Rob

[Boeing 747 Flyer]

Hi Rob,

I managed to fix it be implementing the GS Flag offset into the script. Even then though, I have to tell SIOC that if the needle is at 0, it's actually not (if you get that).

We now have another problem. When attempting to compile the following script with another (group compile), I get an error:

"ERROR: Line 19 "Var 0001"

This is the script:


Var 0, Value 0
{
&Motor_1 = 120
IF &Motor_1 = 120
{
&Motor_1 = 250
}
}

Var 814 link FSUIPC_IN Length 1 Offset $023A // seconds of FS time (0 - 59)
{
IF &New_GS = 119
{
IF &GS_Flag = 0
{
&New_GS = 0
}
}
}

Var 0005, name GS_Flag, Link FSUIPC_IN, Offset $0C4C, Length 1, // FSUIPC GS FLAG Source

Var 0866, name GS, Link FSUIPC_IN, Offset $0C49, Length 1, Type 1 // FSUIPC GS Source
{
L0 = &GS + 119
&New_GS = L0
}

Var 0097, name Potentiometer, Link SUBRUTINE
{
L0 = &Pot_Orig * -1
L0 = L0 + 171
&Pot = L0
CALL &Value_Calc
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 0058, name Pot_Orig, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer
{
CALL &Potentiometer
}

Var 9991, name New_GS

Var 8754, name Pot

Var 0003, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 3.260
&Calc = L0
CALL &Position
}

Var 0030, name Calc // Calculation holding variable

Var 0002, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &Calc > &New_GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc < &New_GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc = &New_GS
{
&Motor_1 = 128
}
}
}
}

AS you can see, there is nothing wrong with line 19 (it's the one that defines the FS time offset).

I take it that the error is from SIOC renumbering all my vars in the group compile?

The other file is clean, it has nothing to do with this error.

Jack

[kiek]

Hi Jack,
If you get a compile error it is most certainly caused by the last change you made. So try to remember what you have changed..

From what you write it is the addition of the GS_Flag, maybe it is the extra comma after Lenght 1 ?

regards,
Nico

[Boeing 747 Flyer]

HI Nico,

I removed the comma and still not luck.

Interestingly, the two files compile seperately, but not together. This usually means a "var already exists" error, but as you can see, all the variables have different names. It is a "command outside place error".

Jack

[kiek]

Jack,
Export to one .TXT file and look at line 19... (after that, delete that .TXT file).
Nico

[Boeing 747 Flyer]

Hi Nico,

Do you mean merge the two files, or compile them together and teh nexport as txt?

Jack

[Boeing 747 Flyer]

Hi Nico,as

I'm still working on compiling both files together.

Still no luck. SIOC is telling me that "0001" is causing the problem (note it is not me naming it 0001, but SIOC's group compiler that changes it to 0001).

I don't see what the problem is. I have changed the variable numbers, triple-checked all brackets (though it's impossible to be a problem here as both files compile just fine seperately), and even tried changing the order of the scripts. Still no luck.

It's getting quite frustrating now. Please, tell me, what does "0001" mean? And why is SIOC telling me that this number is the problem?

These are the EXACT two files that I'm using; seperately they compile fine. I'll even put the order in which they're compiled in the config.ini file.

File 1, Localiser:


Var 0, Value 0
{
&Motor_5 = 120
IF &Motor_5 = 120
{
&Motor_5 = 250
}
}

Var 7586, name LOC, Link FSUIPC_IN, Offset $0C48, Length 1, Type 1 // FSUIPC LOC Source
{
L0 = &LOC + 127
&New_LOC = L0
}

Var 2837, name Potentiometer2, Link SUBRUTINE
{
L0 = &Pot_Orig2 * -1
L0 = L0 + 180
&Pot2 = L0
CALL &Value_Calc2
}

Var 2721, name Motor_5, Link USB_DCMOTOR, Output 5 // Motor

Var 5847, name Pot_Orig2, Link USB_ANALOGIC, Input 1, PosL 0, PosC 127, PosR 250 // Potentiometer
{
CALL &Potentiometer2
}

Var 2821, name New_LOC

Var 1875, name Pot2

Var 8570, name Value_Calc2, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot2 * 2.731
&Calc2 = L0
CALL &Position2
}

Var 3765, name Calc2 // Calculation holding variable

Var 1726, name Position2, Link SUBRUTINE // The Calculations for driving the motor
{
IF &Calc2 > &New_LOC
{
&Motor_5 = 190
}
ELSE
{
IF &Calc2 < &New_LOC
{
&Motor_5 = 85
}
ELSE
{
IF &Calc2 = &New_LOC
{
&Motor_5 = 128
}
}
}
}

File 2, Glideslope:


Var 0, Value 0
{
&Motor_1 = 120
IF &Motor_1 = 120
{
&Motor_1 = 250
}
}

Var 53 link FSUIPC_IN Length 1 Offset $023A // seconds of FS time (0 - 59)
{
IF &New_GS = 119
{
IF &GS_Flag = 0
{
&New_GS = 0
}
}
}

Var 0005, name GS_Flag, Link FSUIPC_IN, Offset $0C4C, Length 1 // FSUIPC GS FLAG Source

Var 0866, name GS, Link FSUIPC_IN, Offset $0C49, Length 1, Type 1 // FSUIPC GS Source
{
L0 = &GS + 119
&New_GS = L0
}

Var 97, name Potentiometer, Link SUBRUTINE
{
L0 = &Pot_Orig * -1
L0 = L0 + 171
&Pot = L0
CALL &Value_Calc
}

Var 1, name Motor_1, Link USB_DCMOTOR, Output 1 // Motor

Var 58, name Pot_Orig, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 250 // Potentiometer
{
CALL &Potentiometer
}

Var 9991, name New_GS

Var 8754, name Pot

Var 3, name Value_Calc, Link SUBRUTINE // Provides a scale between GS and Pot
{
L0 = &Pot * 3.260
&Calc = L0
CALL &Position
}

Var 30, name Calc // Calculation holding variable

Var 2, name Position, Link SUBRUTINE // The Calculations for driving the motor
{
IF &Calc > &New_GS
{
&Motor_1 = 250
}
ELSE
{
IF &Calc < &New_GS
{
&Motor_1 = 120
}
ELSE
{
IF &Calc = &New_GS
{
&Motor_1 = 128
}
}
}
}

As you can see, nothing is wrong. You can even try it yourself; seperately they compile, but not together - And there are no variable name clashes.

Regards,

Jack

[kiek]

Hi Jack,
I have good and bad news...

The bad news first:
It looks like Config_SIOC 'gets confused' while combining the two Var 0 codes. Normaly one only writes simple assignments in var 0 , not the IF statements you wrote. So maybe the Config_SIOC compiler is not capable of doing that (a bug I gues).

The good news:
When I had a look at your Var 0 code, I was wondering why you first give the motor a value and then test whether the motor has that value... Is not that always the case? I have simplified the glideslope part into:



Var 0, Value 0
{
&Motor_1 = 250
}


and the localiser part into:


Var 0, Value 0
{
&Motor_5 = 250
}


and then it compiles OK!

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I appreciate the Var 0 logic is confusing, allow me to explain.

At startup, SIOC does not know the value of the potentiometers (because they have not changed).

So, the Var 0 logic moves the motors one way, and then moves them the other way.

This changes the Potentiometer vars, allowing SIOC to get their values. Otherwise, SIOC does not know the Potentiometer values and the motors just stay still, as no further logic is executed.

Unfortunately, I cannot use your style of logic (ie JUST "motor = 250" or "motor = 120"). This is because, for example, if the Localiser motor was all the way to the left, and we tell it to move 120 (ie to the left some more), it will obvious not be able to move any more.

If you can think of a better way to read the Potentiometer values at startup that would be great.

Cheers,

Jack

[kiek]

Jak,
I do not understand, sorry (I have no experience with reading pot meters).
I recommend to combine these two files manually into one localiser_glideslope file, in order to program around the Config_SIOC bug.
And please report this bug to Opencockpits.

Regards,
Nico

[kiek]

Hi Jack,
Here a better idea. I have put the init code in a separate routine called from Var 0. Now the compiler does not get confused...



Var 0, Value 0
{
CALL &Init1
}

Var 52 name Init1 Link SUBRUTINE
{
&Motor_1 = 120
IF &Motor_1 = 120
{
&Motor_1 = 250
}
}


and



Var 0, Value 0
{
CALL &Init2
}

Var 7500 name Init2 Link SUBRUTINE
{
&Motor_5 = 120
IF &Motor_5 = 120
{
&Motor_5 = 250
}
}



Nico

[Boeing 747 Flyer]

Hi Nico,

So sorry that I did not see your new post until now.

The Subroutine is a great idea; I shall implement it ASAP.

Regards,

Jack