SIOC pas à pas

troisième édition

Mais avant d'oaborder la programmation SIOC, quelques précisions concernant les cartes IOCards elles-mêmes, leur présentation, leurs fonctions et leur montage, ne sont pas superflues.

1 - le montage d'une carte Master

Première étape: ... déballer le matériel Cliquer sur les images pour les agrandir.	Le circuit imprimé de la Master: l'emplacement des composants est imprimé. Cliquer sur cette image pour avoir les dimensions de la carte Master.	Commencer par souder les composants les plus petits: les 72 diodes 1N4148 et les 9 résistances 6,8 Ko (bleu, gris,rouge) Ne pas passer plus d'une seconde sur chaque soudure pour éviter toute surchauffe de composant. Evitez autant les soudures trop grosses, qui risquent d'établir ces court-circuits avec les pistes voisines, que les soudures "sèches" qui cachent un mauvais contact avec le composant supposé soudé.
Bien vérifier que tous les traits noirs des diodes sont du bon côté. Le sens des résistances n'a aucune importance, mais pour l'esthétique on les met dans le sens qui permet de lire normalement le code des couleurs.	Souder ensuite les supports de circuits intégrés, non fournis par Opencockpits car non indispensables, mais fortement recommandés. Bien respecter la position de l'encoche, imprimée sur le circuit . Souder deux pattes du support, et vérifier qu'il est bien appliqué à fond sur le circuit imprimé avant de souder les autres.	Souder enfin les composants les plus gros: les connecteurs d'entrée et sortie. Remarquez la position de l'encoche des connecteurs 40 broches. La position des broches 1, 2, 39 et 40 est marquée sur le circuit imprimé. Notez-la, car après montage du connecteur elle n'est plus visible.

Bien évidemment, le montage de la carte d'interface USB suivra exactement les mêmes étapes que celui de la carte Master. Le circuit imprimé nu est de la même excellente qualité que celui de la Master.	On commencera par souder les composants les plus petits: résistances, condensateurs, puis supports de circuits intégrés. A noter que le condensateur C1 donné pour 220 nF (ou 0,2 µF) sur la nomenclature est fourni en O,1 µF, c'est cette dernière valeur qui est la bonne.
La diode LED est soudée (attention à son sens de branchement, à l'envers elle n'éclairera pas): si la diode a un méplat, il doit être orienté vers la prise USB. Les connecteurs sont en place.	La carte USB terminée

On voit ici un câble en nappe équipé de 3 connecteurs HE10 femelle, la pince à sertir, et quelques connecteurs en attente

Un connecteur HE10 mâle: ici seuls les 9 premiers fils sont connectés. Il ne faut jamais souder les fils directement sur les broches, mais souder les broches sur un bout de circuit imprimé d'essai à pastilles, et les fils sur ce circuit.

La carte Master et la solution barrettes-relais à vis, très pratique.

Pourquoi SIOC ?

SIOC est un langage de programmation très puissant, permettant d'agir sur toutes les fonctions internes de Flight Simulator, d'effectuer toutes les opérations simples, mais aussi d'incorporer dans un cockpit des fonctions logiques complexes, des temporisations, etc...

On pourra ainsi facilement créer des fonctions du genre "j'allume une alarme clignotante si la vitesse est inférieure à 130 Kts , si le train est rentré, si les volets sont sortis".

Tous les cockpits peuvent être entièrement commandés par SIOC, du Cessna à l'Airbus, sans aucun logiciel ou carte autre que IO Card, à la seule condition que l'avion utilisé soit un standard de Flight Simulator, c'est à dire qu'il utilise les "variables" connues de FS, ce qui est le cas de la grosse majorité des add-on , mais exclut complètement les avions de PMDG, PSS, Wilco, qui utilisent des variables inconnues. Ces avions ne peuvent pas être utilisés dans un cockpit, quel qu'il soit.

SIOC pour qui ?

Nico Kaan, un réalisateur de cockpit néerlandais très connu, dit "même à des débutants, je recommande d'utiliser SIOC ... " Il est vrai qu'il ajoute "il est bien sûr préférable d'avoir quelques notions en programmation informatique..." (Avsim, 14 mars 2006)

En fait, les notions de programmation ne sont pas vraiment indispensables, ce qui compte avant tout, la seule chose qui soit vraiment indispensable est d'avoir un esprit logique. Quand on sait exactement ce qu'on veut obtenir, ce qui suppose de bien connaître l'avion qu'on modélise, on peut facilement décrire une fonction, définir tout ce qu'il lui faut pour agir, et dès lors transposer ce cahier des charges en SIOC est assez simple.

Les nuls peuvent aussi examiner les fichiers de programmation SIOC (les .ssi) d'autres utilisateurs, les comparer, essayer, c'est sans aucun risque et très instructif.

Comment fonctionne Flight Simulator ?

Flight Simulator fonctionne en interne avec des "variables" qui transportent les instructions pour toutes ses fonctions, et pas seulement ce qui concerne le vol. Peter Dowson a réussi à décortiquer le code de Flight Simulator et a identifier ces variables. A partir de là, il nous est possible de les sélectionner et de les modifier dans un logiciel comme SIOC, et de les transmettre à FS par l'intermédiaire de FSUIPC, il suffit de leur donner une "adresse" et elles y vont ...

La liste des variables de Flight Simulator figure dans les documents à télécharger de ce site, et également sur le site de Peter Dowson. Il y en a des centaines, mais pas de panique, si nous oublions les variables définissant la météo, les coordonnées géographiques, ou des caractéristiques physiques d'un avion, ce qui entre réellement dans un cockpit est beaucoup plus réduit.

SIOC : le principe

Quand le pilote ferme l'interrupteur incorporé dans la manette de train pour le sortir , cet interrupteur établit un contact entre une des 72 entrées de la carte Master et la masse "GND" du groupe correspondant (voir plus haut). L'entrée de la carte Master ainsi mise à la masse change d'état -elle était auparavant à +5Volts, elle passe à 0 V, et SIOC, toujours à l'affut de ce qui se passe, détecte immédiatement ce changement d'état. La programmation SIOC propre à notre avion a été prévue pour dire " si cette entrée change d'état, il faudra immédiatement changer la valeur de la variable du train.
Une variable a non seulement une adresse dans Flight Simulator, mais aussi une valeur mathématique. Certaines ne connaissent que deux valeurs possibles, 0 ou 1, d'autres peuvent avoir n'importe quelle valeur, comprise par exemple entre 0 et 16384. C'est le cas des volets par exemple, si on donne à sa variable la valeur 8192, les volets s'arrêteront à mi-course.

Les cartes IOCards discutent avec Flight Simulator par l'intermédiaire de FSUIPC. SIOC peut aussi utiliser FSUIPC et les "variables" classiques. Mais il peut aussi utiliser sa propre interface, appelée IOCP ou "protocole" IOCP, qui fait exactement la même chose que FSUIPC, un peu plus rapidement . Ne compliquons pas les choses, FSUIPC nous ira très bien, même pour faire un cockpit complexe.

Les programmeurs remarqueront qu'il n'y a pas un programme SIOC pour tout un cockpit, mais des multitudes de petits programmes mis bout à bout, qui fonctionnent indépendamment. Ce qui est très pratique pour essayer interrupteur après interrupteur.

SIOC est par défaut au repos, et n'agit que si un "évènement" nouveau se produit, par exemple un interrupteur qu'on vient de fermer. De ce fait, SIOC est très rapide et très peu gourmand en ressources.

Quels logiciels faut-il installer ?

Après avoir chargé sur le site de OpenCockpits (section downloads), ou au chapitre "Téléchargements" de SimuCockpit.com la dernière version de SIOC, on décompresse le tout dans un même dossier , en principe Program Files / IOCards. C'est un peu fouillis, mais on va faire un raccourci sur le bureau pour sioc.exe, le plus important.

Un coup d'oeil rapide.

Pour que les choses soient plus parlantes, lançons d'abord Flight Simulator.

Lançons maintenant sioc.exe, la fenêtre ci-dessous s'affiche.

Elle est très claire, on y voit d'abord le rappel de la version de SIOC utilisée, ici la 3.5.

IOCards Module nous indique que cette carte est bien branchée (running) .

Le paragraphe en dessous FSUIPC Module, nous confirme entre autres que FSUIPC version 3.75.0 est bien en marche. Ici, FS2004 est utilisé, mais SIOC fonctionne aussi bien avec FSX.

Oublions pour le moment les cases "IOCP" , qui nous suggèrent que IOCP peut agir comme un "serveur" avec des "clients", ce qui veut dire, entre autres, que SIOC peut fonctionner avec plusieurs ordinateurs, sans utiliser WideFS de Peter Dowson.

La fenêtre USB Devices est importante: elle rappelle que sur mon cockpit j'utilise une carte Master, qui porte le numéro d'Index 0 et le numéro de "Device" 85, ainsi qu'une carte USB Outputs, Index 1 et Device 84. Nous consacrerons un chapitre à ces choses bizarres.

Dans la bande bleue en bas se trouve quelque chose de beaucoup plus intéressant:

c:\Program Files\IOCards\SIOC.ssi

Les fichiers .ssi sont les fichiers de programmation qu'utilise SIOC, créés par chaque utilisateur pour chaque avion.

Un coup d'oeil dans Program Filles \ Iocards et effectivement on trouve ce fichier... qui est vide.

C'est simplement pour le cas où vous voudriez appeler votre fichier .ssi "sioc.ssi" il suffira à chaque changement d'écraser le précédent en gardant le même nom. Mais si vous préférez appler votre .ssi "mon_avion.ssi" c'est tout aussi bien. Vous avez vu d'ailleurs que quand on a décompressé le dossier sioc.exe de nombreux .ssi , comme "ejemplo_displays.ssi" , se sont créés. Ce ne sont que des exemples. Pour retrouver plus facilement nos petits, il n'est pas inutile d'afficher les nombreux fichiers de Program Files \IOCards en les classant par type.

