HSI Pulse Range Counter Display - How to manipulate in SIOC?

[Boeing 747 Flyer]

Hi everyone,

Whilst I have, for now, gotten the flags and course pointer on my HSI to work (there's still the remaining motors left though!), I'm currently working on a logic for the HSI pulse counter.

Basically, my HSI display works like a heartbeat. I have an "engage pin" connected to the display, and when 5V is going to this pin, I send pulses (ON/OFF/ON/OFF) to the display.

Each routine of OFF/ON/OFF counts as one pulse, and counts the display up by 1.

Previously, I have been using Nico's LED blink script to simulate this, executed by a button press.

Obviously, I cannot rely on this alone, as in FSX, this value is changed by the disstance from the VOR1 station (tuned).

My friend Mikael Stockfors has very kindly designed a logic for the range display, which certainly looks like it could work. Please analyse the logic (NOTE, is is NOT formatted to work with SIOC yet, it is just a visual draft to show how things work):


"VAR 1, name CurrentDistance"
"VAR 2, name NewDistance, LINK (FSUIPC output source)"
{
L0 = NewDistance - CurrentDistance;

IF L0 > 0 THEN
{
Set output to make counter count UP; // Pulses make the counter go UP
NoPulses = L0;
}
ELSE
{
Set output to make counter cound DOWN; // Same technique, except the pulses count DOWN, due to an
// extra pin which can change the UP to a DOWN count
NoPulses = L0

}

Send NoPulses to the range display; // One pulse = 1 digit count

CurrentDistance = NewDistance;

}

My question is, how can I accurately control the number of pulses outputted by SIOC, and is there a better way than just using an LED blink script? EG, if I want 5 pulses, I just want to send 5 pulses straight to the display. Is there a better way to achieve this goal?

Kindest regards,

Jack

[kiek]

Jack,
What is the "length" of one pulse? I mean, how many milli seconds do you need for each cycle? Or in other words: the time between two ON's ?

Nico

[Boeing 747 Flyer]

Hi Nico,

I think 100 milli-secs would do (that's 10 pulses per second).

Kindest regards,

Jack

[kiek]

Hi Jack,
I have not checked this code, i'm not sure whether SIOC allows recursive calls of subroutines, but I don't see why not.

The idea is to call the subroutine Pulses with the number of pulses that you want to send.


Var 100 name Main
{
&Out = 0
L0 = 3 // 3 is just an example
CALL &Pulses L0 // generate L0 number of pulses
}

Var 1 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 2 name PulseDown
{
L0 = &PulseDown
IF L0 > 0 {
&Out = 0
&Finish = DELAY L0 5 // 50 msec for the other half of the pulse
}
}

Var 3 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 4 name Out link ... pulse train here


An alternative is the TIMER approach. One way or the other you need to build in wait periods in your script. In the example above I do that with the DELAY statement. Note that a SIOC program immediately continues with the statement after the DELAY statement (if present), that's why I needed three different Vars to send a pulse.

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

That is superb! Thanks so much! Thanks for helping me out at such short notice; it is really fantastic =).

It is 11:00PM here, so I shall double-check the code tomorrow. However, I have read through it and can understand how it works. The line "L0 = 3"; as you say 3 is an example. As "3" could theoretically be any number, wouldn't it be better to make L0 equal to another variable specifically designed for the pulse value (ie L0 = X, where X is the number of pulses).

Thank you so much, I am so grateful for your help.

Regards,

Jack

[kiek]

Jack,
Like I said, L0 = 3 is just an example. L0 = &NoPulses is also possible.

If this subroutine works you should also be careful not to call it too often because sending a large number of pulses would take some time.

Maybe you should use the endless timer approach (http://www.lekseecon.nl/howto.html#endless). In the control routine you check the NewDistance - CurrentDistance and act accordingly. If the number of pulses to be sent is too much for the control cycle period, you maximise the amount to what is possible and take care of the rest in the next control cycle.

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I shall consider the endless timer approach should we need to use it for the range display in the future.

I have now taken your script, replaced "3" with NoPulses.

Firstly, this is the script that calculates NoPulses (all finished now):


Var 1, name CurrentDistance

Var 4, name NoPulses

Var 3, name UP_Pin, Link IOCARDS_OUT, Output X

Var 5, name DOWN_Pin, Link IOCARDS_OUT, Output X

Var 2, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source
{
L0 = NewDistance - CurrentDistance
IF L0 > 0 THEN
{
&DOWN_Pin = 0 // Ensure down pin is OFF
&UP_Pin = 1 // Pulses make the counter go UP
NoPulses = L0
}
ELSE
{
&UP_Pin = 0 // We don't want to count up here!
&DOWN_Pin = 1// ...But we need to count down, so DOWN pin is ON
&NoPulses = L0 * -1
}
CurrentDistance = NewDistance
}

Please note: The "Up" and "Down" pins are extra outputs that must be activated in order to provide a pulse. They receive no actual pulses themselves and don't do anything else.

This is your script, adapted slightly to work with the above:


Var 100 name Main
{
&Out = 0
L0 = NoPulses // 3 is just an example
CALL &Pulses L0 // generate L0 number of pulses
}

Var 1 name Pulses link SUBROUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 2 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY &PulseDown 5 // 50 msec for the other half of the pulse
}
}

Var 3 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 4, name &Out, Link IOCARDS_OUT, Output X

Obviously, the "X"s in each script will be replaced with a correct working output number.

So, as it stands, can you see any obvious errors? I just use the first to calculate the pulses, and your script to send them.

