"Inner Circle" HSI - SIOC DC Motors Card Script

[Boeing 747 Flyer]

Hi everyone,

I need some advice on how to build a SIOC script for the "Inner Circle" of my HSI.

This Circle is not the rotating compass card, but the inner needle that points to a VOR station and that moves according to the aircraft's heading.

The HSI is equipped with DC Motors, and is also equipped with Potentiometers for feedback (although I'm still finalising detils of these potentiometers).

So, I need a script that incorporates Motors, feedback and the FSUIPC Offset for the Inner Circle of a HSI. I cannot find anywhere to start; as all the scripts I can see are for Stepper Motors.

I *think* the Potentiometers go from like 0-5K Ohms, then when they reach the 0/360 (North) heading they reset back to 0.

If some-one could help me, point me in the direction of a script that I can modify, or anything else, I would be most grateful.

Kindest regards,

Jack

[crashdog]

Hi Jack,
if I understand you right, you are trying to move the nav1 localizer needle ? You can get the value from the fsuipc offset $0C48. Then you need to calibrate the potentio meter. Means you have to find out where the middle and the right and left extremes are. As well as calculating the pot-values to be equal to the nav-needle values or the other way around. (That depends on your preference). The nav-needle's value range is -127 to 127. Then you need to programm the motor movement according to the pot's position vs. the nav1-needle position. If you're using OC card's analogue input, it's 8-bit so the values will allready be close to those of the nav-needle.
I do have a sioc dc motor code example for an airspeed indicator on my homepage : http://www.md80.ch/index.php?option=com_content&view=article&id=82&Itemid=72
Basically it's the same principal for the nav-needle.

Hope this helps you
Kind Regards,

Gery

[Boeing 747 Flyer]

Thank you very much Gery!

I understood most of that.

Also; thank you very much for the localiser offset. I was, in fact, trying to use Offset 04CE, the NAV1 Course Indicator. This ranges from 0-359 degrees. Does this change anything?

Also, please may you expand a little on the scaling and the "8-bit" sort of things?

Jack

[crashdog]

HI Jack,
the nav1 course is the compass and the nav1 localizer indicator is the needle that shows if your're left or righ off the selected course.

When it comes to the scaling there's not much too it. You will want to use simmilar values for the pot and the needle. So you need to find a factor for either one of them so that you get simmilar values. If you look at the airpseed indicator example you see that I devided dc_in_mo4 / 61. dc_in_mo4 is here the pot-value for the airspeed needle. If I devide it by 61 in this case I get values from 70 to 250 in stead of 4270 to 14250 (which is the pot's native resolution using the bodnar cards as input (12 bit resolution)). The OC cards have a 8-bit input resolution which gives you a potentiometer native values from 0 - 255.

Regards,
Gery

(pot = potentiometer.)

[Boeing 747 Flyer]

Hi Gery,

I definitely understood most of that!

So what you're saying is, you need to divide the FSUIPC range to get it down to a figure of, lets say 70-250 (or whatever the native resolution is).

How can I do this for the Offset $04CE (NAV1 Course) though? It has a range from 0-359, with a length of 2 Bytes. This would have to be divided by something like 1.X surely?

Jack

[crashdog]

Hi Jack,
yes, but the nav1 course will probably not work with a potentiometer since it's 360 degrees. A potentiometer even if the mechanical range is 360 degrees always has a dead zone. It's most likely that your HSI has syncros not pots for the course position. So far I have not seen any one make a card that can handle syncros. So the only way to do the course is to modify the HSI and excange the DC motor with a stepper motor.

Gery

Gery

[Boeing 747 Flyer]

Hi Gery,

The HSI uses three pots per motor. Each Pot covers approximately 120 degrees, thus making up the full circle. They are definitely DC Motors and the Potentiometers are definitely potentiometers.

So, I'll need to scale and script three potentiometers, each covering a different range of offset 04CE.

Jack

[Boeing 747 Flyer]

Hi everyone,

I have written myself a small test script; it does not require FSUIPC or anything; it just rotates the motors when Var0000 is executed. Take a look:


