Piloter un relais bistable avec Arduino

Il y a plusieurs moyen d'augmenter le nombre d'E/S d'un micro : registres à décalage, expanseur.

Nous n'avons pas le cahier des charges de ta gare cachée et donc nous ne savons pas ce que tu essayes de faire. Un exposé dans ce sens serait sympa.

Peut être, si les longueurs de fils entre ta carte et l' Arduino  sont importantes , les 2N2222 ne sont pas suffisamment bloqués (parasites ........) , il faut essayer d'ajouter des résistances entre la base et la masse comme ci dessous.

 

Le fonctionnement de ma gare cachée est on ne peut plus basique et n'a rien d'innovant !   

La gare est constituée par une voie montante et une voie descendante, chacune sous divisée en deux quais.

Pour chacune des voies le fonctionnement est le suivant :
Un train 1 arrive, emprunte le quai A, détection par l'IR lors de son arrivée, mise HORS alimentation d'une zone d'arrêt en fin de quai A (le train 1 s'arrête), mise EN alimentation de la zone d'arrêt en fin de quai B, bascule de l'aiguillage d'entrée du quai A vers B.
Un train 2 arrive, emprunte le quai B, détection par IR, mise HORS alimentation de la zone d'arrêt en fin de quai B ( le train 2 s'arrête), mise EN alimentation de la zone d'arrêt en fin de quai A, (le train 1 redémarre), bascule de l'aiguillage d'entrée du quai B vers A......etc

But recherché : rallonger artificiellement le temps de rotation d'un train sur la boucle.

On se contente de démarrages et d'arrêts "brutaux" puisque tout cela est caché.

Il me faut dans l'état actuel de ma réflexion :
- une entrée pour chacun des IR (4) deux sorties pour le relais de la voie montante (+2) et deux pour celui de la voie descendante (+2) auxquelles viendraient se rajouter deux sorties pour l'aiguillage de la voie montante (+2) et deux pour l'aiguillage de la voie descendante (+2)
Nous sommes déjà à 12 broches occupées... Sans avoir prévu aucune sorties de visualisation par Led (qui pourraient cependant être utiles), ni de démarrage forcé d'un train, car il faudra bien forcer le dernier train à sortir de la gare cachée au moment de replier le circuit (car j'ai oublié de préciser que mon circuit de 2m16 x 0m70 se replie verticalement dans un caisson mural).

Parallèlement à cette gare cachée, j'ai dans l'idée de piloter également avec Arduino + IR une gestion automatisée de raquette, ainsi que l'animation de l'éclairage du décor....

Tout le câblage et l'électronique étant embarqués sur le panneau mobile sous le circuit, je cherche à réduire au maximum le nombre d'Arduino pour une question de place et également de poids (une Arduino ne pèse certes pas lourd, mais rajoutée aux relais, gestions de cantons, câbles, aiguillages, matrices de diodes, décor etc....)

Voilà en quelques mots pourquoi je compte avidement mes broches !!

patpovil a écrit:

Peut être, si les longueurs de fils entre ta carte et l' Arduino  sont importantes , les 2N2222 ne sont pas suffisamment bloqués (parasites ........) , il faut essayer d'ajouter des résistances entre la base et la masse comme ci dessous.

 

Non, j'ai simplement une vingtaine de centimètres.

Ok ok

Donc c'est comme ça :



Les deux rectangles noirs sont les capteurs et les deux zones rouges sont les zones d'arrêt. Les trains arrivent de la gauche.

Mais, une question bête peut-être, pourquoi ne mets-tu pas les capteurs au début de la zone d'arrêt ? :

Ok

C'est pas bien grave, c'est pas compliqué de faire avec mais le logiciel va être un poil plus compliqué. Pour y voir plus clair et éviter de partir à l'aventure en écrivant un programme à l'arrache, il faut formaliser le problème.