Ce qui nous amène à jeter un oeil sur le fichier d'initialisation sioc.ini, toujours dans le même Program Files \IOCards.

Ce petit fichier texte doit comprendre l'indication du fichier .ssi à utiliser, c'est TRES IMPORTANT .

Exemple:

[SIOC]
IOCP_port=8090
IOCP_timeout=4000
Minimized=No
toggle_delay=20
CONFIG_FILE=.\SIOC.ssi

Remarquez le .\ devant le nom du fichier .ssi. Si donc vous changez de nom de fichier .ssi il ne faut pas oublier de modifier le fichier sioc.ini pour lui indiquer le nouveau nom de .ssi à utiliser.

Par défaut, SIOC.exe s'ouvre avec le fichier .ssi enregistré dans sioc.ini, et lors de sa première utilisation, il ouvre le fichier "sioc.ssi"

Remarquez aussi que ce fichier .ini concerne également IOCards classique, FSUIPC, etc... il regroupe plusieurs modules (mais pas tous les modules possibles).

Enfin dans la série des boutons, très pratiques, on trouve:

RELOAD: à utiliser à chaque fois qu'on a enregistré une modification dans notre fichier .ssi, pour transmettre effectivement la nouvelle configuration à Flight Simulator.

CONFIG appelle le fichier .ssi signalé dans sioc.ini, pour le modifier, par exemple. Dans notre cas, si nous cliquons dessus, nous allons avoir un avis "Blank File" puisque pour le moment notre sioc.ssi est vide. Profitons de cette visite à Config pour sélectionner l'anglais ou l'espagnol dans le menu Languages.

IOCP Console appelle le vérificateur de fonctionnement du même nom, nous verrons cela plus tard.

TRAY envoie la fenêtre SIOC dans la barre des notifications, à droite de la barre des tâches.

EXIT vous indique le chemin de la sortie ...

Un premier essai avec SIOC.

Vous êtes impatient de voir ce que donne SIOC sur votre cockpit. Nous allons donc tout bêtement recopier un petit programme existant, et l'essayer. Cet exercice va nous permettre de voir comment on peut transformer un fichier de programmation sous forme de texte en un fichier .ssi utilisable par SIOC.
Disons tout de suite que cette procédure est surtout utilisée pour débuter, on copie et on essaye, mais que par la suite on créera directement un fichier .ssi, sans passer par la phase texte, ce qui sera beaucoup plus simple.

Importons un petit fichier texte intitulé essai_1 Une page de choses bizarres s'affiche, c'est un fichier SIOC sous forme de texte, il s'agit ici d'une commande de volets à trois positions:

// *****************************************************************************
// * Config_SIOC ver 3.5 - By Manolo Vélez - www.opencockpits.com
// *****************************************************************************
// * FileName : essai_1.txt
// * Date : 18/05/2008

Var 0001, name FLAPS, Link FSUIPC_INOUT, Offset $0BDC, Length 4 // Commande des volets

Var 0400, name FLAPS_UP_SW, Link IOCARD_SW, Input 33 // Volets position "Rentrés"
{
IF &FLAPS_UP_SW = 1 // inter en position volets "rentrés"
{
&FLAPS = 0 // valeur pour volets rentrés
}
ELSE // autrement (pos APPR ou DN)
{
&FLAPS = 8191 // valeur pour position "Approche"
}
}

Var 0401, name FLAPS_DN_SW, Link IOCARD_SW, Input 34 // Volets position "sortis"
{
IF &FLAPS_DN_SW = 1 // inter sur volets sortis
{
&FLAPS = 16383 // valeur pour volets sortis
}
ELSE // autrement (pos APPR ou UP)
{
&FLAPS = 8191 // valeur pour position "approche"
}
}

Faites CTRL A pour tout sélectionner, puis CTRL C pour copier. Dans Démarrer/Tous les programmes/ Accessoires, ouvrez le bloc notes et faites CTRL V pour copier ce texte .

Vérifiez bien une chose importante: quand on importe de cette manière un fichier ssi sous forme de texte, il arrive que des lignes soient tronquées: au lieu d'avoir une ligne

Var 0001, name FLAPS, Link FSUIPC_INOUT, Offset $0BDC, Length 4 // Commande des volets

on parfois, quand la place manque, un retour à la ligne intempestif, du genre:

Var 0001, name FLAPS, Link FSUIPC_INOUT, Offset $0BDC, Length 4 // Commande des volets à
trois positions, pour Beech 200

A éviter absolument car lorsqu'une ligne, ici la deuxième, commence par autre chose qu'une variable ou un //, SIOC prend cela pour un ordre de programmation à exécuter, et n'y comprend plus rien. Donc toujours vérifier que les lignes sont complètes.

Notre fichier texte ayant une bonne tête, nous l'enregistrons sous le nom essai_1.txt dans Program Files / IOCards.

Dans la fenêtre de SIOC, cliquons sur le bouton CONFIG. Config_sioc s'ouvre sur la page blanche de sioc.ssi. Nous allons créer un autre sioc.ssi à partir de notre fichier essai_1.txt.

Cliquons sur Files puis sur Import TXT .

Choisissons notre fichier essai_1.txt et le temps d'un clic nous avons deux choses: d'abord un "log de compilation" :

On y voit que la "compilation" ou transformation d'un fichier texte en programme, s'est faite en trois phases, c'est toujours les cas, et que tout est OK, on y voit surtout un OK vert rassurant en bas, signe que tout s'est bien passé. Une croix rouge signifierait par exemple qu'on a oublié de copier un bout du fichier essai_1 et peut être qu'une parenthèse } est passée à la trappe, ou que nous avions un retour à la ligne intempestif. Cela arrive souvent quand on copie un bout de programme de quelqu'un.

Note1: on a remarqué que la transformation d'un fichier texte en programme (la "compilation") s'est faite automatiquement : le bouton COMPILER de la page Config_SIOC de fait ne sert pas à grand chose...
Note 2: Créer un programme SIOC en tapant directement du texte est une entreprise un peu risquée. Les informaticiens font cela les yeux fermés, les autres se font à coup sûr des croche-pieds dans les { et les }...faute d'avoir bien compris le principe de l'arborescence des commandes. Pour créer un nouveau .ssi ou ajouter des choses à un existant, il est beaucoup plus sûr de travailler dans la page .ssi de Config_SIOC, ce que nous ferons systématiquement dans ce tutoriel.

Deuxième chose, fermons le log de compilation devenu inutile en cliquant sur OK, et nous retrouvons notre texte dans la fenêtre SIOC, mais sous une forme différente: il est devenu un .ssi.

Prenons l'habitude de l'enregistrer, comme nous le ferons à chaque fois qu'un fichier .ssi aura été modifié : Files /Save as, et on lui donne le nom de sioc.ssi fichier qui, désormais, ne sera plus vide.

Si vous fermez puis ouvrez de nouveau sioc.exe, vous constaterez que SIOC s'ouvre avec le dernier fichier .ssi utilisé, c'est pratique.
Pour consulter un fichier .ssi sans ouvrir SIOC, il est également possible de double cliquer dessus dans l'Explorateur de Windows.

Est-ce qu'on peut maintenant essayer ce .ssi dans FS ? Non, pas tout de suite, car les interrupteurs de volets de votre cockpit sont certainement sur d'autres entrées de la carte Master que celles prévues dans cet exemple de .ssi

A la ligne de la variable 0400, nous voyons "Input 33 " C'est le numéro de l'entrée sur la carte Master, qu'il faut modifier si cela ne correspond pas à vos attributions d'entrées.

Si vous voulez faire cette modification, double-cliquez sur la ligne de la variable 400 : il apparaît une nouvelle fenêtre très pratique, la fenêtre des Paramètres:

Dans les données IOCards (IOCards Data) nous avons le numéro de l'entrée initialement sélectionnée, 33. Nous pourrions indiquer une autre entrée au lieu de 33, mais pour notre exemple 33 nous ira très bien. Après cette opération, l'arborescence de la variable 400 a disparu dans le fichier .ssi, pour la revoir il suffit de cliquer sur le + qui la précède. Dans le menu See on peut aussi choisir de déployer ou de comprimer l'affichage.

Enregistrons d'abord cette modification dans le fichier sioc.ssi ( Files/Save) puis cliquons sur le bouton RELOAD de SIOC pour envoyer les nouvelles données à Flight Simulator.

Dans FS, actionnons le levier de volets: les volets fonctionnent avec leurs trois positions (si vous avez un B737, cela bougera quand même...)

Nous allons maintenant utiliser ce petit programme pour entrer dans les détails.

Les variables de SIOC

Des variables liées.