Var 0, Value 0
{
&Motor_2 = 120
&Motor_3 = 120
&Motor_4 = 120
&Motor_6 = 120
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1

Var 0002, name Motor_2, Link USB_DCMOTOR, Output 2

Var 0003, name Motor_3, Link USB_DCMOTOR, Output 3

Var 0004, name Motor_4, Link USB_DCMOTOR, Output 4

Var 0005, name Motor_5, Link USB_DCMOTOR, Output 5

Var 0006, name Motor_6, Link USB_DCMOTOR, Output 6

Var 0010, name A1, Link USB_ANALOGIC, Input 1, PosL 0, PosC 127, PosR 255

Var 0011, name A2, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 255

Var 0012, name A3, Link USB_ANALOGIC, Input 3, PosL 0, PosC 127, PosR 255

Var 0013, name A4, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 255

Var 25, name Bar_GS
{
IF &A3 <= 150
{
&Motor_1 = 120
&Motor_5 = 250
}
ELSE
{
&Motor_1 = 250
&Motor_5 = 120
}
}

As you can see, Motors 1 and 5 are meant to rotates according to the position of potentiometer AD3. However, when the script is run... They just stand still. AD3 is DEFINITELY working (I have tested in controlador.exe) and it runs through 0-255 values without any problems.

Any ideas? Have I defined something wrong?

Jack

[crashdog]

Hi Jack,
have you looked at the console ? you should be able to see the contents of the variables there.
I'm not 100% sure but I think var0 is only executed once. You probably need a function and a timer to call the function.
A very good site with some examles: http://www.lekseecon.nl/howto.html

Gery

[Boeing 747 Flyer]

HI Gery,

I found the problem. According to the log, the Pots are not recognised at all.

This is my SIOC.ini:


[SIOC]
IOCP_port=8092
IOCP_timeout=4000
Minimized=Yes
toggle_delay=20
CONFIG_FILE=Motor_tests.ssi

[IOCARDS MODULE]
IOCard_disable=No
IOCard_LPT=No

[USBKEYS]
USBKeys=0,13

[USBDCMOTORS]
USBDCmotor=0,38

[MASTERS]
;MASTER=1,7,1,1001
;MASTER=2,5,1,1002
MASTER=3,11,1,48
;MASTER=5,8,1,1005
MASTER=0,4,1,12
MASTER=2,5,1,50

[USBKEYS]
USBKeys=4,67

[A/D USED MASTER]
USB_AD=4

[MULTIPLE]
MUSB=Yes

[USBSERVOS]
USBSERVOS=0,4
deviceUSB=2132

[FSUIPC MODULE]
FSUipcdisable=No
FSUipcRefresh=50

[IOCP CLIENTS MODULES]
IOCPini_delay=3000
IOCPclient0_disable=Yes
IOCPclient0_host=localhost
IOCPclient0_port=8090
IOCPclient1_disable=Yes
IOCPclient1_host=localhost
IOCPclient1_port=8099

[SOUND MODULE]
Sound_disable=NO
Volume=100


And the script (you have below).

Also, yes Var0 is only executed once. Var 0 will set the 4 motors moving, and the other 2 are dependant upon the position of the pots, which are not recognised.

Jack

[Boeing 747 Flyer]

Any ideas? I still cannot get the potentiometers recognised by SIOC, despite the fact that they are fully working in Controlador.exe?

[fordgt40]

Jack

Try reading the last few lines on page 4 of the installation manual for this card. Also, I would strip out the many references to other cards in your .ini file to reduce it down to only what you currently need

David

[Boeing 747 Flyer]

Hi David,

I will look at the manual.

The references like USBServos, etc... Are all needed. I have 7 seperate Opencockpit Cards + one ATC module.

EDIT: David, which manual is this? I see no reference to Potentiometers in both the USBExpansion or Master manual lifted from the OC shop page.

Jack

[fordgt40]

Hi David,

The references like USBServos, etc... Are all needed. I have 7 seperate Opencockpit Cards + one ATC module.

Jack

I only meant for the troubleshooting stage :)

David

[fordgt40]

Jack

Try reading the last few lines on page 4 of the installation manual for this card.

David


The card you are trying to make work - the USBDCMotors card. I am assuming that you are using the A/D inputs from that card

David

[Boeing 747 Flyer]

Hi David,

The Pots are now completely recognised, but Var 25 refuses to execute when the pot changes from 150 and vice-versa.

Why does this script not work?


Var 0, Value 0
{
&Motor_2 = 120
&Motor_3 = 120
&Motor_4 = 120
&Motor_6 = 120
}

Var 0001, name Motor_1, Link USB_DCMOTOR, Output 1

Var 0002, name Motor_2, Link USB_DCMOTOR, Output 2

Var 0003, name Motor_3, Link USB_DCMOTOR, Output 3

Var 0004, name Motor_4, Link USB_DCMOTOR, Output 4

Var 0005, name Motor_5, Link USB_DCMOTOR, Output 5

Var 0006, name Motor_6, Link USB_DCMOTOR, Output 6

Var 0010, name A1, Link USB_ANALOGIC, Input 1, PosL 0, PosC 127, PosR 255

Var 0011, name A2, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 255

Var 0012, name A3, Link USB_ANALOGIC, Input 3, PosL 0, PosC 127, PosR 255

Var 0013, name A4, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 255

Var 25, name Bar_GS
{
IF &A3 <= 150
{
&Motor_1 = 120
&Motor_5 = 250
}
ELSE
{
&Motor_1 = 250
&Motor_5 = 120
}
}

