simu320

programmer

La programmation SIOC est bien entendu au coeur de l'animation de notre Airbus A320. Associé aux cartes IO Cards, elle permet de pratiquement tout faire, en tout cas, tout ce qu'il est raisonnable de reproduire.

Mon précédent cockpit, un Beech 200, avait un code SIOC dont les variables étaient classées par type de commande. Par exemple, les numéros des variables des interrupteurs étaient toujours dans la série 400 à 499, les afficheurs dans la série des 600. Pour le A320, un autre système semble mieux adapté: nous allons maintenant grouper les variables par destination système. Par exemple, tout ce qui concerne la gestion de l'hydraulique sera regroupé dans une même groupe de variables, toute l'électricité dans un autre. On peut ainsi envisager un programme SIOC par "ATA", ou système avion. L'avantage est que toutes les commandes pour un même objet se trouvent sinon côte à côte, du moins très proches l'une de l'autre, la lecture du code est simplifiée.

Autre avantage, on peut suivre au plus près le FCOM, l'indispensable "Operation Manual" de l'avion, et donc s'y référer plus facilement.

On peut classer les variables dans les groupes suivants, chaque numéro de variable commençant par les deux chiffres du groupe ATA:

Exemples:

Variables "FS"

Var 0000, name INIT, value 0 // variable d'initialisation

Var 1001, name SLEW, Link FSUIPC_OUT, Offset $05DC, Length 2, Value 0 // Y

Var 1035, name ACFT_ON_GND, Link FSUIPC_OUT, Offset $0366, Length 2 // Détection avion au sol/en l'air

Classe JeeHell FMGS:

Var 0008, name SPD_ENC, Link IOCARD_ENCODER, Input 1, Aceleration 1, Type 2

Var 0009, name SPDpush_SW, Link IOCARD_SW, Input 3, Type I

Classe 32 (train, freins):

Var 3200, name GEAR, Link FSUIPC_INOUT, Offset $0BE8, Length 4     // Commande du train

Pour la variable d’interrupteur : 
  
 Var 3201, name GEAR_SW, Link IOCARD_SW, Input 22     // Inter manette de train

Pour la variable de LED :
  
 Var 3202, name NOSE_GEAR_LED, Link IOCARD_OUT, device 1, Output 05 // Voyant vert train avant sorti 

  

Les noms de variables se terminent toujours par un suffixe indiquant de quel type de commande il s'agit.

Mes variables de commande de FS ($...) ont simplement un nom explicite, ainsi que les Subroutines et les variables internes.
Exemple: ma variable de train s'appelle GEAR.

Mes variables d’interrupteurs inverseurs se terminent toujours par _SW .
Exemple: ma variable d'interrupteur de train s'appelle GEAR_SW

Les variables de boutons poussoirs se terminent toujours par _PB

S'il s'agit d'un commutateur rotatif, le suffixe est _ROT SW

Les variables des sorties Output se terminent toujours par _LED.
Exemple: la variable commandant le témoin vert du train gauche s'appelle LEFT_GEAR_LED

Les variables des encodeurs se terminent toujours par _ROT ENCOD
Exemple: la commande de sélection de cap s'appelle HDG_ROT.

Les variables de sons , moins utilisées depuis les dernières versions de SIOC, se terminent toujours par _SND.
Exemple: la variable appelant le son "ding dong" d'enclenchement des signaux passagers peut s'appeler PAX_SIGN_SND

Enfin, plus souvent que nécessaire, les actions sont décrites –en français (!)- derrière le signe // d'un fichier texte, ou dans la case "Description" de la fenêtre des Paramètres vue ci-dessus améliore grandement la compréhension.

Ce système convient parfaitement pour un cockpit pas trop sophistiqué . Par contre, il sera insuffisant si toutes les commandes sont envisagées: voyants FAULT des Korry, panneau ECAM complet , etc... Le premier ATA à être saturé sera le 22, du fait du MCDU. D'autres classes de variables, limitées à 100 variables par classe, seront un peu justes. Si un tel cockpit est envisagé, il est sans doute préférable d'opter dès le début pour des variables SIOC "Static", et un classement en plusieurs fichiers de config. Voir le forum Air Cockpit pour plus de précisions.

Généralités concernant la programmation

Il faut d'abord remarquer que la programmation de l'essentiel de l'avion, à savoir le FMGS, nous échappe, puisque réalisée pour nous par Alex Wemmer (vasFMC) ou Jean Luc (Jee Hell FMGS). Merci à eux, c'est un travail de Titan, que très peu de programmeurs ont osé aborder.

lIl nous reste à programmer les fonctions standards de Flight Simulator, avec quelques conditions supplémentaires sympathiques (par exemple le train ne sort que si la vitesse est inférieure à 260 Kts), mais rien de bien complexe. Bien entendu, si on utilise vasFMC, il y aura plus de lignes de code SIOC que dans le cas de JeeHell, vasFMC étant moins complet. Par exemple, on devra dans vas prévoir la programmation des batteries, alors que dans JeeHell cela se fait automatiquement par SIOC Creator.

Deux remarques: une carte Master possède 45 sorties pour les LEDs, avec trois Master pour l'ensemble du cockpit, le nombre de sorties est un peu juste, mais suffisant. Mais certains voyants sont doubles, il y a par exemple deux Master Warning, deux GPWS, etc... et là, on bute sur un problème de consommation électrique, une LED ça va, deux LEDs sur une seule sortie Master, ça ne va plus.