Donc quand un train entre sur la voie, le capteur va détecter ça (le dessin est pour une loco et 3 wagons mais ça marchera quelque soit le nombre de wagon)



Le problème est qu'il faut faire la distinction entre le retour à HIGH dû au passage d'un attelage et le retour à HIGH dû à la fin du train. Là on va mesurer le temps, en supposant une vitesse mini du train. Si le temps de démasquage dépasse un temps maxi, il ne s'agit pas d'un attelage mais de la fin du train. Par exemple en supposant une vitesse mini de 20mm/s et un espace inter-wagon de 10mm, au bout de 0,5s on sait qu'il s'agit de la fin du train.

Comme on ne veut pas que le programme reste bloqué sur un delay car il a deux gares (ou plus) à gérer, on va utiliser un compteur et un automate permettant de reconnaître le passage d'un train. Supposons que le logiciel examine le système (lit le capteur, compte le temps) toutes les 10ms, on va appeler cette unité de temps le tick. l'espace inter-wagon est de 50 ticks.

L'automate a 3 états : attente (on attend un véhicule), wagon (on a détecté un véhicule), attelage (on suppose avoir détecté un attelage). On démarre dans l'état attente. Si le capteur détecte un véhicule, on passe dans l'état wagon. Si le capteur ne détecte plus de véhicule, on initialise le compteur à 0, on passe dans l'état attelage. Tant que le compteur est plus petit que 50, on reste dans l'état attelage et on décrémente le compteur. Si le capteur est toujours HIGH, on passe dans l'état attente. Si le capteur est LOW, on retourne dans l'état wagon.

Si on dessine cet automate, ça donne ceci :

INGENIEUX !

Cela me paraît séduisant.

J'y vois également un deuxième avantage, c'est que dans le cas d'une constitution malencontreuse de train trop long pour la gare, l'aiguillage ne sera pas actionné au milieu du train, et en revanche celui-ci sera "évacué" puisque la zone d'arrêt sera déjà franchie par la loco quand l'impulsion arrivera   

Mais comment fait-on pour transcrire tout çà en bon langage Arduino       

Là j'ai besoin de ton aide, car tu fais appel à des notions qui me sont aussi étrangères que le Mandarin !

VAUBAN38 a écrit:

J'y vois également un deuxième avantage, c'est que dans le cas d'une constitution malencontreuse de train trop long pour la gare, l'aiguillage ne sera pas actionné au milieu du train, et en revanche celui-ci sera "évacué" puisque la zone d'arrêt sera déjà franchie par la loco quand l'impulsion arrivera   

Je ne suis pas aussi catégorique que toi. Les événements non prévus dans un système ont très rarement une issue favorable. Si le train continue, cela n'empêchera pas celui qui est stationné sur l'autre voie de démarrer et de télescoper l'arrière du train qui a raté son arrêt.

Dans mon idée, la zone d'arrêt doit être hors tension par défaut. De cette manière un train trop long s'y arrête quoiqu'il arrive et le système se bloque (en espérant que ce n'est pas un attelage qui s'arrête sous le capteur).

Citation :

Mais comment fait-on pour transcrire tout çà en bon langage Arduino       

Là j'ai besoin de ton aide, car tu fais appel à des notions qui me sont aussi étrangères que le Mandarin !

C'est assez direct. Pour chaque gare tu as besoin de 2 variables : l'état de l'automate (appelons le etatTrain0) et le compteur (appelons le compteur0). Donc

Code:

// les états que l'automate peut prendre
enum { ATTENTE, WAGON, ATTELAGE };

byte etatTrain0 = ATTENTE;
int compteur0;

const unsigned long dureeAttelage = 50;

Ensuite pour faire avancer l'automate, le plus naturel est d'utiliser un switch ... case, une sorte de if à choix multiple dont le test est l'égalité entre une variable et une constante, ici l'état de l'automate :

Code:

byte capteur = digitalRead(pinCapteur);