[fordgt40]

Jack

It is a basic principle of SIOC that scripts attached to a variable are only executed when the value of the variable changes. But in your coding variable 25 never changes value!! This is amply and clearly explained on Nico`s site, perhaps a bit more homework is required :)

David

[kiek]

This is amply and clearly explained on Nico`s site, perhaps a bit more homework is required :)
SIOC - The golden rule (http://www.lekseecon.nl/sioc.html#goldenrule)
:-)
Nico

[Boeing 747 Flyer]

Thanks very, very much everybody. All works now!:D

Onto the next task... Getting the Pots, Motor and Offset $04CE all interfaced together.

I am trying trying to understand Gery's method from earlier. How can I interface all of them? I am comfortable with Servo gauges but not with these (?).

Kindest regards,

Jack

[Boeing 747 Flyer]

Any ideas?

[crashdog]

Hi Jack,
maybe a more specific question would be good. I don't think someone will write the code for you ;)
If I understand right you now have 3 pots connected to a input card (OC or bodnar) and you have one dc motor that should be move according to the pot's position.
The first thing would be to read the pots and check if one of them is in a range which would make it the active one. You will also need to calibrate the pots (hoping they are linear, logarithmic would be really difficult). When you have the active pot's position you need to calculate the difference from the pot to the fsuipc value and move the motor according to the difference.

Was that what you needed to know ?
Hope I could be of any help.
Gery

[Boeing 747 Flyer]

Hi Gery,

The potentiometers are perfectly linear.

Potentiometer 1, range 127-255, covers the heading range: 180 - 010 Degrees

Potentiometer 2, range 121-253, covers the heading range: 009 - 179 Degrees

When the motor reaches 0 degrees, Potentiometer 2 kicks back in again and the process restarts.

Tests performed anticlockwise. Please note all above readings are anticlockwise.

Both pots work perfectly and are definitely suitable for this application. I would just like to know how I go about scaling, an example calculation, etc.

It's just hard because there are literally no scripts/advise for instruments such as heading indicators, which continously rotate.

Using the above information, can you show me an example calculation involving the offset, motor and pots?

Jack

[crashdog]

If I understand right, the scale of the instrument is 360 deg, the fsuipc value of $04CE goes from goes from 0 to 359 ?
If yes, then I would align everything on "0". Means the instrument's needle is at 0 when the pot1 is and also when $04CE is at 0.
When you move the motor with the pot from 0 to 1 degrees you should read the value that the pot1 shows and that is then the factor between the pots and the fsuipc $04CE value. You then need to choose which value you want to divide or multiply to have simmilar values to compare.
Example:
$04CE = 0 (degree) and pot1 = 0 (decimal)
$04CE = 1 (degree) and pot1 = 64 (decimal)
64 divided by 64 is 1. So if your pot is linear you should be able to divide all values by 64. Then your pot value is the same as your fsuipc value.

Then you need to programm something like :
-- Read pot1 and pot2 value
-- Check which pot is in active range and assing to a helper variable for example pot = pot1.
-- if pot_value < $04CE_value then
move motor negative.
-- if pot_value > $04CE_value then
move motor positive.
-- Else
stop motor.
-- End.

[Boeing 747 Flyer]

Hi Gery,

I understood most of that, except for the "64 - Decimal" part. What is this "decimal"? Pots values in SIOC are 0-255, so I don't understand that little bit.

regards,

Jack

[crashdog]

http://en.wikipedia.org/wiki/Decimal

Sorry this is the last post for this thread. Can't help you more then this.

Gery

[Boeing 747 Flyer]

http://en.wikipedia.org/wiki/Decimal

Sorry this is the last post for this thread. Can't help you more then this.

Gery
For not knowing why 64 is a decimal?

:eek:

To me, a decimal is 13.8, 56.9, etc. 64 is not a decimal?

Also, you say align Pot 1 at 0. As I said, Pot 1 can never reach 0, it covers the anticlockwise range 180 - 010; it never crosses 0. You mean Pot 2?

[kiek]

Hi Jack,


To me, a decimal is 13.8, 56.9, etc. 64 is not a decimal?
I believe he meant number 64 in the decimal system notation (what we normally use for numbers), not hexadecimal like $04CE
$64 (in hexadecimal system, base 16) would be 6*16 + 4 = 100 in decimal system notation (base 10) ...
You understand?

Nico
BTW 100 in the binary system (base 2) is the same as 4 decimal and 4 hexadecimal ;-)

[Boeing 747 Flyer]

Hi Nico,

I'm not sure I understood all that. Where does the "+4" come from? And the base is what you multiply the value by? Like base 16 = *16 like you said.