At the moment, the script(s) don't cater for when you loose the VOR1 signal or something else like that happens; but that's okay for now, it's just a test.

Thanks very much for your time.

Kindest regards,

Jack

[kiek]

Hi Jack,

I think it is better to integrate the two scripts.
We need a Var 0 with some initialisations, and in the NewDistance var we have to call the Pulses subroutine.
In this example there is no need for a NoPulses variable.

Maybe you should test this first. I'm not sure about the value in FSUIPC offset 0x0300, the documentation says nm * 10 ...
Let's see what happens.



Var 0 Value 0
{
&Out = 0
&CurrentDistance = 0 // ??
}

Var 1, name CurrentDistance

Var 2, name UP_Pin, Link IOCARDS_OUT, Output X

Var 3, name DOWN_Pin, Link IOCARDS_OUT, Output X

Var 4, name &Out, Link IOCARDS_OUT, Output X

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source
{
L0 = &NewDistance - &CurrentDistance
&CurrentDistance = &NewDistance
IF L0 <> 0
{
IF L0 > 0
{
&DOWN_Pin = 0 // Ensure down pin is OFF
&UP_Pin = 1 // Pulses make the counter go UP
}
ELSE
{
&UP_Pin = 0 // We don't want to count up here!
&DOWN_Pin = 1 // ...But we need to count down, so DOWN pin is ON
L0 = L0 * -1
}
CALL &Pulses L0
}
}

Var 10 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 11 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY L0 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}


Nico

[kiek]

Jack,
Here is the endless timer approach.
I believe this script is much more robust.



Var 0 Value 0
{
&Out = 0
&CurrentDistance = 0
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
L0 = NewDistance - CurrentDistance
IF L0 <> 0
{
IF L0 > 0
{
&DOWN_Pin = 0 // Ensure down pin is OFF
&UP_Pin = 1 // Pulses make the counter go UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentDistance = &CurrentDistance + 9
}
ELSE
{
&CurrentDistance = &NewDistance
}
}
ELSE
{
&UP_Pin = 0 // We don't want to count up here!
&DOWN_Pin = 1 // ...But we need to count down, so DOWN pin is ON
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentDistance = &CurrentDistance - 9
}
ELSE
{
&CurrentDistance = &NewDistance
}
}
CALL &Pulses L0
}
}

Var 1, name CurrentDistance

Var 2, name UP_Pin, Link IOCARDS_OUT, Output X

Var 3, name DOWN_Pin, Link IOCARDS_OUT, Output X

Var 4, name Out, Link IOCARDS_OUT, Output X

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 10 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 11 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY L0 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}



Nico

[Boeing 747 Flyer]

Hi Nico,

Thanks so much for your help, I'll try the endless timer script (hopefully tonight).

About the Offset * 10...

At first, I thought I'd have to divide this offset by 10 to use it "sensibly". However, it turns out the the range display on the HSI as a dot between the 3rd and 4th digits (like a decimal point).

So, therefore, if I'm 33.3nm away from the station, FSUIPC/SIOC will recognised this as "333" nm, and send 333 pulses. The HSI will then read 333, but because of the DP, it will actually read "33.3".

See what I mean? Or is it better to leave this out?

Regards,

Jack

[kiek]

Jack,
I understand. Leave it as it is.
Regards,
Nico

[kiek]

Jack,
I have tested the Pulses Subrutine with a led. Works like a charm
Nico

[Boeing 747 Flyer]

Hi Nico,

Thanks so much for testing with an LED BTW.