switch (etatTrain0)
{
  case ATTENTE:
    if (capteur == LOW) {
      etatTrain0 = WAGON;
    }
    break;
  case WAGON:
    if (capteur == HIGH) {
      etatTrain0 = ATTELAGE;
      compteur0 = 0;
    }
    break;
  case ATTELAGE:
    if (capteur == LOW) {
      etatTrain0 = WAGON;
    }
    else {
      if (compteur < dureeAttelage) {
        compteur++;
      }
      else {
        // ici changer l'aiguille
      }
    }
    break;
}    

j'ai tout écrit sans compiler ni tester et il faut également gérer les deux gares mais c'est l'esprit

Merci de ton aide !

Je regarde çà tranquillement cet après-midi.

Et si besoin, je crie Au Secours ! (ce qui risque fort d'arriver !     )

En tout cas déjà un grand MERCI !

Un truc que j'ai oublié de préciser sur l'automate :

En rouge les tests qui ont un résultat booléen (on appelle ça aussi des gardes)
En bleu les actions (on appelle ça aussi des étiquettes)

Bien, j'ai "potassé" ton message, et pense avoir compris le principe (du moins je l'espère   ).

Ci-dessous en BLEU ce que je pense avoir compris  (merci de corriger si j'ai mal interprété )
et en ROUGE mes interrogations.


// les états que l'automate peut prendre
enum { ATTENTE, WAGON, ATTELAGE };
// Ok, ici on décline les trois états possibles pour "etatTrain0".
// Mais comment "enum" sait-il qu'on lui parle d'"etatTrain0". Ne faut-il pas le préciser après "enum"
// Est-il normal que lorsque l'on tape cette ligne dans le programme Arduino, "enum" reste en noir et non en rouge/orange comme les autres fonctions ?


byte etatTrain0 = ATTENTE;
// Ici je pense qu'on donne la valeur "ATTENTE" à "etatTrain0" (valeur de démarrage)
// Mais d'après la référence Arduino, "byte" déclare une variable de type octet (8 bits) qui stocke un nombre entier non-signé, soit une valeur de 0 à 255. Concrétement il y a donc quelle valeur dans "etatTrain0" ? Est ce en rapport à l'ordre d'énumération ?

int compteur0;
// On crée une variable "compteur0" de type entier

const unsigned long dureeAttelage = 50;
// On crée une constante "dureeAttelage" de type long (=ou> à zéro) dans laquelle on stocke la valeur estimée d'intervalle entre 2 wagons (en nombre de ticks)



byte capteur = digitalRead(pinCapteur);
// on crée une variable "capteur" type nombre entier dans lequel est stocké le résultat de lecture du capteur (donc j'imagine 1 pour High et 0 pour Low)

switch (etatTrain0)
// On bascule sur l'un des 3 "Case" ci-dessous en fonction d'"etatTrain0"
{
 case ATTENTE:
   if (capteur == LOW) {
     etatTrain0 = WAGON;
   }
   break;
// On était en "ATTENTE", si le capteur est en état de détection on bascule "etatTrain0" en état "WAGON", et on sort de la boucle switch pour atteindre le premier "else".


 case WAGON:
   if (capteur == HIGH) {
     etatTrain0 = ATTELAGE;
     compteur0 = 0;
   }
   break;
// On était en "WAGON", si le capteur est inactif on bascule "etatTrain0" en état "ATTELAGE", on met à zéro le compteur0 et on sort de la boucle switch pour atteindre le premier "else".

 case ATTELAGE:
   if (capteur == LOW) {
     etatTrain0 = WAGON;
   }
// On était en "ATTELAGE", si le capteur est en état de détection on bascule "etatTrain0" en état "WAGON" on continue le déroulement du programme.

   else {
     if (compteur < dureeAttelage) {
       compteur++;
     }
// On vérifie que le compteur reste inférieur à "DureeAttelage". Si oui on considére que le train n'est pas fini, on incrémente le compteur
// Sinon on passe à la ligne suivante.
// Je pense qu'il faut remplacer compteur par compteur0 ?

     else {
       // ici changer l'aiguille  Ici on délivre l'impulsion
     
     }
   }
   break;
}

// Là je ne sais pas où on repart .....Depuis le début ?? Puisqu'il faut remettre à zéro le compteur , remettre en état ATTENTE, en revanche inutile de relire l'"enum"
Sachant qu'il manque avant tout çà, toutes les définitions des broches, et des E/S


Voilà le résultat de ma lecture   et de ma réflexion   

En revanche comme j'ai deux détecteurs par sens de marche, il faut que je multiplie çà par 4 ! (ou au moins en partie)
La variable compteur doit pouvoir par exemple servir de manière indifférente pour les deux quais DU MEME SENS, la variable "dureeAttelage" est identique pour les 4 quais.

Bouh ! Cà fume au dessus de ma tête, heureusement que le détecteur de fumée est plus loin     

VAUBAN38 a écrit:

// les états que l'automate peut prendre
enum { ATTENTE, WAGON, ATTELAGE };
// Ok, ici on décline les trois états possibles pour "etatTrain0".
// Mais comment "enum" sait-il qu'on lui parle d'"etatTrain0". Ne faut-il pas le préciser après "enum"
// Est-il normal que lorsque l'on tape cette ligne dans le programme Arduino, "enum" reste en noir et non en rouge/orange comme les autres fonctions ?

enum est une façon de déclarer plusieurs constantes entières. Le compilateur se charge de leur donner une valeur tout seul (en fait il démarre à 0 je pense). Donc on n'a pas besoin de dire que ça concerne etatTrain0. Ça permet d'éviter de déclarer manuellement des constantes et ça évite de donner à deux constantes la même valeur par erreur.

Citation :

byte etatTrain0 = ATTENTE;
// Ici je pense qu'on donne la valeur "ATTENTE" à "etatTrain0" (valeur de démarrage)
// Mais d'après la référence Arduino, "byte" déclare une variable de type octet (8 bits) qui stocke un nombre entier non-signé, soit une valeur de 0 à 255. Concrétement il y a donc quelle valeur dans "etatTrain0" ? Est ce en rapport à l'ordre d'énumération ?

Oui c'est en rapport avec l'ordre de l'énumération. Tant que l'énumération a 256 items ou moins, c'est ok.

Citation :

int compteur0;
// On crée une variable "compteur0" de type entier

Oui

Citation :

const unsigned long dureeAttelage = 50;
// On crée une constante "dureeAttelage" de type long (=ou> à zéro) dans laquelle on stocke la valeur estimée d'intervalle entre 2 wagons (en nombre de ticks)

Oui

Citation :

byte capteur = digitalRead(pinCapteur);
// on crée une variable "capteur" type nombre entier dans lequel est stocké le résultat de lecture du capteur (donc j'imagine 1 pour High et 0 pour Low)

Oui

Citation :

switch (etatTrain0)
// On bascule sur l'un des 3 "Case" ci-dessous en fonction d'"etatTrain0"

Oui

Citation :

{
 case ATTENTE:
   if (capteur == LOW) {
     etatTrain0 = WAGON;
   }
   break;
// On était en "ATTENTE", si le capteur est en état de détection on bascule "etatTrain0" en état "WAGON", et on sort de la boucle switch pour atteindre le premier "else".

Presque. Switch n'est pas une boucle. J'ai supposé que switch était dans loop() avec un delay(10);

Les case du switch se terminent au break; le else fait partie du if qui est dans le case ATTELAGE. Quand on sort d'un case par break on saute à l'accolade qui ferme le switch

Citation :

 case WAGON:
   if (capteur == HIGH) {
     etatTrain0 = ATTELAGE;
     compteur0 = 0;
   }
   break;
// On était en "WAGON", si le capteur est inactif on bascule "etatTrain0" en état "ATTELAGE", on met à zéro le compteur0 et on sort de la boucle switch pour atteindre le premier "else".

Oui (sauf pour la boucle et le else)

Citation :

 case ATTELAGE:
   if (capteur == LOW) {
     etatTrain0 = WAGON;
   }
// On était en "ATTELAGE", si le capteur est en état de détection on bascule "etatTrain0" en état "WAGON" on continue le déroulement du programme.

Oui

Citation :

   else {

Ce else correspond au if ci-dessus (ie si capteur != LOW, donc HIGH)

Citation :

     if (compteur < dureeAttelage) {
       compteur++;
     }
// On vérifie que le compteur reste inférieur à "DureeAttelage". Si oui on considére que le train n'est pas fini, on incrémente le compteur
// Sinon on passe à la ligne suivante.
// Je pense qu'il faut remplacer compteur par compteur0 ?

Oui c'est compteur0. Le compteur est décrémenté et on reste dans l'état ATTELAGE.

Citation :

     else {
       // ici changer l'aiguille  Ici on délivre l'impulsion
     
     }
   }
   break;
}

// Là je ne sais pas où on repart .....Depuis le début ?? Puisqu'il faut remettre à zéro le compteur , remettre en état ATTENTE, en revanche inutile de relire l'"enum"
Sachant qu'il manque avant tout çà, toutes les définitions des broches, et des E/S

Ceci est dans loop

Citation :

En revanche comme j'ai deux détecteurs par sens de marche, il faut que je multiplie çà par 4 ! (ou au moins en partie)
La variable compteur doit pouvoir par exemple servir de manière indifférente pour les deux quais DU MEME SENS, la variable "dureeAttelage" est identique pour les 4 quais.

On va généraliser à 4 sans bricolage

Je vais détailler tout ça plus tard

Merci PROF !

Bon, j'ai pas trop mauvais, mauvais .... par contre un peu (beaucoup...) mal à la tête. !  

Une seule chose me chagrine, tu dis :



    if (compteur < dureeAttelage) {
      compteur++;
    }
// On vérifie que le compteur reste inférieur à "DureeAttelage". Si oui on considére que le train n'est pas fini, on incrémente le compteur
// Sinon on passe à la ligne suivante.
// Je pense qu'il faut remplacer compteur par compteur0 ?


Oui c'est compteur0. Le compteur est décrémenté et on reste dans l'état ATTELAGE.
Ok pour le maintien en ATTELAGE mais ++ c'est pas une incrémentation ?


En tout cas encore un grand merci, pour le temps consacré !

J'attends la suite avec délectation      

VAUBAN38 a écrit:

Une seule chose me chagrine, tu dis :



    if (compteur < dureeAttelage) {
      compteur++;
    }
// On vérifie que le compteur reste inférieur à "DureeAttelage". Si oui on considére que le train n'est pas fini, on incrémente le compteur
// Sinon on passe à la ligne suivante.
// Je pense qu'il faut remplacer compteur par compteur0 ?


Oui c'est compteur0. Le compteur est décrémenté et on reste dans l'état ATTELAGE.
Ok pour le maintien en ATTELAGE mais ++ c'est pas une incrémentation ?

Si si, erreur de ma part

Je vais détailler un peu plus le dernier item du switch qui est le plus compliqué

J'ai repris le dessin de l'automate en colorant les transitions (flèches) sortantes de ATTELAGE
De plus j'avais oublié de repasser dans l'état ATTENTE sur la flèche verte



 case ATTELAGE:
   if (capteur == LOW) { // capteur == LOW
     etatTrain0 = WAGON;
   }
   else { // capteur est HIGH
     if (compteur0 < dureeAttelage) { // HIGH && compteur < dureeAttelage
       compteur++;
     }
     else { // HIGH && compteur ≥ dureeAttelage
       etatTrain0 = ATTENTE;
       // ici changer l'aiguille
     }
   }
   break;

Et voici comment on généralise à autant de gare que l'on veut en changeant très peu de choses dans le code. Chaque voie de stockage est une gare.

les variables qui contiennent l'état de la gare et le compteur deviennent des tableaux indexés par le numéro de la gare. La broche sur laquelle le capteur est connecté devient un tableau de constantes.

Les 4 automates vont évoluer indépendamment les uns des autres toutes les 10ms via la boucle avec comme index la variable gare. Donc toutes les 10ms chaque gare est traitée.

Citation :

// les états que l'automate peut prendre
enum { ATTENTE, WAGON, ATTELAGE };

const int pinsCapteur[4] = {2, 3, 4, 5}; // par exemple
byte etatTrain[4] = {ATTENTE, ATTENTE, ATTENTE, ATTENTE};
byte compteur[4];

const unsigned long dureeAttelage = 50;

void setup()
{
  int gare;
  
  for (gare = 0; gare < 4; gare++) {
    pinMode(pinsCapteur[gare], INPUT);
  }
}

void loop()
{
  int gare;
  
  for (gare = 0; gare < 4; gare++) {
    
    byte capteur = digitalRead(pinsCapteur[gare]);
  
    switch (etatTrain[gare])
    {
      case ATTENTE:
        if (capteur == LOW) {
          etatTrain[gare] = WAGON;
        }
        break;
      case WAGON:
        if (capteur == HIGH) {
          etatTrain[gare] = ATTELAGE;
          compteur[gare] = 0;
        }
        break;
      case ATTELAGE:
        if (capteur == LOW) {
          etatTrain[gare] = WAGON;
        }
        else {
          if (compteur[gare] < dureeAttelage) {
            compteur[gare]++;
          }
          else {
            etatTrain[gare] = ATTENTE;
            // ici changer l'aiguille
          }
        }
        break;
    }
  }
  
  // attente de 10ms entre 2 analyses du système
  delay(10);  
}

jlb a écrit:

Et voici comment on généralise à autant de gare que l'on veut en changeant très peu de choses dans le code. Chaque voie de stockage est une gare.

Hello jlb, là j'en suis comme deux ronds de flan... Super travail que tu as fait... Il ne nous reste "plus qu'à" !!! Merci à tous ceux qui contribuent à enrichir nos connaissances.  

Bon aller, juste "une" question :  quel logiciel utilises-tu pour les schémas, notamment celui du dessin de l'automate ?

Excellente journée à tous.

Merci

J'utilise Omnigraffle : http://www.omnigroup.com/omnigraffle mais c'est pour Mac OS X et iPad seulement

Mais il reste un détail : comment faire des choses différentes dans

// ici changer aiguille

selon la gare

La suite au prochain numéro

OUAOUUUH ! Cà décoiffe !

Si Class66 en est comme deux ronds de flan, alors moi qui débutes en Arduino, ......j'suis carrément décalqué dans le mur comme dans tout bon dessin animé de Tex Avery !!!    

Je n'ai que deux mots à rajouter :

CHAPEAU L'ARTISTE !    

Et bien sûr te redire encore un énorme Merci !  

Bonjour à tous,

Bravo Jlb pour la machine à états finis et sa réalisation. C'est un bel exemple de programmation synchrone et c'est sur le même principe que fonctionnent les programmes du TCO et du PN de mon réseau.

Si le temps d'exécution des instructions à faire chaque 20 ms devient trop important, il y aura une dérive car ce temps s'ajoutera aux 20 ms. Cela peut poser problème si on compte le nombre d'itérations pour réaliser un timer. J'ai eu cet effet avec la gare de Jappy et j'ai remplacé

Code:

_delay_ms(20);

par le test de la valeur d'un timer intégré à l'AVR. Au début de chaque itération, le timer est réinitialisé, à la fin, on attend qu'il ait atteint la valeur correspondant à 20 ms. Ainsi, pas de dérive car le timer continue à compter parallèlement à l'exécution des instructions.

Pour revenir sur la commande d'un relais bistable, on peut tout simplement remplacer le relais bistable par un relais ordinaire avec un Arduino ou un tout microcontrôleur. Une variable peut mémoriser l'état du relais et c'est la combinaison relais ordinaire + Arduino / microcontrôleur qui en fait un relais bistable.

S'il est important de retrouver le dernier état au démarrage, on peut mémoriser l'état en EEPROM et la relire au démarrage.

Je détaillerai très prochainement ces techniques sur mon blog. Bien qu'elles aient été mises en oeuvre en C standard pour un Atmega, sans les librairies Arduino, elles sont certainement adaptables à l'Arduino car il comporte aussi un Atmega.

SavignyExpress a écrit:

Pour revenir sur la commande d'un relais bistable, on peut tout simplement remplacer le relais bistable par un relais ordinaire avec un Arduino ou un tout microcontrôleur. Une variable peut mémoriser l'état du relais et c'est la combinaison relais ordinaire + Arduino / microcontrôleur qui en fait un relais bistable.

S'il est important de retrouver le dernier état au démarrage, on peut mémoriser l'état en EEPROM et la relire au démarrage.

Tout a fait c'est le principe des systemes a scrutation

une condition vraie a un passage actionne une sortie ou effectue une action ( if x = 1 then y = 1 ) si la condition else n'est pas precisée y est toujours y = a 1 au prochain passage meme si x = 0

une autre condition met y a 0 ( if z = 1 then y = 0 )

on a realisé une sortie identique a un bistable qui peut actionner un relais simple

A+ JL

Bonjour,

Il reste donc a gérer les aiguilles. On a vu comment concevoir un système avec un automate par gare qui évolue au rythme des ticks à 10ms et en fonction des conditions (ou des gardes) et qui effectue des actions sur les transitions d'un état à un autre.

Pour les aiguilles, il faut envoyer des impulsions aux relais et aux moteurs d'aiguille. cette impulsion doit durer un certain temps. On serait tenté d'utiliser delay mais si on fait cela, on casse le rythme du tick et on empêche les automates d'évoluer au cours du temps. Nous allons donc faire exactement la même chose pour les gares : utiliser un automate par aiguille (enfin par paire d'aiguille étant donné que les deux aiguilles au bout de chaque paire de gare fonctionnent conjointement). Et ces automates évolueront au rythme du tick à 10ms. Ceci permet de gérer plusieurs systèmes en parallèle.

L'automate de gestion d'une aiguille est donc comme ceci :



Les deux états DEVIEE et DROITE représente la position de l'aiguille. Les deux autres états PULSE_DEVIEE et PULSE_DROITE sont employés pour la temporisation de l'impulsion de commande. L'impulsion sur la commande pour mettre l'aiguille en position déviée est mise à HIGH lors de la transition de DROITE vers PULSE_DEVIEE et mise à LOW lors de la transition de PULSE_DEVIEE vers DEVIEE. On laisse passer le temps dans PULSE_DEVIEE pour déterminer la durée de l'impulsion avec un compteur. Idem avec la commande pour mettre l'aiguille en position droite.

Les gardes position_deviee et position_droite sont des actions de l'automate de détection des trains.

Voici pour compléter une vue du système :

Là j'avoue avoir un peu du mal à cerner le point !

Je pense que ce sera plus clair pour moi, avec le code, et que je verrai mieux les enchaînements......  

Pour ce qui est des aiguillages, la gestion par paire n'est à mon sens pas forcément une obligation, selon les modèles d'aiguillage (non polarisé) on peut me semble-t-il tout à fait imaginer un aiguillage "sortie" non motorisé et utilisé en talonnement.
Mais çà ne change cependant rien au programme...