Do I need to know this for the scripting of my HSI? I've done loads of Offsets with SIOC before and have never payed attention to this. 04CE is just standard 0-359.

Jack

[kiek]

Hi Jack,
You have to study a little bit I'm afraid...

The base is indeed used to calculate a number,

in a base 10 system 123 means:
1 x (10 to the power of 2) + 2 x (10 to the power of 1) + 3 x (10 to the power of 0), so 100 + 20 + 3 = 123

while in a base 16 system 123 means:
1 x (16 to the power of 2) + 2 x (16 to the power of 1) + 3 x (16 to the power of 0) = 256 + 32 + 3 = 291

Note that 10 to the power of 0 = 1

Nico

[Boeing 747 Flyer]

Okay, so in Decimal (base 10), the number 394 is...

3 x (10 power 2) + 9 x (10 power 1) + 4 x (10 power 0) = 300 + 90 + 4 = 394?

[Boeing 747 Flyer]

Right, this is what I got:

Potentiometer 1

Covering Range - 020 - 345 Degrees

Potentiometer Value Range: 253 - 7

This Pot does NOT cross 0, so there's no point working out 0 -1 degrees.

Potentiometer 2

Covering Range: 346 - 019 Degrees

Potentiometer Value Range: 115 - 134

This Pot DOES cross 0, so we'll work out the 0 -1 cross here.

360/0 Degrees = Pot 130

001 Degrees = Pot 128

So that's practically a ratio of 2 Degrees values for every 1 Pot value. If I turn the motor really slow, I can get tiny increments in Pot value, acutally working out to a ratio of 1.87 Degrees for every 1 Pot Value.

END DATA

So, I'm really confused here. Which values do I use? I take it that I'll need the 130, 128 and maybe the ratio value, but how? Referencing to Gery's post I cannot work it out.

I apologise, but I've spent 1.3 hours working it out and am starting to get a headache!:-?

Kindest regards,

Jack

[kiek]

Okay, so in Decimal (base 10), the number 394 is...
3 x (10 power 2) + 9 x (10 power 1) + 4 x (10 power 0) = 300 + 90 + 4 = 394?
Indeed, that was easy. A final test to check whether you have understood:

What is 123 (decimal) in the hexadecimal notation?

Nico

[Boeing 747 Flyer]

Well Nico, 123 in Base 16 is written below (you provided the answer), so I shall do another number to prove I'm not cheating.

512 in Hexadecimal...

5 x (16 power 2) + 1 x (16 power 1) + 2 x (16 power 0) = 1280 + 16 + 2 = 1298

Is this correct or not?

Also, surely Gery's method only works if "0 Degrees 04CE" = "0 Degrees Pot"? Of course, mine equals 130 Pot when 04CE = 0, so I can't work out the dividing factor.

Regards,

Jack

[kiek]

Well Nico, 123 in Base 16 is written below (you provided the answer), so I shall do another number to prove I'm not cheating.
No Jack .... I did not provided the answer, so my question remains: What is 123 (decimal) in the hexadecimal notation?
Or in other words what hexadecimal number is equal to 123?

Nico

[Boeing 747 Flyer]

Hi Nico,

I have absolutely no idea how to convert backwards. Using online calculators, we frequently see the reading "7B", whatever that means.

What does this have to do with Offset 07CE?

Kindest regards,

Jack

[fordgt40]

Jack

With a minimal amount of effort, it is not difficult to find out

http://www.webelfin.com/webelfindesign/dechex.html

David

[Boeing 747 Flyer]

Jack

With a minimal amount of effort, it is not difficult to find out

http://www.webelfin.com/webelfindesign/dechex.html

David

I apologise, but I do not understand that link, clearly not a "minimal amount of effort".

[fordgt40]

Jack

A minimal amount of effort to find on the web how to do it!!
Understanding it is clearly a step too far then

David

[Boeing 747 Flyer]

Hi David,

I found many articles, identical to yours. It is not the effort that is lacking, it is the understanding.

I would just like to know how hexadecimal(s) relate to offset 04CE. I am still willing to learn, I just want to know the connection. Furthermore, I would like to know how you can get a common factor if 0 Degrees = 130 on the Pot, and 1 Degrees = 128 on the Pot.

Jack

[fordgt40]

Jack

Understanding Hex should not be difficult and is often necessary in programming. Hex counts on a base or 16 therefore 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F - this equates to 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 in decimal. When, in hex, you go past F then it counts again as 10,11,12,13,14,15,16,17,18,19,1A,1B,1C,1D,1E,1F and so on.

In the example Gery gave:-

$04CE = 0 (degree) and pot1 = 0 (decimal)
$04CE = 1 (degree) and pot1 = 64 (decimal)
64 divided by 64 is 1. So if your pot is linear you should be able to divide all values by 64. Then your pot value is the same as your fsuipc value.