Les Var400, Var401, etc... qu'on voit dans notre fichier .ssi sont des variables propres à SIOC, définies comme le souhaite l'utilisateur. Ces variables SIOC peuvent être liées à pas mal de choses (d'où le mot Link qui revient souvent) :

- on peut les lier à FSUIPC, donc leur demander d'agir sur un offset de la liste de Peter Dowson, et ce dans tous les sens: la variable SIOC va:

envoyer (ou écrire) une information à FSUIPC, (la variable est alors précédée d'une icône "FS -> UIPC" qui s'installe automatiquement) ce sera une variable "liée" à FSUIPC OUT,

elle peut aussi recevoir (ou lire) une information de FSUIPC (icône "FS<-UIPC" ou FSUIPC IN ),

ou sera prête à faire les deux, cas le plus courant (icône "FS<->UIPC", FSUIPC INOUT)

Note: on emploie le plus souvent le nom de "variable" , mais on rencontre aussi le nom "offset", pour désigner la même chose.

- une variable SIOC peut aussi être "liée" à un élément physique de IOCards: une entrée sur sa carte Master, comme les variables commandant les interrupteurs, ou une sortie (LED), ou un afficheur (Display) , ou une carte additionnelle comme la carte Servos, la carte Stepper, etc... La variable est précédée dans ce cas d'une icône "carte verte", c'est le cas de nos variables 400 et 401, liées à "IOCard Switches".

- une variable SIOC peut également être liée à un module IOCP (icône "<- -> IOCP" (à voir plus tard...)

- enfin une variable SIOC peut être liée à rien du tout, et dans ce cas le changement de valeur de la variable en question n'agira que sur elle-même. Une variable non liée est précédée d'un carré blanc.

Comment définir un numéro de variable ?

SIOC peut admettre 9999 numéros de variables, numéros définis par l'utilisateur.

Comme il y a de la place entre 0000 et 9999, on créera des "classes" de variables, ce qui permettra d'ajouter facilement des variables nouvelles, et de faciliter la lecture du code.

Un exemple de classification (parmi beaucoup d'autres):

Lecture: une variable liée à IOCards, avec conditions IF et ELSE.

Les lignes qui suivent sont très intéressantes:

Nous avons physiquement un commutateur rotatif à trois positions, un interrupteur en fait, branché sur les entrées 33 et 34 de notre carte Master.

Ce petit bout de programme SIOC , qu'on appelle un script, commande la position des volets avec ce commutateur.

C'est le rôle tout d'abord de la variable que nous avons appelée 400 ou mieux "FLAPS_UP_SW" . Cette variable est liée à "SWITCHES" dans la liste déroulante des Links, et tout naturellement, nous avons 33 comme numéro d'entrée Input. Vous pouvez cliquer sur la ligne Var 0400 pour revoir ces paramètres.

Les lignes en dessous se lisent de la manière suivante:

" Si (IF) la variable FLAPS_UP_SW a une valeur 1, (c'est à dire si l'interrupteur est "fermé"), alors la variable FLAPS (la $0BDC) doit prendre la valeur 0 " . Ceci correspond à la valeur de $0BDC quand les volets sont en position UP ou complètement rentrés.

Autrement dit, et pour être le plus clair possible, l'interrupteur sur la 33 étant le commutateur rotatif 3 positions en position volets rentrés (UP) , cet interrupteur est fermé, et les volets se mettent en position rentrés. S'ils y sont déjà, il ne se passe rien, la variable n'a pas changé de valeur, SIOC reste en sommeil.

La ligne en dessous définit alors ce qui se passe quand cet interrupteur est ouvert (levier des volets ailleurs que sur la position" rentrés", c'est à dire soit sur la position intermédiaire "Approche", soit sur la position basse "sortis") :

"Autrement (ELSE) la variable FLAPS doit prendre la valeur 8191 ", c'est à dire volets en position Approche.

Bien entendu quand le levier des volets est en position Full Flaps tout sorti, c'est l'interrupteur de la variable 403 FLAPS_DN_SW, relié à l'entrée 34 qui entre en jeu:

Ce qui se lit:" la variable FLAPS_DN_SW est liée à un interrupteur relié à l'entrée 34 de la carte Master (position volets pleinement sortis)",
SI cette variable FLAPS_DN_SW a une valeur 1 c'est à dire que l'interrupteur est fermé, la variable FLAPS ($0BDC) prendra la valeur 16383 (volets sortis) , autrement (ELSE) ,c'est à dire si l'interrupteur est ouvert, et donc en position Approach ou Flaps UP, la variable FLAPS devra prendre la valeur 8191"

L'usage de IF et de ELSE permet ici d'éviter de définir trois positions de volets, avec seulement deux variables.

Ecriture: une commande de train avec IF et ELSE

Cet exemple va nous permettre de revoir les notions importantes exposées précédemment, et d'y ajouter la commande de LEDs de signalisation.

Notre fichier d'exemple se résume pour le moment à ceci:

Nous allons y ajouter une variable pour le train d'atterrissage, et les diodes vertes associées.

Pour ajouter une nouvelle variable à la fin de la liste, il suffirait de cliquer sur Edit / New Var. Ici, nous nous proposons de donner le numéro 010 à notre nouvelle variable, par conséquent on va l'insérer entre la 001 et la 400. Double-clic sur la ligne de la variable 400 pour la sélectionner, puis dans le menu Edit, on choisit Insert Var. La nouvelle variable, pour le moment un carré blanc, va s'insérer au dessus de la ligne sélectionnée. Cliquons sur le carré blanc, (flèche sur la capture ci-dessous), la page des paramètres apparaît:

Dans Link To, choisir: Fsuipc In/Out, Var num: 010, description Commande du train, Initial Value: on ne met rien, et en dessous ,VAR LINKED DATA, Var $0BE8 de longueur 4 pour l'offset de commande de train. OK . La variable de commande, toujours précédes de $, se trouve dans la liste de Peter Dowson (voir la page Téléchargements de SimuCockpit.fr).

Il serait souhaitable que le train soit sorti lorsqu'on démarre un vol, en principe au sol... Nous allons donc créer une variable d'initialisation, numéro 000, au dessus de la variable 001, avec Edit/Insert Var (on peut faire un clic droit).

On a choisi NOT LINKED, Variable n° 000, nom "INI" ou "INIT" comme vous voulez , description "variable d'initialisation" , OK.

Nous allons maintenant mettre une commande dans cette variable, pour obliger la variable de train à avoir la valeur 16383 au démarrage de SIOC.
La ligne Var 000 étant sélectionnée, Edit, New Command, double clic dans le cadre d'icône, et dans la fenêtre des paramètres, Command/ Type : Assign pour attribuer une action, puis dans le cadre Assign, Var: choisir dans la liste déroulante la variable GEAR que nous venons de créer et lui donner une valeur = 16383, qui correspond à la valeur de l'offset $0BE8 quand le train est entièrement sorti. Ce qui donne:

Il nous faut maintenant définir des variables SIOC pour les fonctions suivantes:

- allumage d'une LED rouge quand le train est en transit,
- allumage d'une LED verte quand le train avant est sorti,
- allumage d'une LED verte quand le train droit est sorti,
- allumage d'une LED verte quand le train gauche est sorti,
et bien sûr
- attribution d'une variable à l'interrupteur de la manette de train.

Nous allons donc créer 4 nouvelles variables, et comme elles doivent commander des LEDs, ces variables seront liées aux sorties OUT de la carte Master IOCard : Link to: IOCard Output ( variables avec l'icône "carte verte")
La dernière variable est liée à un interrupteur on choisira donc Link to: IOCard Switches

Les variables de LEDs ayant des numéros dans les 700 (choix tout personnel), elles seront à la fin de notre fichier .ssi actuel, donc ce sera Edit/New Var. Les numéros de sortie de la carte Master sont ici choisis au hasard.

Ce qui donne:

Vous remarquerez au passage que si vous oubliez d'indiquer le n° de sortie de la carte Master, la fenêtre refusera de se fermer. Des sécurités de ce genre sont nombreuses dans ce mode d'enregistrement d'un fichier .ssi, et c'est une raison majeure pour le préférer à l'enregistrement direct sous forme de texte. Par contre, vous pouvez enregistrer deux fois la sortie 36 par exemple, il est tout à fait possible de commander une même LED par deux variables.

Occupons nous d'abord de la variable 402 ou GEAR_SW, la manette de train.

Que voulons-nous ? Un petit tableau pour clarifier:

Passons à SIOC, attention aux clics :

1° sélectionner la ligne de la variable GEAR_SW
2° clic droit dessus et sélectionner New Command, et un nouveau cadre d'icône est créé, dont l'arborescence en pointillés indique bien que la condition que nous allons entrer concerne la variable GEAR_SW
3° double clic gauche dans le cadre d'icône et on a la page Parameters:

4° dans cette page, case "Type", choisir CONDITION IF, puis dans le paragraphe CONDITION, aller chercher dans la première liste déroulante GEAR_SW, puis dans la case suivante, mettons = , et enfin dans la dernière case, taper 1 puis OK

Ceci est la première condition "si l'inter de train est fermé ".

5° sélectionner cette nouvelle ligne "IF GEAR_SW=1" et faites un clic DROIT dessus : un nouveau cadre d'icône est créé, et l'arborescence en pointillés indique cette fois que ce que nous allons ajouter concerne bien la ligne IF GEAR_SW=1 (important à vérifier), et non par exemple la ligne de la variable 402 GEAR_SW

6° double clic sur le cadre d'icône, et choisir dans Type: ASSIGN et dans le paragraphe ASSIGN, aller chercher la GEAR et indiquer après = 16383

Nous avons écrit " si l'inter de train est sorti, la variable $0BE8 est égale à 16383"

Nous allons maintenant entrer la deuxième condition: ELSE. Cette condition est rattachée à la variable GEAR_SW, tout comme l'était la condition IF, c'est logique : si.... autrement.

7° sélectionner de nouveau la ligne de la variable GEAR_SW et faites un clic DROIT dessus: un nouveau cadre d'icône est créé, et l'arborescence en pointillés indique bien qu'il est relié à la variable GEAR_SW.

8° double clic sur le cadre d'icône, et choisir dans les paramètres CONDITION ELSE. Avec le paramètre ELSE on ne peut choisir aucune des cases de la fenêtre. Cliquons donc directement sur OK

9° clic DROIT sur ELSE et un nouveau cadre d'icône est créé, rattaché à ELSE

10° double clic dessus et choisir Type: ASSIGN , puis aller chercher dans la liste la variable GEAR et lui donner la valeur 0.

Nous avons écrit la deuxième partie de la phrase "autrement la variable $0BE8 sera égale à 0".

Ce genre de raisonnement, volontairement très détaillé ici, devient vite une habitude et la programmation est très rapide.

Nota: vous aurez remarqué dans les fenêtres de paramètres que le travail est bien préparé, quand une condition concerne une variable la liste de toutes les variables créées dans votre .ssi figure dans une liste déroulante, il n'y a plus qu'à cliquer. De même pour les signes = ou > etc...
Par contre dans la case suivante, là où nous devons écrire 1, ou 0 ou n'importe quelle valeur numérique, il faut évidemment la taper nous-mêmes, SIOC ne peut pas deviner ... Les valeurs préparées, L0, L1, C1 etc... seront utilisées plus tard.

Enregistrez ces modifications au .ssi, relancez SIOC avec le bouton RELOAD, et essayez cette commande de train dans Flight Silmulator, après avoir supprimé la variable $0BE8 et l'inter correspondant dans Config IOCards si vous utilisez conjointement IOCards classique.

L'affichage de la position du train: trois conditions IF et ELSE

L'exemple précédent , la manette de train, était relativement simple, le train est rentré ou sorti. Une seule condition IF et ELSE était attachée à la variable.

Nous avons préparé précédemment les variables 700 à 703 concernant les diodes LED d'affichage de la position du train, nous allons nous en servir.

Flight Simulator utilise plusieurs variables pour ce qui concerne le train:
- $0BE8 vu précédemment est la commande du train en elle-même, et correspond à l'interrupteur inclus dans la manette de train. Dans SIOC on aura donc un couple de variables très unies: la variable x pour $ 0BE8, plus la variable y pour son interrupteur.
- mais Flight Simulator dispose également de trois variables pour indiquer la position du train : $0BEC pour la position du train avant, $0BF0 pour celle du train droit, et $0BF4 pour la position du train gauche.
Le but étant d'allumer ou d'éteindre des diodes pour signaler la position des trois trains, nous allons de nouveau créer des couples de variables, qui vont concerner cette fois les variables captant la position du train d'une part, information fournie par FS, et les diodes branchées sur les sorties Output de la carte Master.

Nous avons déjà créé les variables 700 à 703 liées à une sortie Master, il nous reste à créer les variables liées aux variables de position. Nous y ajouterons par la même occasion une commande indiquant que le train est en transit, commande liée à la diode rouge, mais sans création d'une nouvelle variable, l'état ne sera déterminé que par l'état des autres variables.

Nos variables de "commande" étant classées dans la série 001 à 299, nous aurons ainsi:

Var 011 ou L_GR_POS, position du train gauche ($0BF4) associée à Var 701 ou L_GEAR_LED, diode verte du train gauche, agissant sur la variable Var 700 ou GEAR_TRANS_LED du transit.

Var 012 ou R_GEAR_POS, position du train droit ($0BF0) + Var 702 ou R_GEAR_LED, diode verte du train droit, agissant sur la variable Var 700 ou GEAR_TRANS_LED du transit.

Var 013 ou NOSE_GEAR_POS, position du train avant ($0BEC) + Var 703 ou NOSE_GEAR_LED, diode verte du train avant, agissant sur la variable Var 700 ou GEAR_TRANS_LED du transit.

Commencez par créer ces trois variables, nous y ajouterons ensuite leurs commandes associées. Nous pouvons commencer par créer la variable 013 NOSE_GEAR_POS pour $0BEC, en remarquant bien qu'il s'agit ici d'une variable liée à FSUIPC bien entendu, mais uniquement en entrée (Link To: FSUIPC In) puisque la variable reçoit des informations de la part de FSUIPC, mais ne lui transmet rien en retour. Nous insèrerons ensuite les variables 011 et 012.

Définition de ce qu'on veut obtenir, pour le train avant:

ce qui fait trois conditions IF, d'où un décalage de l'arborescence à chaque fois qu'une condition nouvelle est exposé, décalage symbolisé sur le tableau ci-dessus par un changement de colonnes.

Pour ajouter plusieurs attributions (Assign) à la suite, il suffit de faire plusieurs fois un clic droit sur la condition IF, et de choisir les ASSIGN nécessaires.

Transposons donc dans les commandes SIOC les fonctions définies par le tableau ci-dessus.

Il n'y a plus qu'à faire la même chose pour les variables de position train droit et gauche, et voilà ce que cela donne à la fin sur le fichier .ssi:

Remarquez en particulier le décalage d'un cran des arborescences à chaque fois que l'on passe à la condition suivante. En cas d'erreur d'ailleurs, SIOC refuserait de prendre en compte les nouveaux paramètres. Un IF et son ELSE correspondant sont toujours sur un même plan.
Dans cet exemple, nous avons pour chaque train une condition" IF le train est sorti" ... "ELSE le train n'est pas rentré". Et cette dernière condition est assortie elle-même d'une double analyse: "IF le train est en transit", ou" IF le train est rentré". Assez complexe, mais quand on a bien compris cela, tout le reste de SIOC devient limpide...

Qu'est-ce que cela donnerait en langage texte ? Cliquez sur File / Export to TXT, choisissez le nom essai_1.txt et enregistrez.

Nota: nous avons utilisé dans cet exemple des signes comme >=, ce sont des "opérateurs logiques". Vous en trouverez le détail un peu plus loin.

Enregistrez ce nouveau sioc.ssi et essayez-le dans FS (en faisant RELOAD dans SIOC) . C'est magique !

Variante: on peut aussi dire des choses comme "SI l'inter de batterie est ON, ET SI le moteur 1 est en marche, ET SI la génératrice 1 est sur OFF, ALORS l'alarme de charge batterie est sur ON. Cela fait trois IF pour une seule assignation, et cela s'écrit en décalant d'un cran à chaque fois chaque condition vers la droite.

Nota: la condition ELSE n'est pas strictement obligatoire après un IF, parfois on s'en passe.

La console IOCP

Jusque maintenant nous avons visualisé directement dans Flight Simulator le résultat de nos essais. C'est très bien quand il s'agit de vérifier le fonctionnement d'un train d'atterrissage, par contre, il y a des cas plus complexes, où on ne "voit" pas ce qui se passe.
Nous avons un excellent outil pour regarder ce qui se passe en profondeur dans FS: IOCP Console.

Ouvrez Flight Simulator, puis allez à la fenêtre principale de SIOC, cliquez sur le bouton IOCPCONSOLE, puis, dans la fenêtre qui vient de s'ouvrir, cliquez sur CONNECT.

La fenêtre indique alors l'état de toutes les variables que vous avez créées dans le fichier SIOC actuellement en service. Extrait de mon propre code pour Beech 200:

Nous pouvons lire que la variable 32 concernant le train d'atterrissage a une valeur décimale de 16383, qui correspond au train sorti. Bien entendu, si nous rentrions le train, la valeur passerait à 0.

Vous pouvez également cliquer sur LOG ON et vous aurez un journal de tout ce qui se passe dans votre FS (très pratique pour traquer des anomalies, elles sautent aux yeux).

Attardons-nous sur la colonne "Binary Value", pleine de 0 et de 1.

Vous savez que les variables de Flight Simulator, celles qui sont dans la liste de Peter Dowson, ont une "longueur" de 1, 2 ou 4.
Ce chiffre indique le nombre d'octets de la variable. Un octet, c'est une sorte de mot, constitué de 8 chiffres, les bits.
La colonne Binary Value comporte par défaut 32 zéros, c'est le nombre maximum de bits que peut comporter une variable FS, puisque les plus grandes ont 4 octets de 8 bits, soit 32 bits.
Quand une variable, ou offset, a deux octets, sa valeur binaire est affichée par 8 chiffres, commençant par la droite, et qui se lisent de droite à gauche (qui a dit "c'est de l'hébreu" ?) On peut numéroter les bits des octets, mais pour que ce soit plus drôle, le premier bit, celui le plus à droite, porte le numéro 0. Donc une variable de deux octets aura une forme:

00000000 00000000

et ces 16 bits en deux octets auront les numéros:

15, 14, 13, 12, 11, 10, 9, 8, et 7, 6, 5, 4, 3, 2, 1, 0

Tout ceci pour vous dire que les variables dites "booléennes" , celles qui ne connaissent que deux états, Ouvert ou Fermé, ou 0 ou 1, se contentent d'un seul bit, quand on allume une LED, la valeur binaire passe de 0 à 1, c'est tout.

C'est plus compliqué quand il s'agit d'afficher la valeur binaire de 16383, comme le train, voyez la succession de 0 et de 1, sur la capture d'écran ci-dessus. Comme la variable du train, $0BE8 a une longueur de 4 octets, soit 32 bits, en fait c'est toute la ligne de 0 et 1 qui indique la valeur binaire de cette variable à ce moment là.

Encore plus intéressant, il existe dans Flight Simulator la possibilité de changer la valeur d'une variable en agissant directement au niveau d'un bit.
Par exemple, la variable $0D0C s'intitule globalement "lights", si on change la valeur de son bit n°2, pour le passer de 0 à 1, les phares d'atterrissage s'allument. Si on touche au bit n°0, ce sont les feux de navigation qui s'allument, etc... Etrange, n'est-ce pas ?

Vous pouvez créer, à titre d'exemple, une nouvelle variable SIOC, en utilisant l'offset $3300 correspondant à la capture d'un LOC ou NAV ou Glide. Incorporez cet offset dans votre fichier .ssi, mettez l'avion en position d'interception d'un ILS, laissez-le faire, et regardez comment les valeurs décimales et binaires vont changer quand le LOC va être capturé. Vous verrez qu'un seul bit change à la capture du LOC, le bit n°8. Lorsque le Glide est capturé, c'est le bit n° 9 de cette même variable qui passe de 0 à 1.

Pour faire des essais, même en l'absence de Flight Simulator, IOCP Console permet d'entrer n'importe quelle valeur pour une variable. L'observation dans la colonne LOG de ce qui se passe permet de vérifier que les commandes prévues ont bien été exécutées.

Les variables locales

Il s'agit de variables temporaires, très pratiques pour simplifier l'écriture.
Il arrive fréquemment qu'une variable soit égale à une autre variable + une valeur fixe (ex: V508=V509 + 1000) ou résulte d'un calcul plus ou moins complexe.
Par exemple, la variable $07D4 mesure à tout instant l'altitude de l'avion. Sa valeur en soi ne signifie rien, si on veut obtenir l'altitude en pieds, il faut diviser la valeur de cette variable par 19975.433 (c'est la liste de Peter Dowson qui le dit, on veut bien le croire) Supposons que nous voulions nous servir de $07D4 (notre variable SIOC 0520 ou ALTI) pour faire une alarme de déclenchement d'un son lorsque l'altitude de l'avion sera + ou - 1000 pieds par rapport à l'altitude demandée au sélecteur d'altitude.
Il va falloir définir des variables intermédiaires avec une définition:
Si la variable ALTI divisée par 19975.433 + 1000 pieds est égale à la valeur de la variable de lecture de l'altimètre, alors un son est émis.
On peut simplifier largement cette écriture en définissant une variable locale. Nous dirons une fois pour toutes que la variable locale L0=ALTI/19975.433 (L0 c'est L "zéro", car la suivante s'appellera L1, etc... jusqu'à L2)

Les définitions de variables intermédiaires seront beaucoup plus simples:

ALTI_1=L0
ALTI_2=LO + 1000
ALTI_3=LO - 1000 etc...

Dès qu'un calcul intervient et se répète, une variable locale simplifie bien les choses.

Ces variables locales ne sont valables qu'à l'intérieur d'un même script (groupe de commandes, ou sous-ensemble de programmation, entre un { et un } en texte, exécuté lorsque la variable change de valeur) .

Les variables locales peuvent avoir une valeur numérique, décimale ou entière, positive ou négative, dans ce cas nous les appellerons L0, L1 et L2, car il n'y en a que trois à notre disposition.

Elles peuvent aussi avoir une valeur dite "booléenne" c'est à dire 1 ou 0, VRAI ou FAUX. Dans ce cas nous les appellerons C0, C1 et C2. Evidemment, les variables locales C correspondront souvent à une variable sur un interrupteur, ayant la valeur 0 ou 1.

On peut aussi combiner les variables locales L avec les C dans une même formule.

Les variables internes

A ne pas confondre avec les variables "locales" du paragraphe précédent.

Il peut arriver que certaines fonctions présentes sur un avion "add-on" à Flight Simulator ne correspondent à rien à l'intérieur de FS. Et par conséquent, il n'y a aucune variable correspondante dans la liste de Peter Dowson. Exemple: sur son Beech 200 , Aeroworx a prévu un interrupteur pour le convertisseur (Inverter), commande importante puisque si l'interrupteur est ouvert, la gauge de Torque ne fonctionne pas, et un voyant d'alarme s'allume en rouge. Or, l'Inverter, FS ne connaît pas...

Puisqu'il n'existe pas de variable, rien de plus simple que d'en créer une nous-mêmes. On peut créer une variable portant n'importe quel numéro, par exemple var 900 (il paraît qu'il vaut mieux rester en dessous de 2000). On pourra lui associer une variable d'interrupteur, liée à IOCard Switches, une variable de sortie Output pour une LED, et bien entendu également, on pourra mettre dans le script d'une variable interne toutes les commandes habituelles, IF, ELSE etc...

Exemple:

Remarquez que la variable interne INVERTER est non liée, puisque ne correspondant à rien dans Flight Simulator, Non liée, mais parfaitement fonctionnelle, puisque l'interrupteur de la var 420 pourra très bien déterminer que la var 900 = 1 si lui même est = 1 (dans ce cas, au lieu de faire des IF et des ELSE, il vaut mieux on ajouter une commande ASSIGN à la var 420 pour dire "var900=var420" ou INVERTER = INVERTER_SW.

Souvenez-vous, la variable SUIT l'interrupteur, donc INVERTER = INVERTER_SW, mais c'est l'interrupteur qui commande, donc la commande en question est à mettre dans le script de la variable interrupteur, et non dans INVERTER. De même, la LED SUIT sa variable, mais c'est la variable qui commande)

On imagine le parti qu'on peut tirer des variables internes pour, par exemple, réaliser un Overhead, sachant qu'une variable SIOC, y compris interne peut déclencher un équivalent clavier, donc actionner Key2Mouse, donc cliquer sur un interrupteur caché et commander ce qui n'est pas commandable autrement.

Les subroutines

Il s'agit un peu de la même démarche que pour les variables locales, simplifier des conditions répétitives. Les subroutines sont également très utiles lorsqu'on doit faire intervenir plusieurs variables pour déterminer l'état d'une autre.

Exemple (complexe) :

Dans cette subroutine pour alarme de circuit hydraulique, on définit tout d'abord avec des variables locales la valeur de la pression hydraulique totale, circuits de droite + circuits de gauche. Ce total va être analysé et s'il est insuffisant une alarme à LEDs va s'allumer. Par la même occasion on va dire que si aucun des moteurs de fonctionne, l'alarme s'allumera également.

La procédure est la suivante:

1° créer la subroutine. C'est une nouvelle variable, donc nous appelons Edit / Insert Var. Dans Link To: on va choisir SIOC SUBROUTINE, la variable sera précédée dans le .ssi d'une icône jaune.

2° Définir les commandes et paramètres de cette nouvelle variable, ce qu'elle devra faire, comment elle va fonctionner: ce sont des commandes classiques telles que nous les avons vues.

3° Enfin, dans chaque variable ayant servi au calcul dans la subroutine, nous mettrons une instruction CALL:

Dans l'exemple ci-dessus, nous faisons appel aux variables L_HYDR_PRESS et R_HYDR_PRESS, ainsi qu'aux variables L _ENG_FIRING et R_ENG_FIRING pour déterminer l'état des LEDs d'alarme. Dans chacune de ces quatre variables (mais pas dans les variables des LEDs), nous mettrons la commande CALL et le nom de la subroutine à appeler. Exemple pour les deux premières:

Dans l'exemple ci-dessus, on voit également, à la dernière ligne, qu'une subroutine peut également faire appel à une autre subroutine.

Une subroutine étant un petit programme indépendant, il est fréquent que la variable de subroutine soit appelée dans plusieurs scripts.

Les opérateurs logiques

Dans la page de définition des commandes, IF, ELSE et autres, les conditions comportent des "opérateurs logiques", le plus courant étant "="

Les autres opérateurs possibles sont:

Une fonction: DELAY

Lorsque nous avons attribué un "Type" à un Paramètre, par exemple la CONDITION IF ou la CONDITION ELSE, nous avons choisi ces conditions dans la liste déroulante Paramètres / Type. La même liste comprend également FUNCTION, et ce choix active la fenêtre de droite 'Function" . Nous y voyons des choses comme DELAY, ROUND, TESTBIT, etc... Nous allons examiner les plus importantes de ces fonctions . Prenons un premier exemple: DELAY.

Comme son nom l'indique, cette fonction a pour but d'introduire un certain retard dans l'exécution d'une variable. Reprenons l'exemple du train d'atterrissage. En temps normal, et même si nous utilisons trois variables pour indiquer la position du train, ce que nous avons fait plus haut, les trois vertes s'allument en même temps. Il est plus réaliste de faire en sorte qu'il y ait un petit décalage entre chaque allumage, les trains arrivent parfois en retard ...

Ne touchons pas à la variable NOSE_GEAR_POS ($0BEC), qui transmet la position du train avant. Comme vu plus haut, cette variable est liée à une variable Output, la NOSE_GEAR_LED, allumant la diode verte "train avant sorti" Par contre, nous allons faire en sorte que la variable R_GEAR_POS allumant la diode verte du train droit ait un retard de 0,4 seconde.

Reprenons notre fichier .ssi et faites un double clic sur la ligne R_GEAR_LED=1

Le tableau des paramètres de cette variable apparaît:

Dans Command / Type, déroulons la liste et au lieu de ASSIGN, cliquons sur FUNCTION: la case Function à droite est activée. Choisissons dans sa liste DELAY. C'est maintenant le paragraphe FUNCTION / CALL qui est actif. Dans VAR : indiquons le numéro de la variable que nous voulons temporiser, en l'occurrence R_GEAR_LED.
Dans la case suivante, ne vous occupez pas de la liste déroulante, tapez le premier paramètre de la fonction à savoir 1, puisque nous voulons que la variable R_GEAR_LED prenne la valeur 1 pour allumer la diode.
Dans la deuxième case indiquez la durée du retard souhaité, en centièmes de seconde. Si vous voulez un retard de 1 seconde, tapez 100, nous voulons un retard de 0,4 seconde, nous tapons donc 40. OK.

Désormais notre ligne de commande sera la suivante:

Faites de même pour la variable L_GEAR_LED du train gauche, en introduisant un retard de 1,2 seconde. Nous rencontrerons bien d'autres fonctions par la suite, dans notre voyage en SIOC.

Les fonctions TIMER et MOD

La fonction TIMER déclenche des évènements en fonction d'un chronomètre paramétrable. La variable prend la forme:
VAR 0001 = TIMER 0,-1,10
Le premier paramètre, ici 0, est la valeur que doit prendre la variable lorsque les cycles de comptage ou décomptage seront terminés. Si on veut un compteur en continu, on peut indiquer ici 9999, c'est une valeur limite suffisamment grande pour qu'on puisse considérer que le compteur est permanent.
Le deuxième paramètre indique l'incrémentation, c'est à dire de combien la variable doit augmenter ou diminuer sa valeur à chaque cycle. Ici la valeur de la variable diminuera de 1 à chaque fois.
Le troisième paramètre indique en centièmes de secondes le laps de temps qui s'écoule entre chaque cycle.

On trouve des exemples de Timer sur l' excellent site de Nico Kaan, ces scripts fonctionnent très bien, mais indéfiniment.

Ce n'est pas grave en soi, la consommation de SIOC étant insignifiante. Par contre cela peut perturber la lecture de IOCP Console, et obliger à déselectionner toutes les variables (bouton Deselect All), et re-sélectionner uniquement celles qui nous intéressent (petit rectangle entre le numéro et le nom de la variable).

Deux cas peuvent se présenter:

On utilise le TIMER pour des fonctions très limitées, et on ne souhaite pas avoir un compteur TIMER fonctionnant en permanence. Il faut donc déclencher puis arrêter le TIMER à la demande, autrement dit, il faut mettre un interrupteur.

Le premier paramètre de la fonction TIMER est, nous l'avons dit, la valeur de fin, la limite. Si la limite est 0, un TIMER à valeur décroissante n’ira pas plus loin que 0.

Si la limite est 9999, solution présentée à tort comme un TIMER fonctionnant indéfiniment, un TIMER à incrémentation positive s’arrêtera lorsqu’il dépassera 9999. Si notre TIMER a un cycle par seconde, sa « durée de vie » sera de 9999 secondes, il s’arrêtera donc au bout de 2,7 heures. Donc si vous voulez faire des vols de longue durée, il faudra prévoir une remise à zéro du TIMER (SI TIMER=9999 > TIMER=0), sinon vous aurez peut être des surprises à la fin du vol, le clignotant ne fonctionnant plus.

Je propose la solution suivante: l'interrupteur donnera à la variable munie d'un TIMER, la valeur limite prévue. Par exemple, si nous avons un TIMER qui décompte de -1 à chaque cycle , à partir d'une valeur de départ égale à 10, le script sera du genre:

Var 0001, name SWITCH, Link IOCARD_SW, Input 27, Type I
{
IF &SWITCH = 1

&CLIGNOT = 10// la valeur de départ de la variable du clignotant est égale à 10
&CLIGNOT = TIMER 0 ,-1 ,100// le TIMER décompte de 10 à 0 chaque seconde
}
}

ELSE // si le Switch est égal à 0
{
&CLIGNOT = 0 // mise à 0 de la variable
}
}

Var 0002, name CLIGNOT

Le ELSE permet d’assigner une condition importante: si l’interrupteur est OFF, le clignotant prend la valeur 0. Comme il a une incrémentation de -1, il prend immédiatement la valeur -1. Et comme la valeur -1 est inférieure à la valeur de fin, fixée à 0, le clignotant s’arrête.

Le fonctionnement de ce temporisateur peut être vérifié avec IOCP Console.

Si nous voulons faire un TIMER « infini » en mettant 9999, comme valeur limite, s’il dépasse cette valeur, il s’arrête.

Prenons le cas d'un TIMER qui commence à compter à partir de 1, avec une incrémentation de +1 à chaque cycle , et ce, toutes les secondes:

Var 0001, name SWITCH, Link IOCARD_SW, Input 27

{

IF &SWITCH = 1

&CLIGNOT = 1 // valeur de démarrage

&CLIGNOT = TIMER 9999 ,1 ,100

}

}

ELSE // SI LE SWITCH EST = 0

{

&CLIGNOT = 9999

}

}

dans ce cas, lorsqu’on met l’interrupteur sur OFF, le TIMER prend la valeur 9999, comme son incrémentation est ici de +1, il passe au cycle suivant à la valeur 10000, et comme cette valeur est supérieure à sa valeur limite, il s’arrête.

Reste maintenant à lier ces types de clignotants à une LED, qui devra… clignoter.

C’est la valeur de la variable CLIGNOT qui va déterminer si la LED est allumée ou éteinte. Heureusement pour nous, il existe dans la liste des fonctions la fonction MOD, pour "Module", qui donne un résultat 1 ou 0 selon que la valeur de CLIGNOT est un nombre pair ou un nombre impair. Avec une incrémentation de 1, on aura donc une LED qui s’allumera un cycle sur deux.

Ajoutons donc une LED:

Var 0002, name LED, Link IOCARD_OUT, Output 25

Notre Script de TIMER devient alors :

Var 0001, name SWITCH, Link IOCARD_SW, Input 27

{

IF &SWITCH = 1

{

IF &LED = 0 // par sécurité, pas indispensable

{

&CLIGNOT = 1// valeur de démarrage

&CLIGNOT = TIMER 9999 ,1 ,100

}

}

ELSE // SI LE SWITCH EST 0

{

&CLIGNOT = 9999

}

}

et ajoutons la fonction MOD à la variable CLIGNOT:

Var 0003, name CLIGNOT

{

L0 = MOD &CLIGNOT ,2

IF L0 = 0

{

&LED = 0 // LED éteinte

}

ELSE

{

&LED = 1 // LED allumée

}

}

Remarque : on pourrait écrire directement

ELSE // SI LE SWITCH EST 0

{

&CLIGNOT = 10000

au lieu de 9999, mais dans ce cas le TIMER prendrait la valeur d’arrêt 10000+1=10001 soit un nombre impair, et la LED resterait allumée, alors qu’avec 9999 le TIMER s’arrête sur un nombre pair : 10000, et la LED reste éteinte.

Inutile de préciser que l’interrupteur, ici dénommé SWITCH peut être n’importe quelle commande dans une variable, une subroutine, etc… qui lancera le clignotant, ou l’éteindra.

______________________________________________________________________________________________________________

 Deuxième cas: on utilise le TIMER pour des fonctions multiples, à usage fréquent, comme le clignotement de l'alarme MASTER WARNING ou MASTER CAUTION.

Ici, il devient intéressant d'avoir un compteur fonctionnant en permanence, lancé dès le démarrage de SIOC, et d'y faire appel, y compris à partir de plusieurs sources, lorsque c'est nécessaire.

La meilleure solution a été développée par Pierre Brandeis, et exposée sur le site SimuBaron . La solution de Pierre est excellente car non seulement elle permet d'utiliser une seule "centrale clignotante" pour plusieurs alarmes, mais en plus elle isole en quelque sorte le clignotant de ses commandes, ce qui évite des variations désagréables du rythme de clignotement quand les commandes sont à conditions multiples. Reportez-vous au site SimuBaron pour les explications détaillées.

La fonction TESTBIT

Cette fonction analyse en permanence l'état d'un bit déterminé dans une variable. S'il vient à changer, une commande s'exécute.
Par exemple, si on met en place une surveillance TESTBIT sur le bit n° 9 de la variable $3300, il ne se passera rien tant que l'avion sous P.A. n'aura pas capturé un Glide. Mais si c'est le cas, la valeur du bit n°9 passe de 0 à 1, et on peut alors se servir de ce changement d'état pour allumer une LED "Glide capturé".

Pour mettre en place une fonction TESTBIT, il faut bien entendu :
- avoir créé la variable sur laquelle la surveillance va s'appliquer,
- avoir créé la variable qui va être modifiée, par exemple la variable liée à FSUIPC Output devant allumer une LED,
- définir une fonction TESTBIT dans les commandes de la première variable, en indiquant dans les paramètres d'abord la variable à modifier, puis la variable à interroger, puis le bit à surveiller.

La page des paramètres ressemble à ceci:

et le .ssi à cela:

Les fonctions SETBIT, CLEARBIT, CHANGEBIT

Ces fonctions permettent de changer l'état d'un bit pour obtenir une commande déterminée, et inversement d'annuler cette modification pour revenir à l'état antérieur.

Exemple déjà cité: les phares.

On va mettre un SETBIT sur la variable $0D0C, "Lights" bit n° 0 pour allumer les feux de navigation, et un CLEARBIT sur le même bit pour les éteindre.

Ici, c'est la variable de l'interrupteur qui va avoir une condition IF avec SETBIT et une ELSE avec CLEARBIT:

La fonction CHANGEBIT change la valeur d'un bit dans une variable. CHANGEBIT N fait la même chose, en inverse.

Les encodeurs

Rien de bien compliqué. Exemple, pour l'encodeur de cap:

Var 0607 , name HDG, Link IOCARD_ENCODER, Input 86, Acceleration 6 //Heading

Donc: définition de la variable, agissant comme un encodeur et non un interrupteur, première entrée sur la carte Master: 86, accélération à définir selon le type d'encodeur pour obtenir un déplacement sans à-coups.

Il n'y a plus qu'à définir ensuite les conditions de fonctionnement de cet encodeur. De nombreux exemples d'utilisation des encodeurs se trouvent sur les sites spécialisés d'Internet.

Les encodeurs font souvent appel à des "fonctions".

Les entrées analogiques

Pas plus compliqué que les encodeurs, on pourra définir les positions 0, centre et maximum du potentiomètre utilisé.

Exemple:
Var 1100,name L_THROTTLE, Link IOCARD_ANALOGIC, Input #1, PosL 0, PosC 127, PosR 255

c'est à dire que la variable L_THROTTLE est commandée par un potentiomètre branché sur l'entrée analogique n°1 de la carte d'interface USB . La course du potentiomètre est divisée en 255 "positions". Le potentiomètre aura le calibrage suivant : sa valeur 0 Ohms sera la position de butée gauche, sa valeur en ohms maximum (10 Kilohms) correspondra à la position extrême 255, et si nous voulons que sa courbe de variation soit linéaire, sa position médiane correspondra à 255/2, soit 127.

Les sorties vers des LEDs

Nous en avons vu quelques exemples ci-dessus, ces variables ne comportent rien de bien particulier. Exemple d'une variable de sortie:

Var 0703, name AP_ALT_LED, Link IOCARD_OUT, Output 20 // Voyant PA mode ALT

Les numéros de "device"

Ceci concerne principalement la carte USB Outputs, mais aussi les cartes Servos, Stepper, etc...
Quand la carte USB Output est branchée sur un port USB, on ouvre SIOC (version supérieure à 3.46) et dans la fenêtre supérieure droite on voit un numéro IDX et un numéro de « device » pour chaque carte branchée sur une prise USB. Dans l’exemple ci-dessous, il n’y a que deux cartes : la carte USB Expansion et la carte USB Output.

Le numéro IDX

Le numéro d’Index IDX (0,1,2, etc… par défaut) est très important, c’est lui qui va déterminer si une variable Output devant par exemple allumer une LED sur la sortie Output n°11, doit le faire sur la 11 de la carte Master (J2) ou sur la 11 de la USB Output.
Les numéros IDX peuvent être attribués arbitrairement par l’utilisateur, on peut mettre 10 pour la Master et 20 pour la USB Output par exemple.
Si on donne 0 comme numéro d’Index à une carte, les sorties de cette carte sont considérées comme sorties par défaut, prioritaires.
Le numéro d’Index concerné doit figurer à la fois dans le fichier sioc.ini et dans chaque variable Output. (voir plus loin pour les détails)

Le numéro de « device »

Le numéro de « device », dans la capture d’écran ci-dessus 85 ou 84, change à chaque fois qu’on change de port USB sur l’ordinateur ou sur un hub USB.
Ce numéro de « device » doit être reporté dans le fichier sioc.ini, et ne concerne que ce fichier.

Le fichier sioc.ini, et le logiciel Config SIOC ini.

Pour configurer correctement ce fichier, il est recommandé d’utiliser le petit logiciel « config SIOC ini » de Fernando Brea, très visuel. Dans « File » de ce logiciel on choisit le fichier « sioc.ini » et ensuite dans l’onglet « Masters » on ajoute la carte USB Output  (Enable coché):

Ici, nous avons laissé les IDX 0 et 1, la carte Master/USB Expansion portant le n°0 est donc la carte par défaut.
On choisit ensuite le Type de carte : dans le menu déroulant la USB Expansion porte le numéro 4, la USB Output le numéro 6.
Dans N°Cards, on indique combien de cartes de ce type on utilise, 1, 2 ou plus.
Dans ID USB , qui aurait pu s’appeler « Device » on indique le numéro … de « device » indiqué par SIOC lorsque les cartes sont correctement branchées sur un port USB.
LPT ne concerne que le cas, très rare, d’utilisation du port parallèle.
Il ne reste plus qu’à enregistrer les modifications (File/Save).
Le fichier sioc.ini est alors modifié automatiquement, on doit voir les deux lignes suivantes dans le paragraphe [MASTERS]

La première Master est la carte Master classique. Elle a le numéro d’index 0, le chiffre 4 correspond à une Master branchée sur la carte USB Expansion, le 1 indique qu’il n’y a qu’une seule Master utilisée, et le 85, qui changera avec chaque prise USB, est le n° de « device ».

La deuxième Master est en fait la carte USB Output, son index est 1, le 6 signifie carte USB Output, le 1 indique qu’il n’y en a qu’une, et le 84 est le n° de « device ».

Même principe en cas de cartes multiples (plusieurs cartes servos par exemple).

Les afficheurs

SIOC permet bien entendu d'afficher sur des afficheurs 7 digits la valeur d'une variable. Ce peut être une fréquence radio, un cap, le niveau de carburant, la pression barométrique, mais aussi la valeur quelconque d'une variable interne.

Une variable d'affichage sera tout naturellement liée à la carte Display multiplexée, et donc on choisira Link To: IOCARD_DISPLAY.
On indiquera le nombre de digits nécessaire pour cet affichage, si nous mettons 3 par exemple, cela signifie que nous allons utiliser un afficheur à 3 chiffres, comme celui des caps. Il se peut que ce nombre affiché doive être parfois précédé du signe -, dans ce cas, il faudra évidemment prévoir un afficheur de plus (cas de la vitesse verticale par exemple).

Rappel 1: pour qu'une variable puisse prendre en compte des valeurs négatives, il faut que dans ses paramètres soit indiqué "Type 1".

Rappel 2: la carte Display est dite "multiplexée", car elle fournit une alimentation intermittente à ses afficheurs, à tour de rôle.

Les variables d'affichage peuvent aussi prendre des valeurs "spéciales" parfois très utiles:

De nombreux exemples d'utilisation des afficheurs se trouvent sur le Forum SIOC de OpenCockpits.

Les 1 fixes : on peut économiser des sorties de la carte Display en remarquant que les 1 des fréquences radio (ex: 118.60) sont fixes, c'est bien connu. On peut les brancher directement sur l'alimentation avec une résistance . Inconvénient, ils sont trop lumineux et quand on éteint l'afficheur, ils restent allumés. Solution possible: relier l'anode des segments, qui sont des LEDs, à une ou plusieurs sorties J2 de la carte Master, en faisant attention à ne pas dépasser 20 mA par sortie.Les cathodes, multiplexées, étant communes sur les afficheurs, et reliées à la carte Display, les segments ainsi alimentés seront eux aussi multiplexés, et fonctionneront comme leurs voisins, avec la même luminosité, et sans qu'il soit nécessaire d'intercaler une résistance.
Autre possibilité d'économie, dans le cas des affichages des altitudes, on peut très bien rendre fixes de la même manière les deux derniers zéros de l'altitude, il suffira alors de trois sorties sur la carte Display au lieu de 5.
Dernière solution : économiser des sorties sur la carte Display n'est pas toujours nécessaire: on peut se simplifier la vie, pour les fréquences radio par exemple, en multipliant leur valeur par 100. On aura dans ce cas à afficher 118.60 et non plus 18.60, celà fait un afficheur de plus, mais tout est plus simple.

Attention: le nombre d'afficheurs doit correspondre au nombre maximum de chiffres à afficher, sinon gros cafouillages.

Exemple d'utilisation: afficher la température extérieure OAT.

Var 0031, name OAT, Link FSUIPC_IN, Offset $0E8C, Length 2, Type 1 // température extérieure

L0 = &OAT / 256
&OAT_DIS = TRUNC L0 // Afficheur 3 digits
}

Var 0600, name OAT_DIS, Link IOCARD_DISPLAY, Digit 0, Numbers 3 // Affichage Temp. extérieure

La variable OAT est de Type 1, pour prendre en compte les températures négatives. On divise sa valeur par 256 pour obtenir la valeur en degrés centigrades. On utilise ensuite la fonction TRUNC pour arrondir cette valeur et être sûr de ne pas dépasser le nombre de chiffres: ici nous avons deux afficheurs pour les chiffres plus un pour le signe moins, soit trois afficheurs, les n° 0,1 et 2 sur la carte Display.

On voit également qu'une variable quelconque, ici OAT, mais ce pourrait être aussi une subroutine, peut commander directement la valeur d'une variable d'affichage, sans variable interne intermédiaire.

On peut bien entendu faire intervenir autant de conditions qu'on le souhaite. Un autre exemple: un afficheur digital indique la tension du bus gauche, sur un Beech 200. Si l'inter de batterie =1, la batterie =1. Deuxième condition: si le générateur gauche a la valeur 2, c'est à dire qu'il est en marche, l'afficheur de tension va indiquer 28 (volts) . Si on coupe le générateur , l'afficheur indiquera 22 volts, la tension de la batterie seule. Si la batterie est coupée, l'afficheur indiquera 0. Jusque là, pas de problème. Mais on a un gros dévoreur de courant à bord, le dégivrage de l'hélice. Quand il est en marche, la tension du générateur chute de 1 volt, malgré sa régulation. On pourra donc écrire: si dégivrage =1 alors afficheur = afficheur -1. Au lieu d'indiquer 28 volts, l'afficheur indiquera 27 volts. Si on coupe le dégivrage, le ELSE prévoit que dans ce cas c'est la subroutine définissant les conditions d'affichage qui reprend la main, et la tension remonte à 28 volts.

Comment générer des équivalents clavier avec SIOC

1° Dans le fichier SIOC.ini, attribuer des équivalents clavier à chaque numéro #.

Ceci suit les mêmes règles que pour l’attribution à la carte USB Keys, en particulier :

• FS ne connaissant que des commandes en minuscules, une commande attribuée à une action dans FS, comme G pour le train, doit être notée #1=<G soit G minuscule, et non pas #1=G
• Les fonctions classiques de FS peuvent être commandées par SIOC : si on tient à sortir les volets avec F7, on notera #2=\K , \K donnant F7 comme pour USB Keys. Si on veut envoyer un F6 ce sera #3= \J

Enregistrer le fichier SIOC.ini modifié (Program Files/IOCards)

2° Dans le fichier ssi, créer une variable « Keys », par exemple :

Var001, name Keys, Link KEYS

Link KEYS est dans la liste des liens possibles sous le nom Keyboard Emulator, et non USB Keys…

A chaque fois qu’on demandera une action à un interrupteur, il se réfèrera à cette variable et lui attribuera un numéro, donc un équivalent clavier selon les attributions de sioc.ini

Exemple : un interrupteur

var 002, name Inter, link IOCARD_SW, input 01 // inter pour essais

Si var 002 a une valeur 1, on lui assigne Keys=1 pour lui faire envoyer un G minuscule, ou Keys=2 pour lui faire envoyer un F7, etc… F

Après ce premier ASSIGN, il faut en mettre un deuxième, pour faire une remise à zéro, et permettre que l’interrupteur puisse envoyer de nouveau son code.

Exemple: la machine à café du Beech 200:

Var 0474, name COFFEE_MACH_SW, Link IOCARD_SW, Input 44 // Poussoir son machine à café
{
&KEYS = 4 // appelle un d pour Key2Mouse
&KEYS = 0 // remise à zéro
}

Les sons

Une variable SIOC peut très bien déclencher un son, qu'il s'agisse d'une variable liée à un interrupteur ("Fasten Seat Belts") ou d'une variable déclenchée par une autre ou un calcul (par exemple un son d'alarme quand l'altitude de l'avion arrive à + ou - 1000 pieds de l'altitude demandée au sélecteur d'altitude).

Les fichiers sons peuvent être n'importe quel fichier .wav, ils n'ont rien à voir avec FSUIPC ni même avec les fichiers sons de l'avion. Il suffit que les fichiers en question soient placés dans le même dossier que les fichiers SIOC. Le plus simple est de tout mettre dans Program Files \ IOCards.

On aura par exemple dans le dossier SIOC:

A noter que l'utilisation de IOC Sound.exe n'est plus nécessaire avec les dernières versions de SIOC.

Ensuite, il faut s'occuper du fichier sioc.ini, et modifier le paragraphe [SOUND MODULE] en indiquant des numéros d'ordre, commençant par #1, pour chaque fichier son qui sera utilisé dans le programme .ssi de chaque avion. Cela donnera dans notre exemple:

[SOUND MODULE]
Sound_disable=No
Volume=100

[ #1 ]
Sound=PAX_SIGN.wav,-1,-1,0

[ #2 ]
Sound=*FIRE_BELL.wav,-1,-1,0

[ #3 ]
Sound=STALL.wav,-1,-1,0

[ #4 ]
Sound=CLICK.wav,-1,-1,0

[ #5 ]
Sound=GEAR_ALARM.wav,-1,-1,0

[ #6 ]
Sound=flaps20.wav,-1,-1,0

Les paramètres -1, -1, 0 correspondent à :
- la fréquence du son : -1 signifie fichier actuellement utilisé, ou 0 signifie fréquence de l'original.
- le volume du fichier son utilisé (en tête du paragraphe on a Volume=100, qui correspond au volume général de tous les sons).
- la balance: de -100 pour un son tout à gauche à +100 pour tout à droite, en passant par 0 pour un son centré.

Sauf cas particulier, on ne retouchera que rarement ces paramètres.

A noter également que notre son #2 est précédé d'un *, qui signifie que ce son devra être joué en boucle.

Ensuite, plusieurs méthodes sont possibles, mais je suivrai la suggestion de Guda, qui préconise de créer deux variables, l'une pour lancer tous les sons , ceux qui sont joués une fois et ceux qui sont joués en boucle, et une autre pour arrêter les sons en boucle uniquement. Ces variables seront liées au module SOUND. A noter que la variable d'arrêt comporte le paramètre "Type S" , indispensable dans ce cas.

Il ne restera plus qu'à indiquer dans la variable qui commandera le son, un interrupteur par exemple, quel numéro de fichier son la variable PLAY_SOUND devra lancer, et de reprendre le même numéro dans la variable STOP_SOUND.

Mais attention, quand une variable a pris une valeur quelconque, il n'y a aucune raison qu'elle en change, à moins qu'on ne l'y force. Quand votre interrupteur qui commande les signaux passagers, par exemple, a pris la valeur 1 pour appeler le son n°1, si vous voulez de nouveau actionner cet interrupteur, il faudra au préalable que la variable PLAY_SOUND ait repris la valeur 0, sinon il ne se passera rien. La remise de l'interrupteur en position OFF pourrait s'en charger, mais c'est une bonne habitude que de remettre la variable PLAY_SOUND à zéro immédiatement après qu'elle ait lancé un son.

Exemple:

Sur cet exemple, on voit aussi qu'il est inutile d'utiliser la variable STOP_SOUND, puisqu'il s'agit d'un son joué une fois, qui s'arrête de lui même.

Si par contre on lance un son en boucle, comme l'alarme incendie appelant le son FIRE_BELL.wav, il est indispensable non seulement de remettre à zéro la variable PLAY_SOUND, mais également la variable STOP_SOUND, sinon votre avion pourra brûler une fois, mais pas deux ...

Les autres fonctions

TRUNC: Lorsque la valeur d'une variable est le résultat d'un calcul, comme V0001=V0002*(100/16384),le résultat de l'opération n'est pas arrondi dans Flight Simulator pour être pris en compte par une gauge, mais "tronqué", c'est à dire écourté: 15,780 ne sera pas pris en compte comme 15,8 ni comme 16, mais comme 15. Quand ce mode de prise en compte est obligatoire, on utilise le paramètre TRUNC. Par exemple, V0003=TRUNC L0
Cette fonction est particulièrement importante quand il s'agit d'afficher une valeur avec des afficheurs à 7 segments.

ROUND: à l'inverse de TRUNC, cette fonction arrondit la valeur d'un calcul à une valeur entière, sans décimales.

NOT: change la valeur 0 ou 1 d'une variable booléenne, en lui donnant la valeur inverse de ce qui est indiqué dans le paramètre 1

FROM BCD convertit en valeur décimale une valeur en binaire. TO BCD fait l'inverse.

ROTATE: exécute des incrémentations ou des décrémentations cycliques. Permet de simplifier la programmation des encodeurs.

TOGGLE: modifie à 1 puis à 0, ou inversement, la valeur d'un bit d'une variable.

ABS: renvoie à une valeur absolue.

LIMIT: incrémente une variable en fonction de certaines limites . Exemple si on veut écrire
{
IF &ALTITUDE > 500
{
&ALTITUDE = 500
}
IF &ALTITUDE < 0
{
&ALTITUDE = 0
}

on peut plus simplement écrire:


&ALTITUDE = LIMIT 0, 500

DIV: calcule le résultat entier d'une division entre deux nombres

Note: les variables ont toujours une valeur numérique, exprimée soit en décimal, soit en hexadécimal. Et comme pour toute valeur numérique, il est possible d'y appliquer des formules mathématiques. On peut ainsi multiplier une variable par une autre (*) ou la diviser par une autre ou par un nombre fixe (/) , additionner deux variables (+) , etc...

Tester du code

Quand on a fait ou recopié le code d'un script déterminé, on l'essaye avant d'aller plus loin. Ce qu'il ne faut pas faire est de changer pour essais les numéros d'entrée ou de sortie d'un interrupteur ou d'une LED déja installés pour les utiliser pour l'essai d'une fonction nouvelle. On arrive vite à des oublis, des confusions de numéros, bref quand quelque chose fonctionne on n'y touche plus. Il est tentant d'utiliser les afficheurs digitaux du niveau de carburant par exemple, pour vérifier si le transpondeur fonctionne, mais l'opération est risquée. Il m'est rapidement apparu qu'il fallait avoir un banc de test pour faire les essais sans toucher au reste.

Pour ce faire, si on crée un code SIOC nouveau, on va se réserver tout d'abord des variables de test : si nos variables des interrupteurs sont dans la série 400 à 499, on créera des variables pour tester des interrupteurs dans la série 2400 à 2499 par exemple. Quand le script nouveau fonctionnera, on attribuera des numéros définitifs en retirant le 2 pour ne garder que le 400.

Dans le même ordre d'idées, il est indispensable de se réserver des numéros d'entrées, sorties et afficheurs pour faire les essais. Ce sera par exemple le dernier groupe d'entrées de la carte Master, soit les numéros 63 à 71 avec la masse commune GND8 si on n'a qu'une seule carte Master, soit, c'est plus probable, si on en utilise deux, le groupe 135 à 143 avec la masse GND16. Ceci permet le test de deux interrupteurs à levier, de deux boutons poussoirs et de deux encodeurs.

Il est très pratique d'utiliser le tableau des attributions de Joël Péruffo, qui dans le dernier cas indiquera :

On peut de même se réserver les sorties 54 et 55 de la première Master ou les 118 et 119 de la deuxième pour essayer des LEDs, et on gardera 5 afficheurs sur une des cartes Display uniquement pour les tests. Cela peut paraître un gaspillage des sorties, mais en fait on y gagne largement.

Dans cet exemple on se réserve les Displays 27 à 31 pour les essais.

Nous avons donc des variables de test dans la série 2000, des entrées Master, des sorties LEDs et des sorties Displays réservées, reste à savoir à quoi cela correspond physiquement.

Une petite console de test .

L'investissement n'est pas considérable, on mettra dans un petit boitier deux interrupteurs, deux poussoirs, deux LEDs sans résistance puisqu'elles seront branchées sur les deux sorties Output réservées, un bloc de 5 afficheurs pouvant par exemple afficher l'altitude sélectionnée (5 chiffres) mais aussi un cap à trois chiffres, et deux encodeurs CTS 288 pour pouvoir tester les radios. Cette petite console peut rester branchée en permanence sur le cockpit, elle fonctionnera avec nos variables de test en fonction des besoins.

Conclusion

Ce court tutoriel donne un aperçu des possibilités de SIOC. A partir de ces bases, il est facile de concevoir les commandes les plus complexes, . SIOC est un outil remarquablement puissant, d'une stabilité totale, on comprend qu'il soit devenu le langage de programmation des cockpits le plus répandu dans le monde.

Merci à Manuel Vélez