Hey guys,
WOW! I am finally read to hook up my OpenCockpits DC Motor card and watch my throttles move on their own! I never thought I would physically get to this point. Now it becomes even more difficult... it has become a mental challenge!
Does anyone know how to write SIOC code for the OC DC motors card? I need to just use the FSUIPC offsets for the Autothrottle. Having done some research, it sounds like this should be a pretty easy setup to write. That being said, I know just about as much about SIOC code language as I do Chinese, so if anyone is well versed (or even better versed than me) I would love some help.
And... if it comes down to it, I would be willing to negotiate some price if you would be willing to write the codes for me. Details would need to be worked out, but I would be more than willing to send a little compensation over PayPal if necessary.
Thanks guys,
Matt
Matt,
A few years ago the (free) code below was posted on a website which does not exist anymore.
It's gives a very solid base for studying, gaining insight in what's going on and eventually adapting to your own situation.
I converted it in that time for the 767 with *one* driving throttle axis and slipclutches (because that's the only realistic way) but can't find it at this very moment.
See this thread:
http://www.mycockpit.org/forums/showthread.php/17573-Autothrottle-Override (http://www.mycockpit.org/forums/showthread.php/17573-Autothrottle-Override)
Nevertheless, happy studying the coming Christmas days :-).
Hessel Oosten
////////////
// *****************************************************************************
// * Config_SIOC ver 3.5 - By Manolo Vélez - www.opencockpits.com (http://www.opencockpits.com)
// *****************************************************************************
//
// * Editor: Hermann Hummer www.simhard.eu.tt (http://www.simhard.eu.tt)
//
// * FileName : Motorized_Throttle_1.385.txt
// * Date : 8.3.2008
// * PM + PSS Airbus updated
// * some variables shiftet
// * manual Trim enabled when all AP of PM are disengaged
// * Subroutine for motor movement starts every 50ms now
// * Some improvements for AP: eg. when APP is active then V/S is set to -2000
// * PMDG variables changed esp. ALT-HOLD and SPEED-HOLD
// * Pause modus is now dedected, so levers and trim stops in pause mode
// * FeelThereAirbus with relais to connect levers to game port
// * 2nd Mastercard and some inputs added for EFIS
// * FSX Compatibility: Disconnect both LeverPotentiometers from FS when AP is on
// * Variables for AIR-File different in FS9 and FSX
// * Some improvements for LevelD FS9 & FSX
// * FeelThere Airbus and FeelThere Boeing are recognised as different planes now
// * VNAV sets IAS for LevelD
// * Standard-AP OFF switches to Trim by Hand (eg. for FeelThere Airbus)
// * LeverStart for FSX: Var 12 & 13 changed Why different to FS9 ???? FSUIPC ??
Var 1000, Value 0 // Initialisation
{
&Lever_Elevator = TIMER 999 , 0,5 // Subroutine for Lever and Elevator Motors starts every 50ms
}
Var 0004, name V1_385 // Version number
Var 0000, name lever2_motor // Motor control
Var 0001, name lever1_motor, value 1 // starts program
Var 0002, name elevator_motor // Motor control
// for FeelThereAirbus only
Var 0003, name Relais // Relais switches from upper to lower printed board
// The following variables depend on the used Potentiometers
// You must check these values by using IOCPConsole for each Potentiometer
// 1)for 100 percent thrust: 'LeverX_upper' 2)idle: 'LeverX_idle' 3)reverser: 'LeverX_lower'.
// In this case the potentiometer values are the following:
Var 0100, name Lever1_upper, Value 121 // Upper potentiometer value of Lever1
Var 0101, name Lever2_upper, Value 124 // Upper potentiometer value of Lever2
Var 0102, name Lever1_idle, Value 23 // Idle potentiometer value of Lever1
Var 0103, name Lever2_idle, Value 24 // Idle potentiometer value of Lever2
Var 0104, name Lever1_lower, Value 6 // Lower potentiometer value of Lever1
Var 0105, name Lever2_lower, Value 6 // Lower potentiometer value of Lever2
// Airbus only:
Var 0106, name Lever1_CL, Value 65 // CL potentiometer value of Lever1
Var 0107, name Lever2_CL, Value 68 // CL potentiometer value of Lever2
Var 0108, name Lever1_FLX, Value 90 // FLX potentiometer value of Lever1
Var 0109, name Lever2_FLX, Value 93 // FLX potentiometer value of Lever2
Var 0014, name dead_area1 // to avoid jitter, we define a 'dead area' for the potentiometers
Var 0015, name break_dist1 // how many points we need for break the motors to zero
Var 0016, name current_break1 // we can define a break current for the motor
Var 0017, name current_run1 // Speed for motor when running
Var 0034, name dead_area2
Var 0035, name break_dist2
Var 0036, name current_break2
Var 0037, name current_run2
Var 0041, name dead_area3, Value 8
Var 0042, name break_dist3, Value 30
Var 0043, name current_break3, Value 40
Var 0044, name current_run3, Value 50 // Speed for motor when big difference
Var 0110, name Lever1_factor // Distance FS / PointPot
Var 0111, name Lever2_factor // Apply Distance_Pot to Distance FS
Var 0112, name Pot1_factor // Distance Pot / PointPot
Var 0113, name Pot2_factor // Apply Distance_Pot to Distance Lever
Var 0038, name Flusi, Link FSUIPC_IN, Offset $3308, Length 2 // what Flusi-version is in use?
{
&dead_area1 = 5 // to avoid jitter, we define a 'dead area' for the potentiometers
&break_dist1 = 20 // how many points we need for break the motors to zero
¤t_break1 = 50 // we can define a break current for the motor
¤t_run1 = 70 // Speed for motor when running
&dead_area2 = 5
&break_dist2 = 20
¤t_break2 = 50
¤t_run2 = 70
}
Var 0005, name Leverdiscon, Link FSUIPC_OUT, Offset $310A, Length 1 // Disconnect both LeverPotentiometers from FS
Var 0045, name Lever1_from_FS, Link FSUIPC_OUT, Offset $3330, Length 2
Var 0046, name Lever2_from_FS, Link FSUIPC_OUT, Offset $3332, Length 2
Var 0060, name CL_PSS
Var 0061, name FLX_PSS
Var 0062, name TOGA_PSS
// read the first four letters of the name of the airplane form AIR-file
// to see if it is a standard- or non-standard plane
Var 0140, name AIRFILE1, Link FSUIPC_IN, Offset $3c09, Length 1 // 1st letter of Airplane name in FS9
Var 0141, name AIRFILE2, Link FSUIPC_IN, Offset $3c0a, Length 1 // 2nd letter of Airplane name
Var 0142, name AIRFILE3, Link FSUIPC_IN, Offset $3c0b, Length 1 // 3rd letter of Airplane name
Var 0143, name AIRFILE4, Link FSUIPC_IN, Offset $3c0c, Length 1 // 4th letter of Airplane name
Var 0144, name AIRFILE5, Link FSUIPC_IN, Offset $3c0d, Length 1 // 5th letter of Airplane name
Var 0145, name AIRFILE6, Link FSUIPC_IN, Offset $3d00, Length 1 // 1st letter of Airplane name in FSX
Var 0146, name AIRFILE7, Link FSUIPC_IN, Offset $3d01, Length 1 // 2nd letter of Airplane name
Var 0147, name AIRFILE8, Link FSUIPC_IN, Offset $3d02, Length 1 // 3rd letter of Airplane name
Var 0148, name AIRFILE9, Link FSUIPC_IN, Offset $3d03, Length 1 // 4th letter of Airplane name
Var 0149, name AIRFILE10, Link FSUIPC_IN, Offset $3d04, Length 1 // 5th letter of Airplane name
Var 0150, name AIRFILE11, Link FSUIPC_IN, Offset $3d05, Length 1 // 6th letter of Airplane name
Var 0151, name AIRFILE12, Link FSUIPC_IN, Offset $3d06, Length 1 // 7th letter of Airplane name
Var 0152, name AIRFILE13, Link FSUIPC_IN, Offset $3d07, Length 1 // 8th letter of Airplane name
Var 0153, name AIRFILE14, Link FSUIPC_IN, Offset $3d08, Length 1 // 8th letter of Airplane name
Var 0154, name AIRFILE15, Link FSUIPC_IN, Offset $3d09, Length 1 // 10th letter of Airplane name
Var 0155, name AIRFILE16, Link FSUIPC_IN, Offset $3d0a, Length 1 // 11thletter of Airplane name
Var 0156, name AIRFILE17, Link FSUIPC_IN, Offset $3d0b, Length 1 // 12letter of Airplane name
Var 0157, name AIRFILE18, Link FSUIPC_IN, Offset $3d0c, Length 1 // 13thletter of Airplane name
Var 0158, name AIRFILE19, Link FSUIPC_IN, Offset $3d0d, Length 1 // 14th letter of Airplane name
Var 0159, name AIRFILE20, Link FSUIPC_IN, Offset $3d0e, Length 1 // 15thletter of Airplane name
Var 0160, name AIRFILE21, Link FSUIPC_IN, Offset $3d0f, Length 1 // 16th letter of Airplane name
// Variables for LevelD
Var 0081, name IAS_Lvld
Var 0082, name VS_Lvld
Var 0083, name ALT_Lvld
Var 0084, name APP_Lvld
Var 0085, name N1_Lvld
Var 0086, name SPD_Lvld
Var 0087, name VNAV_Lvld
// Variables for PM
Var 0070, name IAS_PM
Var 0071, name VS_PM
Var 0072, name ALT_PM
Var 0073, name APP_PM
Var 0074, name N1_PM
Var 0075, name SPD_PM
Var 0076, name AT_PM
Var 0077, name AP_L_PM
Var 0078, name AP_C_PM
Var 0079, name AP_R_PM
Var 0114, name LOC_PM
Var 0115, name LNAV_PM
Var 0116, name VNAV_PM
Var 0117, name HDG_PM
Var 0118, name FLCH_PM
Var 0119, name MACH_PM
// Standard- or Non-Standard Planes?
Var 0057, name PMDG // PMDG
Var 0056, name LVLD // LevelD
Var 0058, name PSS // PSS Airbus
Var 0059, name PF // Project Fokker
Var 0054, name Std // Standard Plane
Var 0055, name PM // Project Magenta
Var 0063, name FeelThere // FeelThere Airbus
Var 0064, name APL_Lvld // Autopilot L LevelD
Var 0065, name APC_Lvld // Autopilot C LevelD
Var 0066, name APR_Lvld // Autopilot R LevelD
Var 0067, name FLCH_Lvld // FlightLevelChange LevelD
// LevelD: read MPC status from FSCONV 5.5.
// Thanks to Nico Kaan for his great work!
// www.nicokaan.nl (http://www.nicokaan.nl)
Var 0092, name LvlD_Flg, Link FSUIPC_IN, Offset $8BAC, Length 4
{
&APL_Lvld = TESTBIT &LvlD_Flg, 2
&APC_Lvld = TESTBIT &LvlD_Flg, 3
&APR_Lvld = TESTBIT &LvlD_Flg, 4
&VNAV_Lvld = TESTBIT &LvlD_Flg, 9
&FLCH_Lvld = TESTBIT &LvlD_Flg, 10
&VS_Lvld = TESTBIT &LvlD_Flg, 12
&ALT_Lvld = TESTBIT &LvlD_Flg, 13
&APP_Lvld = TESTBIT &LvlD_Flg, 15
&N1_Lvld = TESTBIT &LvlD_Flg, 17
&SPD_Lvld = TESTBIT &LvlD_Flg, 18
}
Var 0095, name PMDG_Flg, Link FSUIPC_IN, Offset $62BC, Length 4
{
// &VS_PMDG = TESTBIT &PMDG_Flg, 24
// &ALT_PMDG = TESTBIT &PMDG_Flg, 23
&APP_PMDG = TESTBIT &PMDG_Flg, 21
// &N1_PMDG = TESTBIT &PMDG_Flg, 15
// &SPD_PMDG = TESTBIT &PMDG_Flg, 16
// &CMD_A_PMDG = TESTBIT &PMDG_Flg, 8
&CMD_B_PMDG = TESTBIT &PMDG_Flg, 9
// &CWS_A_PMDG = TESTBIT &PMDG_Flg, 25
// &CWS_B_PMDG = TESTBIT &PMDG_Flg, 26
}
// *** For ProjectMagenta Users:
Var 0080, name PM_Flg, Link FSUIPC_IN, Offset $04F0, Length 2
{
&IAS_PM = TESTBIT &PM_Flg, 9
&VS_PM = TESTBIT &PM_Flg, 2
&ALT_PM = TESTBIT &PM_Flg, 3
&APP_PM = TESTBIT &PM_Flg, 4
&N1_PM = TESTBIT &PM_Flg, 10
&SPD_PM = TESTBIT &PM_Flg, 9
&AT_PM = TESTBIT &PM_Flg, 11
&AP_L_PM = TESTBIT &PM_Flg, 0
&AP_C_PM = TESTBIT &PM_Flg, 1
&AP_R_PM = TESTBIT &PM_Flg, 13
&LOC_PM = TESTBIT &PM_Flg, 5
&LNAV_PM = TESTBIT &PM_Flg, 6
&VNAV_PM = TESTBIT &PM_Flg, 14
&HDG_PM = TESTBIT &PM_Flg, 7
&FLCH_PM = TESTBIT &PM_Flg, 8
&MACH_PM = TESTBIT &PM_Flg, 15
}
// Variables for PMDG
// Thanks for the Offset List to shadow.sp@gmx.net, http://members.chello.at/spatat/pmdg.htm (http://members.chello.at/spatat/pmdg.htm)
Var 0091, name IAS_PMDG, Link FSUIPC_IN, Offset $621E, Length 2 // PMDG:is IAS_HOLD active? 0=arm,1=speed,2=n1
Var 0088, name ALT_PMDG, Link FSUIPC_IN, Offset $622A, Length 2 // PMDG: is ALT hold active? Values from 1 to 9
Var 0089, name AP_PMDG, Link FSUIPC_IN, Offset $6226, Length 2 // PMDG: is AP active 0=off,256=cws,512=cmd
Var 0090, name VS_PMDG, Link FSUIPC_IN, Offset $6230, Length 2 // PMDG: is V/S active?
Var 0093, name APP_PMDG
Var 0094, name CMD_B_PMDG
// Var 0097, name N1_PMDG
Var 0098, name SPD_PMDG
Var 0047, name IAS // is IAS_HOLD active?
Var 0049, name ALT_hold // ist ALT_HOLD active?
Var 0050, name APP // Autopilot APP-mode
Var 0051, name N1 // Autopilot N1-mode
Var 0052, name SPD // Autopilot Speed-hold-mode
Var 0053, name VS // Autopilot V/S-mode
// Variables for Standard Planes
Var 0019, name Pause, Link FSUIPC_IN, Offset $0262, Length 2 // is Pause mode active?
Var 0021, name ALT_STD, Link FSUIPC_IN, Offset $07D0, Length 4 // Standard planes: AutoPilot ALT hold active?
Var 0022, name IAS_STD, Link FSUIPC_IN, Offset $07DC, Length 4 // Standard planes: is IAS_HOLD active?
Var 0029, name APP_STD, Link FSUIPC_IN, Offset $07FC, Length 4 // is Glideslope hold active?(GS and APP exchanged!!)
Var 0030, name TOGA, Link FSUIPC_IN, Offset $080C, Length 4 // is TO/GA switch active?
Var 0048, name MACH, Link FSUIPC_IN, Offset $07E4, Length 4 // is MACH_HOLD active?
Var 0039, name AP, Link FSUIPC_IN, Offset $07BC, Length 4 // is AutoPilot MasterSwitch active? Att: not in PSS & PM!!
Var 0040, name GS, Link FSUIPC_IN, Offset $0800, Length 4 // is ApproachMode active? (GS and APP exchanged!!)
Var 0020, name Trim_to_FS, Link FSUIPC_OUT, Offset $0BC0, Length 2 // Send value of PitchTrim to FS
Var 0023, name Lever2_to_FS, Link FSUIPC_OUT, Offset $0932, Length 2 // Send value of Lever2 to FS
Var 0024, name Lever1_to_FS, Link FSUIPC_OUT, Offset $089A, Length 2 // Send value of Lever1 to FS
// Var 0023, name Lever2_to_FS, Link FSUIPC_OUT, Offset $3332, Length 2 // Send value of Lever2 to FS
// Var 0024, name Lever1_to_FS, Link FSUIPC_OUT, Offset $3330, Length 2 // Send value of Lever1 to FS
Var 0031, name EngineNumbers, Link FSUIPC_IN, Offset $0AEC, Length 2 // how many engines has the plane?
Var 0032, name Lever3_to_FS, Link FSUIPC_OUT, Offset $09CA, Length 2 // Send value of Lever3 to FS
Var 0033, name Lever4_to_FS, Link FSUIPC_OUT, Offset $0A62, Length 2 // Send value of Lever4 to FS
Var 0097, name LEVER_START // Motor for levers should start
Var 0096, name ELEV_START // Motor for elevator trim should start
Var 0068, name lever2_diff // difference where the Lever2 is and where it should be
Var 0069, name lever1_diff // difference where the Lever1 is and where it should be
Var 0027, name corr_Trim_pos // Where ElevTrim should be (corrected to potentiometer values)
Var 0028, name trim_diff // difference where the Trim is and where it should be
Var 0013, Link FSUIPC_IN, name L1_target, Offset $088c, Length 2 // FSX: Where Lever1 should be
// Var 0123, Link FSUIPC_IN, name L1_target_9, Offset $089a, Length 2 // FS9: Where Lever1 should be
// Var 0013, Link FSUIPC_IN, name L1_target, Offset $3330, Length 2 // Where Lever1 should be
{
// because the potentiometer differ in value, we align the potentiometer value to the leverlength
L0 = &Lever1_upper - &Lever1_idle // Upper Potentiomer Value - Idle Potentiomer Value
L1 = 12800 / L0 // Distance Pot = 128 * 100 because in SIOC are no decimal values possible
&Pot1_factor = L1
L0 = &Lever1_Pot - &Lever1_idle // Corrected value from Pot to FS
L1 = L0 * &Pot1_factor // apply length lever to pot
L1 = L1 / 100 // same as above, because of no decimal value possible
L2 = &L1_target / 128
&Lever1_diff = L1 - L2 // where the lever is and where it should be
IF &LEVER_START = 1 // A/T is on
{
IF &Flusi = 8
{
&Leverdiscon = 192 // Disconnect both LeverPotentiometers from FS
}
CALL &MOTOR_LEVER // subroutine for motor motion
}
}
Var 0012, Link FSUIPC_IN, name L2_target, Offset $0924, Length 2 // FSX: Where Lever2 should be
// Var 0122, Link FSUIPC_IN, name L2_target_9, Offset $0932, Length 2 // FS9: Where Lever2 should be
// Var 0012, Link FSUIPC_IN, name L2_target, Offset $3332, Length 2 // Where Lever2 should be
{
L0 = &Lever2_upper - &Lever2_idle // Upper Potentiomer Value - Idle Potentiomer Value
L1 = 12800 / L0 // Distance Pot = 128
&Pot2_factor = L1
L0 = &Lever2_Pot - &Lever2_idle // Corrected value from Pot to FS
L1 = L0 * &Pot2_factor
L1 = L1 / 100
L2 = &L2_target / 128
&Lever2_diff = L1 - L2
IF &LEVER_START = 1 // A/T is on
{
IF &Flusi = 8
{
&Leverdiscon = 192
}
CALL &MOTOR_LEVER // subroutine for motor2 motion
}
}
Var 0018, Link FSUIPC_IN, name Trim_target, Offset $0BC2, Length 2 // Where Elevator Trim should be
{
IF &Trim_target > 33000
{
L0 = 81918 - &Trim_target // Trim down (49153 .. 65535)
L1 = L0 / 128 // 65535 + 16383 = 81918
L1 = TRUNC L1
}
ELSE
{
L0 = 16383 - &Trim_target // Trim up (0 .. 16383)
L1 = L0 / 128
L1 = TRUNC L1
}
&corr_Trim_pos = L1
&trim_diff = &corr_Trim_pos - &Trim_Pot
}
Var 0006, name Lever1_Pot, Link USB_ANALOGIC, Input 1, PosL 0, PosC 127, PosR 254 // Lever1 Pot position
{
L0 = &Lever1_upper - &Lever1_idle // Upper Potentiomer Value - Idle Potentiomer Value
L1 = 16383 / L0 // Distance FS = 16383
L1 = TRUNC L1
&Lever1_factor = L1
L0 = &Lever1_Pot - &Lever1_idle // Corrected value from Pot to FS
L1 = L0 * &Lever1_factor
L1 = TRUNC L1
IF &LEVER_START = 0 // A/T is OFF
{
&lever1_motor = 0 // motor stops
&Leverdiscon = 0 // Connect both LeverPotentiometers to FS
IF &EngineNumbers <= 2 // here we look how many engines the plane has
{
&Lever1_to_FS = L1 // Send Lever1 Position to FS
}
IF &EngineNumbers = 4
{
&Lever1_to_FS = L1 // Send Lever1 Position to FS
&Lever2_to_FS = L1 // Send Lever2 Position to FS
}
}
}
Var 0007, name Lever2_Pot, Link USB_ANALOGIC, Input 2, PosL 0, PosC 127, PosR 254 // Lever2 Pot position
{
L0 = &Lever2_upper - &Lever2_idle // Upper Potentiomer Value - Idle Potentiomer Value
L1 = 16383 / L0 // Distance FS = 16383
L1 = TRUNC L1
&Lever2_factor = L1
L0 = &Lever2_Pot - &Lever2_idle // Corrected value from Pot to FS
L1 = L0 * &Lever2_factor
L1 = TRUNC L1
IF &LEVER_START = 0 // A/T is OFF
{
&lever2_motor = 0 // motor stops
&Leverdiscon = 0 // Connect both LeverPotentiometers to FS
IF &EngineNumbers <= 2 // here we look how many engines the plane has
{
&Lever2_to_FS = L1 // Send Lever2 Position to FS
}
IF &EngineNumbers = 4
{
&Lever3_to_FS = L1 // Send Lever3 Position to FS
&Lever4_to_FS = L1 // Send Lever4 Position to FS
}
}
}
Var 0008, name Trim_Pot, Link USB_ANALOGIC, Input 3, PosL 0, PosC 128, PosR 254 // Trim Potentiometer position
{
L0 = &Trim_Pot * 128
L1 = 16383 - L0
IF &ELEV_START = 0 // Trimwheel steered by hand
{
&Trim_to_FS = L1 // send Trimwheel to FS
&elevator_motor = 0 // Elevator motor stops
}
}
Var 0120, name Lever_Elevator, Link SUBRUTINE // Subroutine for Lever and Trim Motor movement
{
// Detection if Standard- or Non-Standard-Plane
&PM = 0
IF &PM_Flg >= 1
{
&PM = 1 // PM started
}
IF &PM = 0
{
&PMDG = 0
IF &AIRFILE1 = 80
{
IF &AIRFILE2 = 77
{
IF &AIRFILE3 = 68
{
IF &AIRFILE4 = 71
{
&PMDG = 1 // Plane is PMDG
}
}
}
}
&lvld = 0
IF &Flusi = 7 // FS2004
{
IF &AIRFILE1 = 76 // l
{
IF &AIRFILE2 = 86 // v
{
IF &AIRFILE3 = 76 // l
{
IF &AIRFILE4 = 68 // d
{
&lvld = 1 // Plane is LevelD767
}
}
}
}
}
IF &Flusi = 8 // FSX
{
IF &AIRFILE7 = 101 // E
{
IF &AIRFILE8 = 118 // V
{
IF &AIRFILE9 = 101 // E
{
IF &AIRFILE10 = 108 // L
{
&lvld = 1 // Plane is LevelD767
}
}
}
}
}
&PSS = 0
IF &AIRFILE1 = 80 // P
{
IF &AIRFILE2 = 115 // S
{
IF &AIRFILE3 = 115 // S
{
IF &AIRFILE4 = 65 // A
{
&PSS = 1 // Plane is PSS Airbus (PSSA)
}
}
}
}
&FeelThere = 0
IF &Flusi = 7 // FS2004
{
IF &AIRFILE13 = 114 // r
{
IF &AIRFILE14 = 101 // e
{
IF &AIRFILE15 = 32
{
IF &AIRFILE16 = 65 // A
{
&FeelThere = 1 // Plane is FeelThere Airbus
}
}
}
}
}
IF &Flusi = 8 // FSX
{
IF &AIRFILE13 = 114 // r
{
IF &AIRFILE14 = 101 // e
{
IF &AIRFILE15 = 32
{
IF &AIRFILE16 = 65 // A
{
&FeelThere = 1 // Plane is FeelThere Airbus
}
}
}
}
}
IF &PMDG = 1 // PMDG Airplane
{
// &IAS = &IAS_PMDG
// &N1 = &N1_PMDG
// &ALT_hold = &ALT_STD // AP of PMDG often switches off ALT_HOLD so we use STD instead
IF &IAS_PMDG >= 1
{
&IAS = 1
}
ELSE
{
&IAS = 0
}
&APP = &APP_PMDG // ist APP_PMDG APP
&VS = &VS_PMDG
IF &ALT_PMDG >= 1
{
&ALT_hold = 1
}
ELSE
{
&ALT_hold = 0
}
}
IF &LVLD = 1 // LevelD Airplane
{
&IAS = &IAS_Lvld
&ALT_hold = &ALT_Lvld
&APP = &APP_Lvld
&N1 = &N1_Lvld
&SPD = &SPD_Lvld
&VS = &VS_Lvld
&IAS = &VNAV_Lvld
}
IF &PSS = 1 // PSS Aibus
{
&IAS = &IAS_STD // In this time all are Standard
&ALT_hold = &ALT_STD // but shortly we will find adresses for PSS
&APP = &GS // PSS uses GS instead of APP (or vice versa?)
}
IF &Std = 1 // Standard Airplane
{
&IAS = &IAS_STD
&ALT_hold = &ALT_STD
&APP = &APP_STD
}
}
IF &PM = 1 // Project Magenta
{
&IAS = &IAS_PM
&N1 = &N1_PM
&SPD = &SPD_PM
&ALT_hold = &ALT_STD // MCP often switches here to 0 but it should remain 1 !! So we use STD and not PM
&APP = &APP_PM
&VS = &VS_PM
}
&Std = 0
IF &PMDG = 0
{
IF &LVLD = 0
{
IF &PSS = 0
{
IF &PF = 0
{
IF &PM = 0
{
&Std = 1 // FeelThere in the moment is standard plane
}
}
}
}
}
// Start Relais for FeelThere
IF &FeelThere = 1
{
&Relais = 120
}
ELSE
{
&Relais = 0
}
// now we look if the levermotors should start or stop
&LEVER_START = 0
IF &Pause = 0
{
IF &PSS = 0 // Airbus has no Motorized Throttles !!
{
IF &FeelThere = 0
{
&LEVER_START = 1
}
}
}
IF &IAS = 0
{
IF &MACH = 0
{
IF &TOGA = 0
{
IF &FLCH_Lvld = 0 // When FLCH is set, LevelD switches SPD to 0, so Throttles would stop
{
IF &N1 = 0
{
IF &SPD = 0
{
&LEVER_START = 0
}
}
}
}
}
}
// now we look if the elevator motor should start or stop
IF &Pause = 0
{
IF &AP = 1
{
&ELEV_START = 1
}
ELSE
{
&ELEV_START = 0
}
}
ELSE
{
&ELEV_START = 0
}
IF &ALT_hold = 0 // ALT hold is on
{
IF &APP = 0 // APP hold is on
{
IF &VS = 0 // V/S mode is on
{
IF &AP_L_PM = 0 // all AP of PM are off
{
IF &AP_C_PM = 0
{
IF &AP_R_PM = 0
{
IF &AP_PMDG = 0 // Autopilot PMDG is off
{
IF &APL_LvlD = 0 // Autopilot LevlD is off
{
IF &APC_LvlD = 0
{
IF &APR_LvlD = 0
// {
// IF &AP = 0 // Autopilot Standard is off
{
&ELEV_START = 0 // Elevator Motor stop
}
// }
}
}
}
}
}
}
}
}
}
IF &ELEV_START = 1 // Elevator Motor should start
{
CALL &Motor_Elevator // subroutine for motor motion
}
}
Var 0125, name Motor_Lever, Link SUBRUTINE // USB_DC controls motors for Lever1&2
// Motor control 0-127 = left; 129-255 =Right; 0 stops
{
L0 = &lever1_diff
L1 = 0
IF L0 < 0
{
L1 = 128 // Motor run direction
}
L0 = ABS L0
L2 = ¤t_run1 + L1 // Lever1 Motor runs with full current
IF L0 <= &break_dist1
{
L2 = ¤t_break1 + L1 // Lever1 Motor runs with break current
}
L0 = ABS L0
IF L0 <= &dead_area1
{
L2 = 0
}
IF &LEVER_START = 0
{
L2 = 0 // Lever1 Motor stops
}
&lever1_motor = L2
L0 = &lever2_diff
L1 = 128
IF L0 < 0
{
L1 = 0
}
L0 = ABS L0
L2 = ¤t_run2 + L1 // Lever2 Motor runs with full current
IF L0 <= &break_dist2
{
L2 = ¤t_break2 + L1 // Lever2 Motor runs with break current
}
L0 = ABS L0
IF L0 <= &dead_area2
{
L2 = 0
}
IF &LEVER_START = 0
{
L2 = 0 // Lever2 Motor stops
}
&lever2_motor = L2
}
Var 0130, name Motor_Elevator, Link SUBRUTINE // USB_DC controls motor for Elevator
// Motor control 0-127=left, 128 stops, 129-255=right
{
L0 = &trim_diff
IF &Flusi = 7 // FS2004
{
IF L0 < 0
{
L1 = 128
}
ELSE
{
L1 = 0
}
}
IF &Flusi = 8 // FSX
{
IF L0 > 0
{
L1 = 0
}
ELSE
{
L1 = 128
}
}
L0 = ABS L0
L2 = ¤t_break3 + L1
IF L0 <= &break_dist3
{
L2 = ¤t_run3 + L1
}
L0 = ABS L0
IF L0 <= &dead_area3
{
L2 = 0
}
IF &ELEV_START = 0 // Motor Elevator trim stop
{
L2 = 0
}
&elevator_motor = L2
}
After looking at this, people can stop telling me how outdated EPIC is. Looks just like the code for my EPIC.
Hessel,
Thank you so much for posting that. I am still confused, but looking over it, it is beginning to make more sense. My dad writes code for a living, so he might be able to help me.
Just out of curiosity... you say that this code allows for manual override of the autothrottle even within FS? Can that be done with any airplane? If I don't care about manual override, is that something that if I left it out would make writing the code easier?
Also, could you please elaborate a little bit on what it means when it says "Standard Airplane" vs "Non Standard Airplane"?
Thanks again,
Matt
Matt,
Here is the file that was missing.
I tested it and it worked.
Hessel
///////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//
//
//
// SIOC A/T file for B767 Level-D,
// Lekseecon (www.lekseecon.nl (http://www.lekseecon.nl)),
// FS2004 version.
//
// V. 1.0
//
// Hessel Oosten (BoeingBrown), the Netherlands.
// As always (!) thanks to Nico Kaan (Kiek) for his great help.
//
// 1 (= realistic !) DC_motor version.
//
//
//
// Introduction and comments.
//
// This comments do far extend the length of the whole file below...
// The reason is, that i.m.o. so many files are too cryptic (for me)
// to understand them...
// Hope some people do like these extensive comments...
// And remember, deleting this part only takes a few milliseconds ...
//
//
// Starting with some constants:
// lev1(or2)_max. The max thrust position of your lever.
// lev1(or2)_idle. The idle possition of your lever.
//
// Remember that full thust in FS is 16384 and full reverse is -4096.
// In total 20480 range. So 4094 is 20 %, the rest 80 %.
// In general, keep these ratio in mind (look at the values).
//
// The A/T (when correcting the hardware lever) initially runs fast to the
// target position (speed_fast).
// When more nearby the tartget it enters the range_slow were the running
// speed is reduced to speed_slow.
// To reduce unnecessary motion due to pot spikes etc. in the dead_area the
// lever does not react on sporadic impulses.
// The values can be tuned to your liking.
//
// The scale of FS values (see above) is not equal to the values the pot
// produces in the range of the lever.
// A correction factor must calculate lever(so pot)values to FS values:
// lev1(or 2)_FS_cf (lever1 to FS correction factor).
//
//
// The scale of FS values (see above) is not equal to the values the motor
// wants to see.
2
// The DC motor runs on a scale of 1 - 127 (more and more faster),
// 128 is stop and 129 - 255 is again more and more faster BUT the turn
// is now inverse.
// A correction factor must calculate the FS value (16384) to the motor scale
// (x (e.g. left) or (x + 128, right).
// We use FS_mot1_cf: FS to motor1 correction factor.
//
// Then comes the Var pot1(or2)_value. This is in fact the Var belonging to your
// physical potmeter, link USB_ANALOGIC.
// Here the actual pot position is calculated by subtracting the actual position
// pot1(or2)_value from the "zero position" : lev1(or2)_idle.
// This outcome is multiplied with the correction factor.
// We can't return decimal values to FS so the outcome is TRUNCated to integers
// and then send it to FS (Lev1(or2)_to_FS). Remember to calibrate your physical
// pot 0,128 and 255 values to what you find with a hardware lever attached
// and probably make it a few points smaller on both sides. Eventually
// calculate a new center position by dividing this found range by 2.
//
// When the A/T is functioning the potmeters will be used for measuring the
// hardware lever position. This lever position is compared with the software
// position in FS.
// If there is a difference the hardware lever will be moved by the motor.
// For disconnecting the pots as manual instruments and using them for A/T
// feedback the Var: Lever1discon, Link FSUIPC_OUT, Offset $310A, Length 1
// is used (see FSUIPC for Programmers manual).
//
// When the ATSwitch is armed this lever1_(or2)_discon Var is set to 192,
// when A/T is OFF to 0. Can't reproduce the origin of value 192 in the
// "FSUIPC for Programmers" manual, but it works...
//
// When ATSwitch = 1 and Lever1(or2)discon = 192 the program starts the actions
// for motor function. But before doing this Pause is checked.
// You won't burn your motor while you are drinking coffee in the room
// downstairs ...
//
// The Fs_to_Lev1 (FS value towards lever1) is read from FSUIPC.
// The actual pot value is calculated by subtracting the actual value from
// the idle value.
// This value is multiplied by the motor correction factor from before and
// divided by 100 (was multiplied by 100 before).
// This value now, is our actual lever position in FS values.
//
// Also is calculated the target FS position as read in FS (L2).
// Now the difference is calculated between these two. The value is TRUNCated
// to have only integers.
// Then the routine is called which will make from the difference (see before) a
// value which the motor can understand (left or right and speed).
//
// This lev1_to_Mot routine looks is the difference is pos or negative and
// stores that position in another local Variable (L1 = 0 or L1 = 128).
3
// Then the speed (L2) is is taken (speed_fast or speed_slow) and (0 or 128) is
// added for the direction of the turn.
// If the hardware lever is very nearby the target the hardware levers enters
// the dead area and the speed (L2) is ordered zero.
// At last the chosen speed and direction (all included in L2) is send to the
// USB_DCMotor.
// The pause function was already mentioned before.
Var 0000 value 0
{
&lev1_max = 220
&lev1_idle = 60
// &lev1_min = 20 // not used, educational
&lev2_max = 220
&lev2_idle = 60
// &lev2_min = 20 // not used, educational
&speed_fast = 100
&speed_slow = 40
&range_slow = 15
&dead_area = 10
call &lev1_FS_cf
call &lev2_FS_cf
call &FS_mot1_cf
}
Var 1001 name lev1_max
Var 1002 name lev1_idle
// Var XXXX name lev1_min // not used, educational
Var 1003 name lev2_max
Var 1004 name lev2_idle
// Var XXXX name lev2_min // not used, educational
Var 1005 name speed_fast
Var 1006 name speed_slow
Var 1007 name range_slow
Var 1008 name dead_area
Var 1009 name lev1_FS_cf
{
L0 = &lev1_max - &lev1_idle
L1 = 16383 / L0
L1 = TRUNC L1
4
&lev1_FS_cf = L1
}
Var 1010 name lev2_FS_cf
{
L0 = &lev2_max - &lev2_idle
L1 = 16383 / L0
L1 = TRUNC L1
&lev2_FS_cf = L1
}
Var 1011 name FS_mot1_cf
{
L0 = &lev1_max - &lev1_idle
L1 = 12800 / L0
L1 = TRUNC L1
&FS_mot1_cf = L1
}
Var 1012 name lev1_to_Fs link FSUIPC_OUT Offset $089A length 2
Var 1013 name lev2_to_Fs link FSUIPC_OUT Offset $0932 length 2
Var 1014 name pot1_value link USB_ANALOGIC Input 1 PosL 0 PosC 128 PosR 255
{
L0 = &pot1_value - &lev1_idle
L0 = L0 * &lev1_FS_cf
L0 = TRUNC L0
&lev1_to_FS = L0
}
Var 1015 name pot2_value link USB_ANALOGIC Input 2 PosL 0 PosC 128 PosR 255
{
L0 = &pot2_value - &lev2_idle
L0 = L0 * &lev2_FS_cf
L0 = TRUNC L0
&lev2_to_FS = L0
}
Var 1016 name Lever1discon Link FSUIPC_OUT Offset $310A Length 1
Var 292 name ATSwitch Link IOCARD_SW Input 9 Type I
{
IF &ATSwitch = 1
{
&lever1discon = 192
}
ELSE
{
&lever1discon = 0
}
5
}
Var 1017 name FS_to_lev1 link FSUIPC_IN Offset $089A length 2
{
IF &ATSwitch = 1
{
IF &pause = 0 // GO, so no pause today
{
L0 = &pot1_value - &lev1_idle
L1 = L0 * &FS_mot1_cf
L1 = L1 / 100
L2 = &FS_to_lev1 / 128
L0 = L1 - L2
&levs1_diff = TRUNC L0
call &Lev1_to_Mot
}
}
ELSE
{
&MOTOR = 0
}
}
Var 1018 name levs1_diff
Var 1019 name Lev1_to_Mot link subrutine
{
L0 = &levs1_diff
L1 = 0
IF L0 < 0
{
L1 = 128
}
L2 = &speed_fast + L1
L0 = ABS L0
IF L0 <= &range_slow
{
L2 = &speed_slow + L1
}
IF L0 <= &dead_area
{
L2 = 0
}
&MOTOR = L2
}
Var 1020 name MOTOR link USB_DCMOTOR output 1
Var 1021 name pause link FSUIPC_IN Offset $0262 length 2
{
6
IF &pause = 1
{
&MOTOR = 0
}
}
// end
Hessel
Many thanks - those comments are worth their weight in gold :)
David
Matt,
The best thing is to read, read, read, experiment, and read some more. :)
Niko's site is the best place to get some basic info, it helped me on the few things I've programmed, and I'm still an amateur. Good luck and may the force be with you. ;)
Cheers,
Rand
Does anyone know where I can find the list of FSUIPC offsets? I am reading through Opencockpit's info on SIOC and they say to reference the list for the offsets and last time I checked, I couldn't find them. If anyone has the list, or knows where I can find it, I would really appreciate it!
Regards,
Matt
Matt
D/L the FSUIPC SDK 29th release file from Peter Dowson`s website. Within that .zip file is a file called FSUIPC4 Offsets status.pdf
That has a complete list of offsets
David
Thanks David.
Regards,
Matt
Alright, another question:
Do the pots for my throttle axes need to be attached to the Opencockpits DC Motors card? Or can they be attached to Leo Bodnar's BUO836X and still work with the opencockpits card?
Regards,
Matt
Matt
You can use both options, though the Bodnar card will give you greater accuracy ie 10/12 bits as against the 8 for OC
See this link - it explains how to use Bodnars cards with FSUIPC and SIOC
David
http://www.mycockpit.org/forums/showthread.php/21881-Using-BU0836X-and-other-BU0836-cards-with-SIOC-scripts?highlight=bodnar
Matt,
SIOC needs to have feedback from the throttles, because it should know where the throttles are at that particular moment. The difference between that position and the "wished" position (by the A/T) is calculated when the A/T is ON. After that throttlemotor is started to make the difference go back to zero.
So (see before) SIOC needs analogue input from the throtles. The throtttles do this by means of the position of the potmeters which are attached to the throttles.
So it makes no sense to attach the pots to other inputs than to analogue inputs of Open C. cards.
Of course it is not obligatory to attach them to the analogue inputs of the DC motor card. Every O.C. card on which analogue inputs are attached will do.
Hope this helps.
Hessel
Hessel
But surely, by using the method in the link you can have much greater accuracy. SIOC limits you to 256 steps, which on a typical throttle lever sweep wil give you a movement of .5mm per step. I would much rather have the greater accuracy of a 10/12 bit a/d.
David
Hi David,
I had missed your VERY usefull information completely.
Was not aware of this in-direct route, but it seems very logical if processed ib this way.
Thanks, good to know !
Hessel
Hessel
Glad to help :)
The OC analogue ports are not the most stable and tend to jitter quite badly, even on a reasonably smoothed power supply. This can be so bad that, for example on my overhead, the jittering on the air temp pots triggered so much sioc code in response that other inputs were being missed. You can of course programme in a dead zone but on 8 bit accuracy you are also going to struggle a little, especially when you add in physical backlash on the gearing.
Regards
David
Quote from: Hessel Oosten on January 17, 2011, 01:02:21 AM
Hi David,
I had missed your VERY usefull information completely.
Was not aware of this in-direct route, but it seems very logical if processed ib this way.
Thanks, good to know !
Hessel
Hey guys,
So please enlighten me... what is the "in-direct" route? It sounds to me like it is much preferred to have the pots attached to the BUO836X board because it has more accuracy, so can it be done so that the OC motors card gets info from the BUO836X card? I'm just a little confused by the last 2 posts!
Thanks,
Matt
Haha just kidding... I too missed your response David! Sorry about that!
Matt
Alright so I just read the link David posted on using Bodnar's card with the OC card and it raised a question for me....
In order to do this, you need to assign the axis as an FSUIPC offset, right? Well, normally when I calibrate my axes on the TQ, I have sent the axis direct to "FSUIPC Calibration". So will this change the function of the throttle lever? Will they still be able to be calibrated through FSUIPC to function as a normal axis when the A/T is not engaged? Does my question make sense?
I appreciate your guys' help very, very much! This is actually beginning to make some sense!
Matt
Matt
I have not got to this stage of my build, so it may be best to await further advice. However, it seems to me that with the throttle positions going to an offset and that offset being used by SIOC to control throttle movement, then there is no calibration by FSUIPC - all control being exercised by SIOC code. I could be wrong :)
David
David
So then do you think that the throttles will still be able to be operated manually when the A/T is not engaged?
Here is another option I thought of... do you think it would work to attach the pots to BOTH the 836X and the DC motors card? That way, I could still manage the calibration in FSUIPC with the 836X for manual operation and the DC motors card would also get pot inputs to send to SIOC?
Even though you are not at this stage, I appreciate your advice since it is helping to increase my own understanding!
Matt
@ Matt,
You CAN manually override the (engaged) A/T BUt therfore in the axis a slipclutch is necessary (and realistic). If the clutch was not there you should have to fight against the motor.
@ David,
I wondered if the compression of the high resolution of the Bodnar card numbers can fade awy if the numbers have to be compressed to the +/- 128 in SIOC OR .. is this not he case.
Hessel
Hessel,
Actually, my question refers more to the calibration of the throttle axes than the physical movement. I have a slip clutch setup, so yes, physically I can move them manually. However, I am wondering how I calibrate the throttles if I use the Bodnar card and assign them as an offset instead of doing calibration through FSUIPC?
Matt
Hessel
As SIOC is not reading the throttle position from an analogue port, but taking a value from an offset then it would not be limited to the +/- 128 of the SIOC read analogue function.
Matt
Do not try to link the pots to both SIOC and Bodnar ports - I would expect you to introduce all manner of electrical surprises and feed back loops.
David
Matt
You can control the whole movement of the throttles through coding in SIOC to include start and finish positions. What is your worry about calibration?
David
David,
I guess my worry is that I am comfortable with calibrating within FSUIPC and I really don't know or yet understand how the calibration works through SIOC...
Matt
Matt
Then stay with Bodnar/FSUIPC joystick axis. Though you will then need to recode the SIOC examples as you will be reading the throttle position from an offset and not the OC analogue ports. Six of one and half a dozen of the other :)
In reality you are going to need to understand coding in SIOC whichever way you go :(
David
David,
See that leaves my head spinning a bit again. I didn't think you could chose FSUIPC calibration of the joysticks attached to the Bodnar card if you select the axis as an FSUIPC offset for SIOC to read? That's where my confusion stems from. In FSUIPC, once you identify the joystick axis, you have to pick one of 3 options: 1) send to FS as normal axis 2) send to FSUIPIC calibration or 3) set as FSUIPC offset.
Do you mean that SIOC will be reading the throttle positions from a DIFFERENT FSUIPIC offset? I know there are throttle position offsets in the FSUIPC offset list, is this what you are referring to when you say "you will be reading the throttle positon from an offset and noth the OC analogue ports"?
Also, what do you mean "six of one and half a dozen of the other"?
If what you're saying is that I need to write a whole new code (compared to the example Hessel posted) I am actually not to worried about that. I have been doing a lot of reading on SIOC and I actually feel like I have an alright understanding thus far of how programming the motors through SIOC works. What I am confused about now is calibrating the joysticks AND having them give the proper inputs to SIOC.
Sorry if my questions are redundant or stupid! Thanks for all your help.
Matt
Matt
I advised in an earlier thread that my build had not yet progressed to coding the throttles, so what I am about to say may not be 100% :)
If you choose FSUIPC Axis Calibration then the only way SIOC can know where the throttles are is by using one of FSUIPC`s built in offets from the list - assuming there is one. In which case you will need to recode the SIOC example to suit
Else, you choose FSUIPC Axis Offset and alter your SIOC code also, which will include defining the start and finish positions within SIOC coding ie calibration
Hence whichever route you go you will need to code in SIOC - ie 6 of one or half a dozen of the other - you cannot avoid some SIOC coding :(
My best advice is to play around with trying to control the throttles thru SIOC - learn, adapt and perfect :) you will need a dark room to escape to on occasions
David
Edit You do not need to write a whole new SIOC code - just read, understand how Hessel`s one worked and then amend to suit your needs, thats how nearly all of us do it - build on someones earlier work
Question: is the Phidgets DC motor card easier to work with than the OC DC motors card?
Matt
It may be only you who can answer this, as it depends on your abilities and grasp of computer languages. Whichever route you go, it is unlikely that you will find an earlier piece of programming that will run your throttles without some modification. I suggest that you carefully analyse the logic flow that is needed to achieve what you want. Then read both the SIOC and Phidgets manuals/examples to check if they have all the commands you will need. Then assess which one you think suits your skills best and/or is best supported
Alternatively, there may be someone on here who has sound experience of both and can advise from a position of knowledge
David
Alright, this is probably a REALLY stupid question with an obvious answer, but I still can't manage to find the answer anywhere in the Opencockpits Manuals... how do I know if I need extra power to run my motors? I have 2, 12V motors, but again, I cannot find in the manual where it says whether or not I need to connect extra power and if I do, how do I do that?
Also, do I need to be running FS while running SIOC while editing the code in order for it to work? Also, does SIOC need to be open whenever I play flight sim for the motors to work?
And one more question: I have decided to do the Offset through FSUIPC thing and then have the throttles set though SIOC. I understand now that I will still get the same calibration, just though SIOC code instead of in FSUIPC. But that raises another question: what part of the code that Hessel posted gets changed to reflect the fact that the throttle positions are not coming from the analog OC connections but are instead coming from the FSUIPC offset? Does that make sense?
I have now been playing around with this (hooked up the motors and card tonight) for the last few hours and have gotten nowhere. It doesn't help that all the OC manuals seem to have been run though an online translator and make very little sense!
Regards,
Matt
Hi Matt,
no expert on O/C,ad alook at the USBmotors Manual.Page 3 says J2 is for dc volts to motors.In your case 12v must be connected here.The manual shows a connection diagram for the board and P/S connections for Motors are shown. Has to be a seperate supply to enable high Voltage motors to be run.
Current would be to high to be powered from USB port if they were 5v.Also you will Have a file in your SIOC directory named sioc.ini.In here you have to tell it what number your USBmotors card is and how many cards you have.It says about this in the manual.I dont have the motors card but have the stepper and this is similar.
Hope this helps.
Les
alright, so next question is where can i find a DC 12V power source? i am not at all familiar with the hookups on this board for the power supply. Is this something that will plug into the wall? Or does it attach to the computer?
Matt,
If you have an old computer PSU laying around that's a good source for 12vdc and 5vdc.
Cheers,
Rand
Matt
"what part of the code that Hessel posted gets changed to reflect the fact that the throttle positions are not coming from the analog OC connections but are instead coming from the FSUIPC offset"
From reading the SIOC manual and studying the code, you can see that the read analogue port function gives a range of the throttle`s minimum, centre and end positions - that determines how far the throttle can move according to the code. You now need to establish the FSUIPC offset that is holding the Bodnar A/D converter value (instead of the analogue function) give it a variable name and then find out by moving the throttles what the values are at the extremes of movement. Then you introduce some code to limit movement within the physical constraints of the throttle housing.
Suppose that when the throttle is at its end stop and the Bodnar card (through the FSUIPC Offset) is returning a value of say 16,000 - then you introduce some code that says
if commanded throttle movement value > 16000 then throttle movement value = 16000
Always make sure that power is only applied to the motors when your SIOC proggramme is running, unless you have a physical clutch installed that will stop the motor burning out if it reaches the end stops and your coding is incorrect :(
Some advice :)
Your only way to succeed with SIOC is to dive in , read the manual thoroughly - I mean thoroughly! and start coding by using simple examples from Nico Kaans site. Building on that practical understanding you can progress to amending the motor control coding. There is no simple short cut. To be fair to your forum colleagues, you need to demonstrate a basic/good degree of understanding SIOC concepts before asking questions on advanced coding.
Sorry if this is blunt, but I hope you appreciate that it is offered in the spirit of helping you achieve what you want
David
Thanks guys for the advice. I'm gonna see if I can find an old PSU.
David,
While I appreciate, and understand to a degree, your bluntness about needing to understand SIOC, in my own defense, I will state that I spent nearly 4 hours last night combing through the manuals and looking at Nico's site. The manuals provided by Opencockpits, I think you will agree, are very difficult to understand because of the translation. Not only that, things like the power supply are not really covered. Given that, it seems to me there are large holes of information that are very hard to find.
Nico's site is an amazing wealthy of information and clarified some things for me, but many of his examples really are the basics for writing 1 code (like the parking brake). I am trying to write much, much more advanced code that involves several variables working together. I spent all evening last night looking at and trying to comprehend Hessel's code. I understand a lot of it, but I also am confused by some of it. Considering that I do not need a trim wheel motor and I am not running any special software, like PM, I wonder if I would just be better off trying to write a code from scratch that I would actually understand lol.
Matt
I am not doubting that you have read the manual, but the best way to learn is to try some simple examples first. Code for controlling dc motors and the associated interfacing with FSUIPC is advanced stuff for a beginner.
What SIOC manuals are you reading - I ask because I have a number of different ones which may be able to make some things clearer to you
David
Matt, I don't want to go over old ground here but have you looked at the dedicated program written by Diego Viso on My Cockpit. It's called DVATX and controls both the throttles, speed brake and trim wheels. It's also designed to use the Phidgets DC motor cards and Pot sliders.
If you haven't spent any money yet it is worth investigating, everything is controlled and calibrated from a single screen. No coding to do at all. The only down side is the cost of all the Phidget controllers etc. which are considerably more than the OC cards.
Just a thought, I hope I haven't made things worse for you. :idiot:
Cheers
Joe.
Matt,
As David said, it's wise to study more. That's much more than 4 hours. That's weeks, for all of us.
Several members are writing here, but sometimes due to the fact that you did not enough (till now :-) study/homework.
Even with helpers around the world, the last thing you have to do yourself in most circumstances!
On the Opencockpits site are LOTS of English documents, even VERY nice powerpoint's etc.
Manuals of the cards are in English too there (but some search is necessary). Agree that the site is not well organized.
In the fora HUNDREDS of code examples of all kind (and all in SIOC linguage).
You are confused by the trimwheel, BUT in the second code I provided in this thread there is not even a trimwheel included ! So please re-read.
Furthermore it simply works if attached to a small DC motor and SIOC and is dedicated to your (!) plane.
So, accept that this a not an "hours" project. Read, re-read and try small steps (!) with patience.
Hessel
Hessel,
Yes, I reread your second post and it did make sense to me. My one question about that second code is will it work with 2 motors? I know the realistic motorized throttles only use 1 motor, but my setup requires 2 motors, one for each lever. I assume that the second code you posted can be adapted to 2 motors?
One more question, for anyone, not regarding SIOC but in regards to a power source for the DC motors card... I have 2 12V motors attached to the card, does that mean I need a 24V power source? Or will a 12V source work to power both motors? I ask because when I wired my LED's on my overhead, using the 5V on the 836X card, I needed to split those 5V among 3 LED lights, so I was curious if it's the same thing with the motors.
In the meantime, I will try to stop asking so many questions and rebury myself in the SIOC stuff for a while. I see frustration on the horizon lol. Hopefully followed by success.
Thanks guys,
Matt
Quote from: matta757 on January 23, 2011, 08:19:43 AM
I assume that the second code you posted can be adapted to 2 motors?
I have 2 12V motors attached to the card, does that mean I need a 24V power source? Or will a 12V source work to power both motors?
Matt,
The second code can be adapted for 2 motors. All commands for motor 1 can be copied to a motor 2. In fact, it's "about the same" as the first code but to make it more simple for study ..:-), this is for 1 motor.
(That stays complete aside from the "more realistic one motor drives all" discusssion which has several problems with the software systems, NOT doing that.)
If you have 12 V motors you can (hmm in theory) drive 1000 motors on a 12 V power supply.
The limitation is the power of the powersupply is in Watt's. Watt = Volt x Ampere.
So e.g. if you motor takes 1 ampere at 12 Volts the power supply needs to be 12 x 1 = 12 Watt AND about 50 % more to be sure. You can calculate this for 2 motors ...:-). Let's not start discussions here about these educational sentenses...:-).
Asking this last question proves that you also need to study more basic electricity. Really !
Not doing this makes your motors and power supply AND your expensive electronic cards ready for a big smoke !
So in conclusion. People are willing to help. But people are getting reluctant if the questions have a toooooo wide range e.g. "my motor does not work, please help".
Better is a far more specific question in which is also stated what you already have done to solve the problem.
Don't start to be the "
king of questions" ...:-).
Hessel (seriously trying to help).
Hessel,
Thanks for the advice. You wouldn't happen to have your 1-motor code in a TXT file, would you? I guess I could just copy it into notepad too, but last time I tried that and imported it, it didn't work. I have made significant progress today in the sense that I now have SIOC seeing my pots and seeing the difference they need to move the levers.
Don't worry, I am done asking questions. I'll just muscle though it. You guys have been a big help though. I have a friend who is really good with electrical stuff, so I should be able to figure out how to properly wire the power source.
Matt
Yes, you can copy it in simply in Notepad.
Maybe that, due to the layout of this forum, there are some hidden characters added ?
So copy it in Notepad as experiment with "save as" and the different "types" e.g. txt and not ANSI.
H.
Ok, i did save it as a TXT file before and it still didn't read it properly when imported into SIOC, but I will try it again and see what happens!
Matt,
See attachment.
(same as in this thread; nothing new).
H.
thanks Hessel!