He was only pointing out the difference in number base to avoid any confusion as FSUIPC uses hex!!
You can ignore hex for the time being and focus on how you programme your pots. The info is all there, though I suspect again that your knowledge of SIOC is not to the standard required for such a task. Again, as previously advised, you should focus on becoming fully versant with less demanding SIOC coding before tackling this exercise.

David

[Boeing 747 Flyer]

though I suspect again that your knowledge of SIOC is not to the standard required for such a task. Again, as previously advised, you should focus on becoming fully versant with less demanding SIOC coding before tackling this exercise.

David

Heheheh, you should see some of the scripts I have done in my free time. They are far more demanding than you may think;). Here's one I wrote earlier this year:


Var 7777, Link FSUIPC_IN, Offset $3AB0, Length 8, Numbers 0 // EGT2
{
L0 = V7777 - 459.67 // FSUIPC Conversion Rankine -> Celcius
L0 = L0 - 32
L0 = L0 * 5
L0 = L0 / 9
L0 = ABS L0 // L0 not signed
L2 = L0
IF L0 <= 100 // First sector
{
L1 = L2 * 0.07 // (7 steps/100 values) = 0.07
}
ELSE // Is a greater value
{
L2 = L0 - 100 // L2 only have values for next sector
IF L0 <= 200 // Second sector
{
L1 = L2 * 1.37 // (137 steps / 100 values) = 1.37
L1 = L1 + 7 // Add steps of others sectors (+7)
}
ELSE
{
L2 = L0 - 200 // L2 only have values for next sector
IF L0 <= 500 // 3. Sector
{
L1 = L2 * 1.463 // ( 439 / 300) = 1.463
L1 = L1 + 144 // Add steps of others sectors (7 + 137)
}
ELSE // Out of range
{
L2 = L0 - 500 // L2 only have values for next sector
IF L0 <= 800 // 4. sector
{
L1 = L2 * 1.437 // (431 steps / 300 values) = 1.437
L1 = L1 + 583 // Add steps of others sectors (7 + 137 + 4
}
ELSE
{
L1 = 1014 // Max. position
}
}
}
}
&Servo1 = 0 + L1 // Add to minimum (0)
}

Besides, what an earth have I done wrong in SIOC so far, since the introduction of Gery's script?

I have simply asked how it can be factorised, that's all. Nothing else.

0 = 130
1 = 128
2 = 126

And so on... As you can see, linear, but I cannot personally factorise it.

Thank you, once again, for the explanation of Hex, it is helpful.

Jack

[fordgt40]

Jack

Good luck then, I will be gentle and not answer your question :)

David

[Boeing 747 Flyer]

Jack

Good luck then, I will be gentle and not answer your question :)

David
What else should I expect from a SIOC question thread!:)

I don't see how your comment is appropriate to this thread, I'm sorry. From now on, I'd only like post related directly to the scaling of the HSI which is, interestingly, the title of this thread.

For those of you who can answer: Using Gery's method, how could I factorise 0 = 130, and 1 = 128? I can only see this method working if the pot is at 0 at 0 degrees.

[kiek]

I have absolutely no idea how to convert backwards. Using online calculators, we frequently see the reading "7B", whatever that means.

7B means 7 * 16 + 11 = 123 ...

I was only trying to help you to learn the difference between number notations (binary, decimal and hexadecimal for instance). You have to understand that if you are using FSUIPC offsets or lekseecon variables. Some of my Lekseecon variables are coded in hex (like the clocks 846 and 847, the COMM displays 852 and 853 , ...).

Nico

[kiek]

Hi Matt,

PLEASE for our sake, keep it on topic.