I have good news! Whilst there are some problems, the HSI display works most of the time, accurately representing the distance (eg 1.6 nm appears as "16", but it's actually 1.6 because of the DP).

The problem was, that when the HSI counted to 16, I flew towards the VOR station. The value counted down, as it should, but stopped at 0.4. Then, when I flew over the VOR station, and the distance started to increase again, the HSI value remained stuck at 0.4nm.

One thing, I had to change the script slightly. The "UP" and "DOWN" Pins I mentioned are infact the same pin. +5V to the pin (ON) means that it counts up, whilst 0V (OFF) to the pin makes the display count down.

This is the script; identical, just for that minor change:


Var 0 Value 0
{
&Out = 0
&CurrentD = 0
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 > 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 10 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 11 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY &PulseDown 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

However, I am extremely impressed by your script. I am surprised I have got it working at all, so when FSX read 1.6, and the HSI read 1.6, I was very, very pleased.

One thing; when using the script, SIOC seems to activate output 28 (unrelated) when it is counting up. There is a RESET pin on the pulse meter, which, if tampered with, can seriously affect the pulse. Is it possible SIOC is accidently activating this output, just like 28?

Kindest regards,

Jack

[kiek]

Hi Jack,
We're making progress!

I see you have removed the IF L0 <> 0 test in Var 100.... that's not right, now if L0 = 0 you try to count down...

And no, it's not very likely that the SIOC script changes Output 28. That output is not mentioned at all, is it? Are you sure you have no short-circuits in your hardware?

regards,

Nico

[Boeing 747 Flyer]

Hi Nico,

I have changed the script back to the <>; so now it's the same just with that one alteration.

This is what I did this time:

- Started a flight

- Started SIOC

- VOR1 DME = Out of range

- I then tune 116:00, VOR1 DME = 1.6nm away

- The range counter went to 1.4

- I changed back to the "0" range frequency, it went down to 2 (or something like that; not 0)

Weirdly, this is what the IOCPConsole log states:


5=0 - New Distance
5 = 16 New Distance
5 = 15 New Distance
5 = 14 New Distance

... And so on, as I fly towards it.

As you can see, even though "New Distance" changes; no other var at all changes.

Regards,

Jack

[Boeing 747 Flyer]

Hi Nico,

To add to my last post, here is the full IOCPConsole Log:


5=9 - NewDistance
2=1 - UPDOWN_Pin
1=9 - CurrentD
10=9 - Pulses
11=9 - PulseDown
4=0 - Out
12=9 - Finish
10=8 - Pulses
4=1 - Out
11=8 - PulseDown
4=0 - Out
12=8 - Finish
10=7 - Pulses
4=1 - Out
11=7 - PulseDown
4=0 - Out
12=7 - Finish
10=6 - Pulses
4=1 - Out
11=6 - PulseDown
4=0 - Out
12=6 - Finish
10=5 - Pulses
4=1 - Out
11=5 - PulseDown
4=0 - Out
12=5 - Finish
10=4 - Pulses
4=1 - Out
11=4 - PulseDown
4=0 - Out
12=4 - Finish
10=3 - Pulses
4=1 - Out
11=3 - PulseDown
4=0 - Out
12=3 - Finish
10=2 - Pulses
4=1 - Out
11=2 - PulseDown
4=0 - Out
12=2 - Finish
10=1 - Pulses
4=1 - Out
11=1 - PulseDown
4=0 - Out
12=1 - Finish
11=0 - PulseDown
12=0 - Finish
2=0 - UPDOWN_Pin
10=0 - Pulses
4=1 - Out
5=8 - NewDistance
2=1 - UPDOWN_Pin
1=8 - CurrentD
10=-1 - Pulses
11=-1 - PulseDown
2=0 - UPDOWN_Pin
10=0 - Pulses
11=0 - PulseDown
5=7 - NewDistance
2=1 - UPDOWN_Pin
1=7 - CurrentD
10=-1 - Pulses
11=-1 - PulseDown
2=0 - UPDOWN_Pin
10=0 - Pulses
11=0 - PulseDown
5=6 - NewDistance
2=1 - UPDOWN_Pin
1=6 - CurrentD
10=-1 - Pulses
11=-1 - PulseDown
2=0 - UPDOWN_Pin
10=0 - Pulses
11=0 - PulseDown
5=0 - NewDistance
2=1 - UPDOWN_Pin
1=0 - CurrentD
10=-6 - Pulses
11=-6 - PulseDown
2=0 - UPDOWN_Pin
10=0 - Pulses
11=0 - PulseDown
5=6 - NewDistance
2=1 - UPDOWN_Pin
1=6 - CurrentD
10=6 - Pulses
11=6 - PulseDown
4=0 - Out
12=6 - Finish
10=5 - Pulses
4=1 - Out
11=5 - PulseDown
4=0 - Out
12=5 - Finish
10=4 - Pulses
4=1 - Out
11=4 - PulseDown
4=0 - Out
12=4 - Finish
10=3 - Pulses
4=1 - Out
11=3 - PulseDown
4=0 - Out
12=3 - Finish
10=2 - Pulses
4=1 - Out
11=2 - PulseDown
4=0 - Out
12=2 - Finish
10=1 - Pulses
4=1 - Out
11=1 - PulseDown
4=0 - Out
12=1 - Finish
11=0 - PulseDown
12=0 - Finish
2=0 - UPDOWN_Pin
10=0 - Pulses
4=1 - Out
5=5 - NewDistance
5=6 - NewDistance
5=7 - NewDistance
5=8 - NewDistance

Generally, the script did not give the correct values. Also, the last 5 lines are strange; distance changes but nothing else.

kindest regards,

Jack

[kiek]

Hi Jack,
I have no experience with IOCPConsole, never work with it.

I recommend to build it up from the ground up with small steps.
We know that the Pulses SUBRUTINE is ok.
So first make a script that sends say 5 pulses to your HSI and count UP, then do the same counting down. Check the correct working of that first.

If that's OK, do some tests with the NewDistance variable.

If that's ok bring in the control routine without the test about sending more then 9 pulses.
If that's ok maximise the number of pulses sent in a control cycle.

and so on...

Such an approach gives a lot more insight then "staring at a IOCPlog file...." ;-)

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I'm so sorry; I couldn't quite understand that.

Do you mean a script with JUST the pulse subroutine on its own? Maybe linked to a pushbutton or something? Because that subroutine on its own doesn't do anything unless it's used with the other variables in the script.

Kindest regards,

Jack

[kiek]

Jack,


Do you mean a script with JUST the pulse subroutine on its own? Maybe linked to a pushbutton or something?
Yes indeed. Or called from Var 0.
And "connected" via Outputs to your HSI.

Like I did when I tested the Pulses subrutine with a led.

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

How is this:


Var 2 name Trigger Link IOCARD_IN Input 25
{
IF &Trigger = 1
{
CALL &Pulses
}
}

Var 1 name Pulses link SUBROUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 3 name Out Link IOCARD_OUT Output 29 // Pulse Pin

Var 11 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY &PulseDown 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

I couldn't isolate the Pulses var because it relies on the "Pulsedown" var, which is further linked to the finish var.

Regards,

Jack

[kiek]

Hi Jack,
Almost correct...


Your script lacks a parameter to the CALL of &Pulses ... You should write CALL &Pulses 5 or whatever the number you want to test.
And you should add Up or Down counting in Var 2, before you call &Pulses.


BTW: Pulses, PulseDown and Finish belong together. You cannot and should not isolate Pulses.

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I used the following script; using two different pushbuttons for counting UP and DOWN. Each button produced exactly 10 pulses.


Var 2 name Trigger Link IOCARD_SW Input 25
{
IF &Trigger = 1
{
&UPDOWN_Pin = 1
CALL &Pulses 10
}
}

Var 8 name Trigger2 Link IOCARD_SW Input 19
{
IF &Trigger2 = 1
{
&UPDOWN_Pin = 0
CALL &Pulses 10
}
}

Var 1 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 3 name Out Link IOCARD_OUT Output 29 // Pulse Pin

Var 11 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY &PulseDown 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 55, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

I did the following test:

(Button X = UP, Y = DOWN)

- Pressed button X twice, HSI went to 20

- Press button Y once, HSI went to 11

- Pressed X once, went to 21

I reset the HSI using the reset pin.

- I pressed X once, went to 10

- Pressed Y once, went to 0

- Pressed X twice, went to 20

- Pressed Y once, went to 12

As you can see, it more or less goes up by exactly 10 each time. There is, however, a noticeable small margin of error counting down sometimes.

EDIT: After looking closely at the HSI display, I can confirm that when giving the first 10 pulses, the HSI display goes:

0000, 9999, 9998, 9999, 0000, 0001, 0002, 0003... Up to 0008

As you an see, the display goes DOWN by 2 values before counting 10 up... Which may explain the "lag" by 2 in pulses (explained in the above tests).

Also, I have found out that the display cannot be given two instructions at once. EG: If told to go up by 10 pulses, it MUST finish receiving 10 pulses before doing anything else. If told to go up by 10, and then 15, whilst it is still counting to 10, it will not go up by either 10 or 15 and get "confused".

Regards,

Jack

[Boeing 747 Flyer]

Hi Nico,

I tried the DME_Full script again and frequently replicated the same problem.

Although, after tuning a VOR station that was 1.6nm away, the HSI showed 16 (1.6); it would never count down.

This is what IOCPConsole shows, after changing from 16 -> 15 (I have written it in the format you prefer). The following is listed in chronological order, it just tells you the value of each var as time goes on. The following all happened in about 5 seconds.

- New Distance = 15

- UPDOWN Pin = 1 (so as if we're going to count up??? Why?)

- CurrentD = 15

- Pulses = -1

- PulseDown = -1

- UPDOWN Pin = 0 (that's better, we can count down now)

- Pulses = 0

- PulseDown = 0

END

My concern is that SIOC is trying to do all the pulsing BEFORE it sets the UPDOWN_Pin to 0. Obviously, it cannot count down until this is set properly. Also, why is the pulses value -1? We can't have a -1 pulse?

Regards,

Jack

[kiek]

Hi Jack,


I tried the DME_Full script again and frequently replicated the same problem.

It's too early run the full script. Your basic test, sending pulses does not work correctly yet as you have reported in post #22.
First things first.

Nico

[kiek]

Jack,


As you an see, the display goes DOWN by 2 values before counting 10 up... Which may explain the "lag" by 2 in pulses (explained in the above tests).

You have to find out why this is. Maybe you need to build in some time between &UPDownPin = 1 and the Call of &Pulses?
Use 1 push button (Type P) to set the UPDOWN pin (according to the position of the button) . Use the other button to start the CALL of &Pulses 10



Also, I have found out that the display cannot be given two instructions at once. EG: If told to go up by 10 pulses, it MUST finish receiving 10 pulses before doing anything else. If told to go up by 10, and then 15, whilst it is still counting to 10, it will not go up by either 10 or 15 and get "confused".

Good to know. In my control script this will not happen because it only generates a number of pulses per control cycle, either up or down. But maybe, see also my first comment, we need more delay.

Again: make this procedure (sending up/down pulses) 100% reliable before continuing...
regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I have now finally figured out how to get a consistent value "10" on the HSI every time, without an erraneous results.

Basically, the pulse must START on 5V, and end on 5V. For example to count from 0-10:

- ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON, OFF, ON,

That's 11 "ONs" and 10 "OFFs". Doing this sequence consistantly gets 10 values exactly each time. The identical logic applies for counting down; you must START with 5V and END with 5V (with 11 ons and 10 offs).

I cannot seem to get a consistent enough result starting with an OFF.

In other words, all pulses must start with ON, and end with ON. If a pulse is finished with OFF, and starts with ON, then this in itself counts as a pulse and will give one extra value we don't need.

PS: All information was recorded using the following script:


Var 99 name Trigger3 Link IOCARD_SW Input 18 Type P
{
IF &Trigger3 = 1
{
&UPDOWN_Pin = 1
}
}

Var 98 name Trigger4 Link IOCARD_SW Input 23 Type P
{
IF &Trigger4 = 1
{
&UPDOWN_Pin = 0
}
}

Var 2 name Trigger Link IOCARD_SW Input 25 Type P
{
IF &Trigger = 1
{
CALL &Pulses 10
}
}

Var 1 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 1
&PulseDown = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 3 name Out Link IOCARD_OUT Output 29 // Pulse Pin

Var 11 name PulseDown
{
L0 = &PulseDown
IF L0 > 0
{
&Out = 0
&Finish = DELAY &PulseDown 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseDown = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 55, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

On its own, the script didn't work. So, I opened up controlador.exe and manually provided the pulses, and it worked exactly as described above.

Regards,

Jack

[kiek]

Hi Jack,
Good work.

I have changed the subrutine Pulses such that in 'rest' Out will be 1. Also added a Var 0 in order to be able to start with Out = 1




Var 0 Value 0
{
&Out = 1
}

Var 99 name Trigger3 Link IOCARD_SW Input 18 Type P
{
IF &Trigger3 = 1
{
&UPDOWN_Pin = 1
}
}

Var 98 name Trigger4 Link IOCARD_SW Input 23 Type P
{
IF &Trigger4 = 1
{
&UPDOWN_Pin = 0
}
}

Var 2 name Trigger Link IOCARD_SW Input 25 Type P
{
IF &Trigger = 1
{
CALL &Pulses 10
}
}

Var 1 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 3 name Out Link IOCARD_OUT Output 29 // Pulse Pin

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 55, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin


Regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

Great news! That script ensures that it goes up EXACTLY by 10 or down by 10 each time. The trick seems to be starting on 5V and ending on 5V.

There is just one problem. As you know, as SIOC is started it resets all outputs connected to the mastercard.

Var 0 turns the range display to 5V. So, in other words, the range display = 0 for a very, very short time, before var 0 sets it to 5V. This very short OFF/On sequence, even if it is for a billionth of a second, counts as a pulse, so the HSI display counts down one.

We need to get rid of this initial OFF/ON pulse.

Also, some more good news: the script even works when transitioning from an UP to a DOWN count EG: 10-20, then back down to 10 is no problem.

Regards,

Jack

[kiek]

Hi Jack,


We need to get rid of this initial OFF/ON pulse.


Well, change Var 0 to this:


Var 0 Value 0
{
&Out = 1
&UPDOWN_Pin = 0 // count down
CALL &Pulses 1 // correct for first OFF/ON pulse at startup
}


regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

Fantastic news! We have bypassed stage 1. All is working!

I did, however, have to change the script slightly. Firstly, the error was a DOWN pulse (it went from 0 to 9999) so the UPDOWN_Pin had to be 1. Secondly, and I don't know why, &Pulses must be called TWICE to compensate for the error:


Var 0 Value 0
{
&Out = 1
&UPDOWN_Pin = 1 // count down
CALL &Pulses 2 // correct for first OFF/ON pulse at startup
}

Var 99 name Trigger3 Link IOCARD_SW Input 18 Type P
{
IF &Trigger3 = 1
{
&UPDOWN_Pin = 1
}
}

Var 98 name Trigger4 Link IOCARD_SW Input 23 Type P
{
IF &Trigger4 = 1
{
&UPDOWN_Pin = 0
}
}

Var 2 name Trigger Link IOCARD_SW Input 25 Type P
{
IF &Trigger = 1
{
CALL &Pulses 10
}
}

Var 1 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 3 name Out Link IOCARD_OUT Output 29 // Pulse Pin

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 55, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Anyway, I tested it many times, and no matter how hard I tried, I could not get the display to go wrong. It always count up or down 10; exactly how I wanted it.

Woohoo!

Jack

[Boeing 747 Flyer]

Hi Nico,

More great news!

I have now, using the following script, managed to initiate and UP or DOWN pulse from just 2 buttons. Previously, we had to use 3, with the third button controlling the UPDOWN_Pin Output. Now, however, this is done automatically upon pressing the button.

This proves that an UP/DOWN count can be initiated immediately upon being commanded to do so, without needing to set the UP/DOWN Pin through some other instruction.

Code:


Var 0 Value 0
{
&Out = 1
&UPDOWN_Pin = 1 // count down
CALL &Pulses 2 // correct for first OFF/ON pulse at startup
}

Var 99 name Trigger3 Link IOCARD_SW Input 18 Type P
{
IF &Trigger3 = 1
{
&UPDOWN_Pin = 1
CALL &Pulses 10
}
}

Var 98 name Trigger4 Link IOCARD_SW Input 23 Type P
{
IF &Trigger4 = 1
{
&UPDOWN_Pin = 0
CALL &Pulses 10
}
}

Var 1 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 3 name Out Link IOCARD_OUT Output 29 // Pulse Pin

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 55, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

Kindest regards,

Jack

[kiek]

Hi Jack,
Understood. Just change in Var 0:


&UPDOWN_Pin = 1 // count down

into


&UPDOWN_Pin = 1 // count up

Programmers often forget to update the commentary parts when they change their code.

Regards,
Nico

P.S. Some people even state that it is better not to comment at all. They claim that it is better to have no comment then a wrong comment... ;-)

[Boeing 747 Flyer]

Hi Nico,

All done! What's next on the agenda?:D

Jack

[Boeing 747 Flyer]

Hi Nico,

What should I do next? Should I just try and implement the (new) pulse code into the full script, or should I do some more testing (ie: one step at a time) before I run the full thing?

Kindest regards,

Jack

[kiek]

Hi Jack,

I would first run a test script with just the NewDistance offset (so no Pulses routine at all).
Fly to, over and past a VOR and write the NewDistance value to a 3 digit display.
This will give you information upon which you can base the Control algorithm

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I have tried that, watching the value of the VOR1 DME change according to offset $0300.

It does indeed work perfectly, so no problems with this offset.

Regards,

Jack

[kiek]

Hi Jack,
If you are sure about the values coming from NewDistance then try the complete Control script from posts #13 and #14, adapted with the 'inverted Pulses code' and the Var 0 code of post #31

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

How is this:


Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
&UPDOWN_Pin = 1 // count up
CALL &Pulses 1 // correct for first OFF/ON pulse at startup
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

If you can see anything wrong please tell me and I shall correct it right away.

Kindest regards,

Jack

[Boeing 747 Flyer]

Hi Nico,

I have tested the new pulses script.

Firstly, for some reason, &pulses must now only be called ONCE instead of TWICE at startup.

This is the exact script I am using:


Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
&UPDOWN_Pin = 1 // count up
CALL &Pulses 1 // correct for first OFF/ON pulse at startup
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

The problem is not the pulsing script at all; it is the calculation for the pulses.

For some reason, after setting a VOR station that is 1.6 miles away (16 pulses), the HSI only went up to 0.9 (9 pulses). Also, when I tuned a non-existant VOR station (in other words, "0" miles away), the script did not count down. So, to summarize, the problems are:

- Script does not count up enough

- Script does not count down at all

The NewDistance variable changes value accordingly, but the rest of the script does not function correctly. It looks fine to myself, and I cannot see what particular bit is casuing the issue.

Just to reiterate, it is no longer a pulsing issue - That works fine. It is the calculation to calculate the number of pulses.

Regards,

Jack

[kiek]

Hi Jack,

Two problems:
You miss a test on L0 > 0 in Var 100.
The pulse correction in Var 0 must be done before calling control. Maybe you need 2 again now...

Here is the updated script, please test again:


Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&UPDOWN_Pin = 1 // count up
CALL &Pulses 2 // correct for two OFF/ON pulse at startup
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
IF L0 > 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag


regards,
Nico

[kiek]

Hi Jack,
I have modified Var 0 start up a little to be sure that the two pulses in Var0 have been processed before we start de Control loop...



Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&UPDOWN_Pin = 1 // count up
CALL &Pulses 2 // correct for two OFF/ON pulse at startup
&StartControl = DELAY 1 100 // wait a second to let two pulses above happen first
}

Var 9999 name StartControl
{
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
IF L0 > 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag


Nico

[Boeing 747 Flyer]

Hi Nico,

A bit of good news, but we're still not quite there.

Firstly, I can confirm that still only 1 pulse is needed at startup instead of 2 (but I still need 2 if I'm doing the "switch test" script).

Anyway, I tuned a VOR station 1.6nm (16 pulses) away. The HSI went to 1.4, again, not bad, very close. I then tuned back to a "dead" frequency (which means "0" on the NewDistance variable) and it went perfectly back to 0.

So in other words, the HSI did not count up 16, but it did not count 16 down either (14 up and 14 down).

Then, I approached the VOR slowly. It was always off by 0.2, but it went down in perfect increments, so clearly the script is working somewhat correctly.

I then tuned a station 51.7 nm away. The HSI only went to 15, not 15.7 (157) pulses. I think this is a script fault, not hardware, as IOCPConsole reported only a few pulses sent; definitely not 517.

This was the script, same as yours, just CALL &Pulses 1, not 2:


Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&UPDOWN_Pin = 1 // count up
CALL &Pulses 1 // correct for two OFF/ON pulse at startup
&StartControl = DELAY 1 100 // wait a second to let two pulses above happen first
}

Var 9999 name StartControl
{
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
IF L0 > 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 9 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 9 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

I also remember at the start of this thread our original script used a variable called "NoPulses". We seem to have substitued this for L0.

Also, on another note, at the end of my test, the NewDistance variable changed value 5 times but not a single pulse was sent. Weird!

Regards,

Jack;)

[kiek]

Hi Jack,

I have simplified the Control routine a bit. Don't think it will make a difference but it is less code.

However, I also changed the PulseUp and PulseDown delays to 5 (instead of 9) equals 50 msec for half a pulse.

Originally I used 5, don't know why you have changed that to 9???

9 pulses of 90+90 = 9 x 180 msec is more then a second delay so that will not work... These max. 9 pulses per control cycle must fit within 1 second because then the next call to the control routine starts... (do you understand?)

Here the improved script:



Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&UPDOWN_Pin = 1 // count up
CALL &Pulses 1 // correct for two OFF/ON pulse at startup
&StartControl = DELAY 1 100 // wait a second to let two pulses above happen first
}

Var 9999 name StartControl
{
&Control = 0
&Control = TIMER 1 0 100 // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
IF L0 > 0
{
&UPDOWN_Pin = 1 // HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
}
&CurrentD = &CurrentD + L0
}
ELSE
{
&UPDOWN_Pin = 0 // HSI counts Down
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
}
&CurrentD = &CurrentD - L0
}
CALL &Pulses L0
}
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag


regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

More good news.

Firstly, the HSI counts perfect to 0000 each time at startup.

Secondly, the HSI counted perfectly 16 pulses, and then 16 back again when I reset the distance to 0.

One thing that is weird; the HSI actually counts DOWN 16 pulses from 0 (to 9984), and then down another 16 when I reset to 0. Resetting the display fixes this issue, but it is strange, especially because UPDOWN_Pin = 1 in the script.

Also, I tuned the station 51.7nm away. Unfortunately, it only got to 54 (5.4 nm) before stopping. I also noticed that it counted up in perfect blocks of 9 as you said, and 54 is 9 X 6 (so maybe 6 is a "limit" or something? I don't know, guessing here).

This is real progress though!

Regards,

Jack

[kiek]

Jack,
What happens if you fly over that VOR at 1.6 nm?
Nico

[Boeing 747 Flyer]

Hi Nico,

Sorry for my late reply.

I just conducted the following test...

- Tuned VOR 1.6 nm away.

- Went 1.7nm away

- Went 1.6, 1.5, 1.4, 1.3...

- Down to 0.5, then I went back to 0.7nm

- Then, from 0.7nm, 0.5, 0.4, 0.3...

- Down to 0. Then, I went back up to 0.7

- I then dis-tuned the VOR. (aka "0")

UP TO THIS POINT, the HSI performed absolutely brilliantly; not a single error. Then...

- Retuned VOR, which was 1.2nm away.

- HSI went to 0.6

- NewDistance increased as aI flew away. 1.3, 1.4, 1.5, 1.6, 1.7...

- The HSI stayed locked on 0.6

After studying IOCPConsole it is clear two things:

- Firstly, the HSI did not count back up correctly from 0 to 1.2

- Secondly, The NewDistance Var changed 5 times and the HSI did not receive a single pulse.

I hope these results help, but it was awesome up to 1.7 -> 0 -> 0.7 -> 0, not a single error!

Regards,

Jack

[kiek]

Jack,
I really have no idea at the moment. Try some more tests and try to detect a common pattern.
It looks as if the Control routine stopped...
Are you sure SIOC is still running at the end of your test (check the SIOC main window)?

regards,
Nico

[Boeing 747 Flyer]

HI Nico,

I can confirm that SIOC is still running.

How is it even possible for the Timer to stop? I mean, surely, if it is aleady running, then SIOC must purposely give a command to stop it. If so, why?

Regards,

Jack

[kiek]

Hi Jack,


How is it even possible for the Timer to stop?

If you look at the script that is very unlikely if not impossible (it is an endless timer), but it could have stopped due to a bug in the SIOC implementation...
But you confirm SIOC is still running...
That is very strange however, because then the script should sent pulses ... Are you sure the script is dead (not sending any more pulses) and not your HSI?

Regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

I can confirm that IOCPConsole shows no pulses being sent.

IOCPConsole reports on everything SIOC does, and thus tells me exactly when it is sending the pulses. There is absolutely no reaction when the NewDistance variable changes in SIOC.

If it was a HSI fault, IOCPConsole would show pulses being sent, but the HSI display would remain dead.

Jack

[kiek]

Hi Jack,
Understood. So we are certain that the Pulses subroutine is no longer called because you do not see new values for PulseUp and Finish in IOCPConsole.
So we must conclude that the TIMER has stopped working ...But why?
Is it because of a bug in SIOC (I mean not in my script but in the SIOC run time)?

It would be interesting to find out exactly when the TIMER stops.
Run a few more tests with tuning VORs and flying to and over a VOR to see whether there is a "common pattern"

There is no need to change the SIOC script, it works perfectly (up and down). The only problem being that it looks as if it stops .... :-[

Regards,
Nico

[Boeing 747 Flyer]

HI Nico,

I shall run a few tests, seeing if it is a location (ie a specific distance that triggers it) or a timing (it happens after X minutes) problem.

Jack

[Boeing 747 Flyer]

Hi Nico,

I just performed some tests with some promising results.

I can 95% confirm that it is NOT the script that is faulty. Let me explain why...

Firstly, whenever the HSI did work, the Range counter performed brilliantly. I flew over, around, way past and before the VOR, the Range display kept hold of the distance perfectly all the time.

It even worked when I switched from a dead to active frequency in flight.

However, around a period of 5 minutes each time, pulses stopped being sent to the display.

The first time, I got to a distance of 10.4 miles before the display cut off.

The second time, I made sure my take-off roll was very slow. This meant that I could predict when the display would stop working (before 10.4 miles).

And, the display stopped at 9.4 miles. Just as I had thought. This means that it is definitely a TIMER issue.

Perhaps we can work out another way to repeatedly call this variable?

Regards,

Jack

[kiek]

Hi Jack,

Replace Var 9999 with this:


Var 9999 name StartControl
{
&Control = 0
&Control = TIMER 99999 1 100 // control is called each second
}

This should count longer then most flights last.

See whether this makes a difference.
regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

That was a good idea of yours, as it has revealed a fault.

I can see the control variable going up each second by 1 in IOCPConsole. At 1202, the control variable actually just stopped, and thus no further pulses were sent.

This means that SIOC (or something) is definitely stopping the TIMER variables.

Maybe we should use an FSUIPC offset to call the control variable, something like "elapsed time" or "time in GMT" (ie something that always changes). Not ideal I know.

Regards,

Jack

[kiek]

Hi Jack,
Good idea, I have changed the script such that we use the seconds of FS time.
Each second our Control routine will execute.



Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&UPDOWN_Pin = 1 // count up
CALL &Pulses 1 // correct for two OFF/ON pulse at startup
}

Var 100 link FSUIPC_IN Length 1 Offset $023A // seconds of FS time (0 - 59)
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
IF L0 > 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD + 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 9
{
L0 = 9 // no more then 9 pulses per second
&CurrentD = &CurrentD - 9
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 5 // 50 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 5 // 50 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag


It is still hard to believe that there is a bug in TIMER implementation. I know other people that use an endless timer for motor control.
Will make a call to Spain...

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

That script worked great! The HSI kept track of the distance for much, much longer than the previous.

There are, however, a few problems. Firstly, the HSI was always 2 lower than FSX (eg, if the distance was 1.5m, the HSI would be 1.3m).

If FSX = 0, then the HSI = 9998.

Also, when I tuned the VOR station that was 51.7nm away, the HSI slowly sent the pulses, but stopped at 317 miles.

Regards,

Jack

[kiek]

Hi Jack,

That two lower problem is related to the code in Var 0. We have to fine tune that. Take also into account that Var 100 is called immediately as soon as var 0 has been executed. So we have to synchronize that.

HSI slowly sent pulses: thats'by design, it synchronizes at a pace of .9 nm per second. Maye be can sent more pulses per second? I mean why to we sent pulses of .1 second?

Your report that it stopped at 317 miles worries me more... Why is that? Has the FS time stopped? Or is there a problem with the HSI?

regards,
Nico

[Boeing 747 Flyer]

HI Nico,

The FS time definitely didn't stop. IOCPConsole reports that pulses stopped being sent when the HSI value read 317.

I honestly think it would help if we increased the pulse-per-second rate. Maybe 8 times as fast or something like that.

Regards,

Jack

[kiek]

I honestly think it would help if we increased the pulse-per-second rate. Maybe 8 times as fast or something like that.

That's quite a lot more. What does the Manual of the HSI tells you? ;-)
I mean trial and error is not the most efficient way.

Here is the code for 5 times faster, max 45 pulses per second (4.5 nm per second).



Var 0 Value 0
{
&Out = 1
&CurrentD = 0
&UPDOWN_Pin = 1 // count up
CALL &Pulses 1 // correct for two OFF/ON pulse at startup
}

Var 100 link FSUIPC_IN Length 1 Offset $023A // seconds of FS time (0 - 59)
{
L0 = &NewDistance - &CurrentD
IF L0 <> 0
{
IF L0 > 0
{
&UPDOWN_Pin = 1 // Ensure HSI counts UP
IF L0 > 45
{
L0 = 45 // no more then 45 pulses per second
&CurrentD = &CurrentD + 45
}
ELSE
{
&CurrentD = &NewDistance
}
}
ELSE
{
&UPDOWN_Pin = 0 // We don't want to count up here!
L0 = L0 * -1
IF L0 > 45
{
L0 = 45 // no more then 45 pulses per second
&CurrentD = &CurrentD - 45
}
ELSE
{
&CurrentD = &NewDistance
}
}
CALL &Pulses L0
}
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2 // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE // parameter is number of pulses ...
{
&Out = 0
&PulseUp = DELAY &Pulses 1 // 10 msec for a half pulse
}

Var 11 name PulseUp
{
L0 = &PulseUp
IF L0 > 0
{
&Out = 1
&Finish = DELAY L0 1 // 10 msec for the other half of the pulse
}
}

Var 12 name Finish
{
L0 = &Finish
IF L0 > 0
{
IF L0 > 1
{
L0 = L0 - 1
CALL &Pulses L0 // recursive subroutine call
}
ELSE
{
&PulseUp = 0 // make responsive for another series of pulses.
&Finish = 0 // make responsive for another series of pulses.
}
}
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag


regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

Well what can I say. It is absolutely brilliant. Thanks so much!

Changing it to 45 pulses/sec has solved EVERYTHING. I mean everything!

Not a single error, it never stops being called, and it accruately reports the station be it 1.6 or 51.3nm away. It also perfectly resets to 0 even if I'm in the middle of flying towards the VOR and loose the signal.

There really is nothing left to fix IMO. A few problems may crop up, but there are none at the moment, it just works brilliantly.

Thanks so very, very much!

Regards,

Jack

[kiek]

Hi Jack,
CONGRATULATIONS!
Enjoy your HSI.

I will add the SIOC code of the Pulses subroutine to my howto (http://www.lekseecon.nl/howto.html)page.

Let's close this thread now. It is very long already.

regards,
Nico

[Boeing 747 Flyer]

Hi Nico,

Thanks so much, but you deserve most of the thanks for your oustanding efforts and fault-finding.

Should we submit a bug report to OC regarding the SIOC issue?

That's just the glideslope and localiser motors left to do on the HSI!

Regards,

Jack

[kiek]

Hi Jack,
I have added a HowTo example about making a led blink a fixed number of times (http://www.lekseecon.nl/howto.html#fixedblink)to my website.

Do you submit the bug report to OC?

regards,
Nico

[fordgt40]

Nico, Jack

Some interesting coding - thanks
Another application of the principles of sending pulses could be dc motor control through one of the proprietary motor control chips that act upon ttl level logic on/off signals and variable durations - could be cheaper than buying an OC card.

David

[Boeing 747 Flyer]

Hi David,

I had thought about using the PWM technology in the motors card, but it simply wasn't precise enough.

I myself had developed a little test circuit with a potentiometer, capacitor and PIC chip. If I put the potentiometer in "position X" for 10 seconds the HSI would count to 200, but if I did it again, it would count to 213, etc.

Nico's script makes sure we control the EXACT number of pulses sent, so that it never goes off track (even by 1).

Nico, just a small note:

I noticed one condition in which the script struggles. It is not our fault, but that of FSUIPC/FSX.

Whenever a frequency is changed, the Offset in question changes to 0 for a split second, then back up to whatever distance it is away.

This change to 0 affects our script, because the HSI tries to go to 0, and then back up to X miles. Obviously, as I said, sending two different instructions "confuses" the HSI.

I am wondering, if there is any way around this? Maybe to tell the HSI to "ignore" the temporary value of 0. Or, another idea, we make the pulse rate so fast, so that it does change to 0 and then back up to whatever extremely quickly (maybe 1000 pulses/sec, I don't know).

Anyway, just a minor problem. It is nothing to do with the script; just the offset by which it is governed.

Regards,

Jack

[fordgt40]

Hi Jack

I understand why you did not use PWM. I was thinking more about general (undemanding!!) motor control where the pulse system you have developed with Nico could easily control motors with inexpensive chips.

Regards

David

[Boeing 747 Flyer]

Ahhh I see, indeed!

Is there a "limit", or at least a guideline, to the maximum speed of the pulsing? I want to increase it but do not wish to damage or destroy an ouput.

Jack

[fordgt40]

Jack

Sorry, but I have not developed this thought any further. I would need to check the datasheets of the motor contoller chips to see what are the parameters. It is certainly feasible as I did a small experiment some while back using SIOC to send control pulses to the motors - though it was very hit and miss due to my crap coding at the time :)

David