Scaling Localiser and Glideslope Needles for HSI

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

regards,
Nico Kaan

Jack

Glad you got there in the end

David

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

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

Rob

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:

Code:

---

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

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

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

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

Hi Nico,

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

Jack

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:

Code:

---

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:

Code:

---

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

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:

Code:

---

Var 0, Value 0
{
  &Motor_1 = 250
}

---

and the localiser part into:

Code:

---

Var 0, Value 0
{
  &Motor_5 = 250
}

---

and then it compiles OK!

regards,
Nico

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

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

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...

Code:

---

Var 0, Value 0
{
  CALL &Init1
}

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

---

and

Code:

---

Var 0, Value 0
{
  CALL &Init2
}

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

---

Nico

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