We would love to, but it all started when Jack wrote this (in post #26):

To me, a decimal is 13.8, 56.9, etc. 64 is not a decimal?

So we tried to teach Jack number notations first....

Nico

[Boeing 747 Flyer]

Thank you Nico for the further explanation. It seems I have some mathematical work to do.

Anyway, back on topic. I've been working my brain tying to solve the Pot V Motor problem.

0 degrees = 130

1 degrees = 128

2 degrees = 126 (actually 127 because it decreases by 1.87 each time, not 2, but such a small difference).

And so on...

Does anyone know, using Gery's method, how the Pot values can be factorised? Am I wrong in thinking that his method only works if Pot 0 = Degrees 0?

Jack

[Boeing 747 Flyer]

Hi guys,

Just an idea... Although this method is labour intensive...

I could hand-assign each potentiometer value to its respective heading value, and tell SIOC to stop the motor if it is equal to the offset, ELSE move =ve/-ve.

EDIT: I have decided to go ahead with this method.

Please see above.

[Boeing 747 Flyer]

HI everyone,

I'm having trouble with the method below.

I developed a test script. For 90% of the instrument, this script is inactive; it only works in the range heading 346-004.

Can anyone tell me why, whenever "P" changes value, it's subsequent brackets are completely ignored by SIOC and not executed? My motor just continously spins in a single direction, never changing according to P, like it should...


Var 0004, name Motor4, Link USB_DCMOTOR, Output 4

Var 0005, name CRS, Link FSUIPC_IN, Offset $0C4E, Length 2

Var 2, name P
{
IF &P > &CRS
{
&Motor4 = 123
}
ELSE
{
IF &P < &CRS
{
&Motor4 = 253
}
ELSE
{
IF &P = &CRS
{
&Motor4 = 128
}
}
}
}

Var 1, name A4, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
IF &A4 = 140
{
&P = 346
}
ELSE
{
IF &A4 = 139
{
&P = 347
}
ELSE
{
IF &A4 = 138
{
&P = 349
}
ELSE
{
IF &A4 = 137
{
&P = 350
}
ELSE
{
IF &A4 = 136
{
&P = 352
}
ELSE
{
IF &A4 = 135
{
&P = 353
}
ELSE
{
IF &A4 = 134
{
&P = 354
}
ELSE
{
IF &A4 = 133
{
&P = 356
}
ELSE
{
IF &A4 = 132
{
&P = 357
}
ELSE
{
IF &A4 = 131
{
&P = 359
}
ELSE
{
IF &A4 = 130
{
&P = 000
}
ELSE
{
IF &A4 = 129
{
&P = 001
}
ELSE
{
IF &A4 = 128
{
&P = 002
}
ELSE
{
IF &A4 = 127
{
&P = 004
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}


Maybe Nico can shed some light if I have done something wrong. There is nothing wrong mechanically. As I said, the brackets following Var P are completely ignored, even when it changes value (appeals for reasons).

Jack

[Boeing 747 Flyer]

Hi everyone,

According to Hessel Oosten's guide, it says that "128" commands the motor to stop.

This is definitely not true; it causes my motors to go very fast instead.

I made a script that when CRS = 0, Motors = 128 (stop).

However, when the CRS hit 0, the motors shot up in speed, before going back down after surpassing 0.

Weird huh?

Jack

[kiek]

Hi Jack,

As I said, the brackets following Var P are completely ignored, even when it changes value (appeals for reasons).

Computers are not like humans... Brackets are not ignored because SIOC does not like you, if they are not executed, then you may conclude that var P never changed value...
And how come P never changes value? Maybe because var A4 is outside the range 127 - 140? Please check.

Nico

[Boeing 747 Flyer]

Hi Nico,

It is true, for most of the time, that Var P does not change. However, when A4 enters the range 127-140, it does change, and this change is recnogised in SIOC. So, if the change is recognised, then why not the brackets?

[kiek]

It is true, for most of the time, that Var P does not change. However, when A4 enters the range 127-140, it does change, and this change is recnogised in SIOC. So, if the change is recognised, then why not the brackets?
Do not doubt the correct working of SIOC, doubt your own script.

I quit. This thread is getting too long, IMHO. This is not a teaching course how to write SIOC scripts. Study, experiment and learn. Start with easier applications then controlling a motor. Even I have not touched that subject. ;-)

regards,

Nico

[Boeing 747 Flyer]

I know perfectly well how to control a motor in SIOC.

After spending 3 hours on the subject last night; I achieved aprtial sucess with this:


Var 0, Value 0
{
&Motor4 = 50
}

Var 0004, name Motor4, Link USB_DCMOTOR, Output 4

Var 0005, name CRS, Link FSUIPC_IN, Offset $0C4E, Length 2

Var 58, name A42, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
C0 = &CRS = 0
C1 = &CRS = 360
IF C0 OR C1
{
IF &A42 = 130
{
&Motor4 = 25
}
ELSE
{
&Motor4 = 170
}
}
}

Whilst this script does not do much, it achieves the primary goal.

The motor always moves. However, if both CRS is on 0, and A42 = 130, the motor stops. However, the second I change the CRS, the motor moves again.

This script proves, for the first time, I have managed to sucessfully integrate the Offset, Motors and Pots together. The motor now specifically stops on the heading that I tell it to, according to FSX.

Of course, more work is needed. I need to repat the above script 359 times. Not too much work 'heh?

Jack

[Boeing 747 Flyer]

Hi everyone,

I appreciate nobody wants to help anymore, but if you do, I would be more than pleased.

The following script is very simple:


Var 0004, name Motor4, Link USB_DCMOTOR, Output 4

Var 0005, name CRS, Link FSUIPC_IN, Offset $0C4E, Length 2
{
C0 = &CRS = 0
C1 = &CRS = 360
IF C0 OR C1
{
IF &A42 = 131
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}

Var 58, name A42, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
C0 = &CRS = 0
C1 = &CRS = 360
IF C0 OR C1
{
IF &A42 = 131
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}

As you can see, the following should happen:

- IF CRS = 0 (or 360, they are the same), AND A42 = 131, then the motor should = 129 (STOP)

- Otherwise, the motor should move at a speed of 201

For the most, this script works. It continues to move, and never stops until the above requirements are met (I have my CRS set to 0, and my A42 Pot is showing 131).

However, if I move my CRS to ANY other value, then the motor should return to a speed of 201. Instead, however, it stays locked at a speed of 29.

Just to reiterate; To STAY at 129, the CRS must be 0 or 360, AND the Pot must be 131. No matter what my CRS is on, it stays locked on 129 for some reason, contradictary of my script requirements. This is surely a SIOC error? I mean, look at the script!!!

Any ideas?

Jack

[kiek]

Hi Jack, me again, one more time...

This is surely a SIOC error? I mean, look at the script!!!
I have looked at your script and it SURELY IS NOT A SIOC ERROR BUT A WRONG SCRIPT.

Have a look at what you produced:

As well in Var 005 as in Var 58 you start with testing whether CRS = 0 OR = 360 or not.

If so, it does something (controlling the Motor based on A42), but if not it does nothing !!!

That's why CRS changes after you have you reached 0 or 360 have no effect. :-)

Nico

BTW It is not recommended to control one motor from two variables. You better write one control subroutine and call it from as well Var 5 as from Var 58.

[fordgt40]

Jack

Please stop blaming SIOC for your own problems. There is a flaw in your coding/logic, despite your avowed abilities :roll:

Try checking what happens through iocpconsole - you will find the answer and more importantly learn as a result.

David

Edit: Posted without seeing Nico`s reply, which actually identified the error I was referring to

[Boeing 747 Flyer]

Thank you very much for the reply guys. I have literally been reduced to tears (pathetic, I know) over this. I have spent months and months building the instrument; it is beautiful, I am just so annoyed that I cannot cross this final hurdle. You know, I would not even mind paying someone to do the script.

@Nico; thanks very much for that. I have, as per your suggestion, used a SUBRUTINE. The following script now works perfectly, thank you so much!!!


Var 0, Value 0
{
&Motor4 = 201
}

Var 0004, name Motor4, Link USB_DCMOTOR, Output 4

Var 49, name P, Link SUBRUTINE,
{
IF &Motor4 = 129
{
C0 = &CRS < 360
C1 = &CRS > 0
IF C0 AND C1
{
IF &A42 = 130
{
&Motor4 = 201
}
}
}
}

Var 0005, name CRS, Link FSUIPC_IN, Offset $0C4E, Length 2
{
CALL &P
}

Var 58, name A42, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
C0 = &CRS = 0
C1 = &CRS = 360
IF C0 OR C1
{
IF &A42 = 130
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}

Var0 sets the motor spinning, and the rest of the coding dictates when and where it stops/starts.

However, the above script literally JUST works for 360/0 degrees, as per the requirements. For my CRS knob + pointer to work, I will have to write 359 more of the above scripts; no problem, I have the time, just that SIOC won't accept it...

I compiled the above script with the following:


Var 49, name P1, Link SUBRUTINE,
{
IF &Motor4 = 129
{
C0 = &CRS1 < 355
C1 = &CRS1 > 355
IF C0 AND C1
{
IF &A421 = 134
{
&Motor4 = 201
}
}
}
}

Var 0005, name CRS1, Link FSUIPC_IN, Offset $0C4E, Length 2
{
CALL &P1
}

Var 58, name A421, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
IF &CRS = 355
{
IF &A421 = 134
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}


The script DOES stop at 355 and 360... But we return to the original problem of it sticking at 29. No doubt this is due to the complex array of the SUBRUTINES and other calculations we have going on.

Can you suggest a way I can get the two scripts to work with each other, so that I can make 360 of them? Or will the above method ONLY work for one, specific degree of operation?

I'm so happy that, even though you suggested the changes and SUBRUTINE, I managed to do the above myself and get it working. Progression, at last.

Please stick with me guys, I may not be brilliant at SIOC but I guarentee this instrument will NOT disappoint. (In fact, I don't think there's anything else like it available for flight simulators; anywhere).

Kindest regards,

Jack

[Boeing 747 Flyer]

EDIT: SEE below post made by myself.

[kiek]

Hi Jack,
Look what you wrote:


Var 49, name P1, Link SUBRUTINE,
{
IF &Motor4 = 129
{
C0 = &CRS1 < 355
C1 = &CRS1 > 355
IF C0 AND C1
{
IF &A421 = 134
{
&Motor4 = 201
}
}
}
}

What a weird piece of code... the expression C0 AND C1 will never be TRUE, so this script actually does nothing ...

Furthermore:
I told you to call the subroutine from two places, not only from the CRS input (var 5) but also from the A42 input (var 58 ). You did not do that.
Put the logic to control your motor in that subroutine and in that subroutine only.

If you think you can solve it with 360 scripts (not a good approach imho) then it should also be possible to develop an algorithm that does exactly the same.

Take a break Jack. Think it over and start with a proper design. Not in SIOC but with pencil and paper. Write down the state information you have (inputs) and what control possiblities (outputs) there are. Then write the algorithm that connects input(-s) to output(-s). Finally convert it to SIOC code.

Programming by trial and error, is not a good approach.

Nico

[Boeing 747 Flyer]

HI Nico,


the expression C0 AND C1 will never be TRUE

That is correct. However, without this SUBRUTINE, the motor does indeed stay stuck at 129 regardless of CRS changes. I appreciate this is strange, because technically the SUBRUTINE does nothing. But somehow, it does!


I told you to call the subroutine from two places, not only from the CRS input (var 5) but also from the A42 input (var 58 ). You did not do that.


I shall rewrite, then repost it here. However, didn't you say that the logic for the motor is flawed (that it only pays attention to 360 or 0?).

Regards,

Jack

[fordgt40]

Jack

You are in danger of compounding error on error. The logic is flawed in at least one place, as per your last para above. Please take Nico`s advice - stop coding and rethink.

David

[kiek]

No the subroutine has no effect at all (no output), that must be caused by something else.

Yes I said that you should put the logic for motor control in the subroutine. Of course I meant the right logic, not yours.

And now I really stop with this thread, I've had enough of it

[Boeing 747 Flyer]

Okay, how's this?


Var 0, Value 0
{
&Motor4 = 201
}

Var 0004, name Motor4, Link USB_DCMOTOR, Output 4

Var 49, name P, Link SUBRUTINE,
{
C0 = &CRS = 0
C1 = &CRS = 360
IF C0 OR C1
{
IF &A42 = 130
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}

Var 0005, name CRS, Link FSUIPC_IN, Offset $0C4E, Length 2
{
CALL &P
}

Var 58, name A42, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
CALL &P
}

I appreciate you have stopped commenting on this thread. but just a simple "Yes" (if I have got your subrutine idea correct) or "No" (if I have still not done what you said) would suffice, if you are still willing.

Jack

[Boeing 747 Flyer]

YEEEEAAAAHHAAAAA!

I finally got it working with TWO degrees now.

The CRS pointer now stops at 355 and 360 degrees. And, although laborious, I am starting the process of doing all 359 degrees.

Woo!

This was my final script.

The 360 degree script:


Var 0, Value 0
{
&Motor4 = 201
&control = 0
&control = TIMER 1 0 5
}

Var 158 name control Link SUBRUTINE
{
CALL &P2
}

Var 0004, name Motor4, Link USB_DCMOTOR, Output 4

Var 49, name P, Link SUBRUTINE,
{
IF &Motor4 = 129
{
C0 = &CRS < 360
C1 = &CRS > 0
IF C0 AND C1
{
IF &A42 = 130
{
&Motor4 = 201
}
}
}
}

Var 0005, name CRS, Link FSUIPC_IN, Offset $0C4E, Length 2
{
CALL &P
}

Var 58, name A42, Link USB_ANALOGIC, Input 4, PosL 0, PosC 127, PosR 250
{
C0 = &CRS = 0
C1 = &CRS = 360
IF C0 OR C1
{
IF &A42 = 130
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}

The 355 degree script:


Var 49, name P1, Link SUBRUTINE
{
IF &Motor4 = 129
{
C0 = &CRS1 < 355
C1 = &CRS1 > 355
IF C0 OR C1
{
IF &A42 = 134
{
&Motor4 = 201
}
}
}
}

Var 0005, name CRS1, Link FSUIPC_IN, Offset $0C4E, Length 2
{
CALL &P1
}

Var 50, name P2, Link SUBRUTINE,
{
IF &CRS = 355
{
IF &A42 = 134
{
&Motor4 = 129
}
ELSE
{
&Motor4 = 201
}
}
}

Both of the above were compiled together.

So yes, everything is working! For now...:D

[kiek]

but just a simple "Yes" (if I have got your subrutine idea correct) or "No" (if I have still not done what you said) would suffice, if you are still willing.

YES, this is what I meant, but you should update the body of Subroutine P with the right logic.

Regarding your second post with as well a subroutine P1 as a subroutine P2: NO THAT'S NOT RIGHT! Now again you have created more places where you control the motor, don't do that.! Do not write 360 scripts (which is not very efficient, to say the least ..............) , but write ONE control script in subroutine P.
I could write it in an hour, but I'll leave it to you as an exercise.

Nico