Deuxième remarque: certains d'entre nous ont trouvé de véritables Korry, il y en a de temps en temps sur E-Bay par exemple. Magnifique, mais les Korry anciens sont équipés de lampes à incandescence qui consomment beaucoup plus qu'une LED, une carte Master ne peut pas gèrer cela. D'où la nécessité, en raison de ces deux remarques, de recourir à une carte USB Output (qui propose 64 sorties). Et la nécessité de n'avoir qu'une seule tension d'alimentation pour tous les Korry réels et maison, en l'occurrence 5 Volts, imposée par les Korry réels.

Les LEDs des "Korry" maison seront donc toutes alimentées en 5 volts. Lorsque ces LEDs sont branchées sur une carte Master, il n'est pas nécessaire de mettre une résistance en série, la carte Master assure une sorte de régulation de tension. Par contre, lorsque une ou plusieurs LEDs sont branchées sur le 5 Volts commuté par la carte USB Output, une résistance est indispensable. Cette résistance aura la valeur suivante:

Chute de tension interne de la LED 2,3 Volts.................. résistance 150 Ohms pour une LED ou 68 Ohms pour deux LEDs en parallèle,

Chute de tension 3 Volts ................................................... résistance 120 Ohms pour une LED ou 56 Ohms pour deux LEDs en parallèle.

Conséquence aussi: les Korry véritables s'il y en a, seront alimentés en courant continu, mais comme il n'y en a jamais beaucoup allumés en même temps, cela ne pose pas de problème pour l'alim d'ordinateur équipant le cockpit. Par prudence toutefois, les fils noir et rouge allant à l'Overhead seront doublés, ou de section 0,50 mm² au lieu de 0,20. Et bien entendu, ce sera aussi le cas des fils POWER Input de la carte USB Output (connecteur J3 , attention à la polarité! ) L'idéal serait toutefois de disposer de deux alimentations 5 volts: une pour la carte USB Output et les LEDs qui y sont branchées et une autre pour l'alimentation des cartes Master et des LEDs qui y sont branchées. Ceci est surtout valable dans le cas de l'utilisation de Korry réels: lors de l'enclenchement, l'éclairage des lampes à incandescence provoque une chute de tension, courte, mais suffisante pour perturber l'alimentation d'une carte Master. Dans le cas de Korry à LEDs, il n'y a pas de chute de tension à l'allumage et quel que soit le nombre de voyants allumés, la tension d'alimentation des cartes Master reste toujours légèrement supérieure à 5 Volts. En aucun cas la tension d'alimentation d'une carte Master ne doit être inférieure à 4,4 volts.

Notes: j'avais quelques inquiétudes quant à la possibilité des ULN2803 équipant la carte USB Output à alimenter les deux lampes à incandescence d'un Korry. J'ai fait l'essai avec Christian, plusieurs Korry branchés en permanence sur un ULN 2803 ne le font absolument pas chauffer, ouf...

Le code SIOC devra donc inclure le numéro " d'index IDX " de la carte USB Output pour chaque sortie (voir SimuCockpit ). Dans le cas de JeeHell FMGS, le numéro IDX est à indiquer en même temps que le numéro de sortie.

Tous les "Korry" maison seront équipés d'une résistance de 150 Ohms sur chaque LED, ce qui simplifie le câblage et limite le risque d'erreur.

Un des avantages, et non des moindres, de la carte USB Output est qu'elle permet d'origine de régler l'intensité lumineuse de toutes les sorties, LEDs et lampes, par un circuit PWM intégré à la carte. Cette commande d'intensité existe sur l'Airbus réel (inverseur ANN LT sur le panneau 25VU de l'Overhead)

Les cartes IOCard

La matériel nécessaire, pour mon cockpit tout au moins, est le suivant:

La disposition des principales cartes IOCard, sur mon cockpit, est indiquée ci-dessous. Avantages: tout est à portée de la main, protégé de la poussière par les couvercles du Glareshield.Cette localisation permet de réduire la longueur des fils et de faciliter le démontage. Il y a en outre une Master dans l'Overhead et deux Displays pour les radios dans le Pedestal.

1 et 2 .................................. cartes Display FCU et EFIS
3 ......................................... EFIS copilote
4 ......................................... FCU
5 ......................................... EFIS pilote
6 ......................................... rampe de LEDs du rétro-éclairage
7 ......................................... carte 8 relais (FCU)
8 ......................................... PWM 5 voies
9 ......................................... barrette de connexion J3 Master 1
10 ....................................... barrette de connexion J4 Master 1
11 ....................................... barrette de connexion J2 Master 1
12 ....................................... Master 1
13 ....................................... carte USB Expansion
14 ....................................... barrette de connexion J3 Master 2
15 ....................................... barrette de connexion J4 Master 2
16 ....................................... Master 2
.

Ne nous précipitons pas ...

Il est tentant de préparer son code SIOC en y mettant tout de suite toutes las variables dont on va avoir besoin, et pourquoi pas, les variables des interrupteurs qui serviront un jour. C'est une erreur à ne pas faire, car SIOC va bien trouver ces variables, mais comme il n'y a pas d'interrupteur branché, il va en déduire qu'il s'agit d'un interrupteur en position OFF, et agir en conséquence, c'est à dire à son idée.

Il en résulte très vite des réactions bizarres, dont on cherche longtemps l'origine, ou alors on découvre qu'il y a deux interrupteurs sur la même entrée, un bien réel et un autre oublié depuis longtemps, prévu dans une variable non utilisée.

Le tableau des attributions SIOC devrait éviter cela, mais par principe, il vaut mieux faire le code au fur et à mesure des besoins, et essayer chaque script un à un. Mieux vaut construire que réparer.