Automatisation de réseau

Bonsoir à tous

Comme indiqué dans ma présentation, je suis en Ho, mais je me sens bien chez vous !

En quelques lignes mon projet : un réseau avec une boucle externe en os de chien et à l'intérieur les gares voyageurs, triages et stockage.
Mon but est d'automatiser la boucle externe (certains l'appelle voie de parade). Je vais essayer de calquer la réalité, mais parfois pour des raisons pratiques je flirterai avec elle ... Mon but n'est pas de reproduire fidèlement la réalité mais de m'en approcher le plus possible.

Mon, cahier des charges est relativement limité : Six cantons sur la boucle, 2 aiguillages de sortie, 2 aiguillage d'entrée et sur chaque deuxième voie des aiguillages une voie en provenance ou destination des gares internes. (cf PJ (si je peux) pour plus de compréhension ...). Les convois sont préparés sur les gares puis prépositionnés sur les voies d'entrée. L'automate les prend alors en charge ... A noter que pour ce projet les gares internes sont gérées manuellement.

Il est à noter que les voies de sortie et d'entrée devront être gérées en manuel et en automatique (détail dans la suite).

A cet instant je ne me suis pas décidé sur la technologie d'automatisation, pc + cartes d'interface ou pic / arduino ou autres "automates" et pour le Tco c'est itou : un écran de pc (tactile ?) ou un Tco classique avec bascules et poussoir ... Un point est sur je ne suis pas en digital mais bien en analogique dans le sens ou aucun décodeur n'existe dans les locomotives ou autres appareils de voie.

La détection d'occupation de canton ou zone sera réalisée à l'aide de détecteurs à consommation de courant de type DMARRION (cf Dominique sur ce forum) ou en double T (cf site amfn).
L'alimentation des cantons sera soit en PWM soit via des CNA ... Ces deux choix vont dépendre du choix pc ou "automate" ...

Je tiens à remercier tous les contributeurs de forum, site internet en France et à l'étranger chez qui j'ai "piqué" des idées, des trucs ...

Je vous présente l'avancé de mon projet fonction par fonction. Mon but ? Avoir vos remarques et mettre en exergue ce que j'ai pu omettre ...
Je ne vais pas poster en une seule fois tout le projet car le suivi en serait difficile pour tous.
Les fonctions et règles sont généralement explicitées en français (en littéral dirions nous) et parfois complété de pseudo code. Ce pseudo code, très orienté C permet de faire tourner les algorithme. Attention la traduction de certaines règles peuvent introduire des notions "poussées" de programmation.
D'autre part, je travaille souvent en boolean. Ainsi un canton est occupé ou non occupé. Ce qui est dans ma logique différent de occupé ou libre ... Enfin parfois, au lieu de faire des cascades de if, incompréhensibles, j'utilise volontiers les poids binaires (cf plus loin).

Ci-après le logique générale de l'automate (nom que je donne au système) :

Logique générale

Début
Initialisation
Tant que non fin demandée
Lire les détecteurs
Lire le Tco
Si non fin demandée
Mise à jour des signaux en fonction des détecteurs et du Tco
Action sur aiguillages, nécessaire et possible
Calculer les vitesses de consigne
Transmettre instruction au cartes hardware
Fin si
fin tant que
Sortie
Fin

Quelques hypothèses que j'ai pris :

Un canton est composé dans le sens de circulation de :
 * un signal à l'entrée
 * une zone pleine voie (zp)
 * une zone d'arrêt (za)

un Za, Zp ou aiguillage est un segment. Tous les segments sont munis d'un détecteur de consommation de courant.

Les aiguillages pris en pointe font partie du canton qui le précède et c'est un segment après la Za. En théorie aucun convoi ne devrait y stationner
Les aiguillages pris en talon font partie du canton aval et c'est un segment qui précède la Zp. On peut considérer que la Zp est agrandie de la longueur de l'aiguillage.

Afin de vous présenter la suite, quelques explications sur les structures et les variables dans les logiques et pseudo codes (Orienté C of course).


const byte NB_CANTONS = 14;
const byte NB_SEGMENTS = 24;
const boolean OQP = true;

typedef struct {
numero int
etat boolean
} t_segment;

typedef struct {
aig t_segment
talon boolean // true = l'aiguille est prise en talon
devie boolean // true = l'aiguillage est dévié
suivant byte // numéro du canton dévié
} t_aiguillage

typedef struct {
rouge boolean
jaune boolean
vert boolean
} t_signal;


// la structure signal permet de garder le bit de la lampe à allumer
// elle permet d'envoyer directement les 3 bits (sans codage / décodage) vers une interface I/O TTL/CMOS)

typedef struct {
num byte
switch boolean //true c'est un aiguillage
aig t_aiguillage // si switch est vrai alors aig est renseigné
etat boolean   // true si za ou zp occupée
za t_segment // zone arret
zp t_segment // zone pleine voie
signal t_signal
signal_svg t_signal
f_vitesse byte // permet de connaître l'algorithme de vitesse à appliquer au canton cf plus bas
} t_canton;

t_canton v_canton[ NB_CANTONS ];
boolean v_etat_detecteur[ NB_SEGMENTS ]; // les détecteurs sont numérotés. v_etat_detecteur[ 0 ] corespond au détecteur physiqe 0, 1 au 1 ...

// Explications sur les variables.
// t_signal
// Un signal est composé de 3 "lampes" Rouge, Jaune et vert. A voir si d'autres "lampes" sont nécessaires.
// Pour le moment, un boolean est affecté à une lampe : true allumée, false éteinte.

// v_etat_detecteur
// Chaque détecteur à un numéro "cablé" qui est le xème élément du tableau v_etat_detecteur.
// les détecteurs sont numérotés. v_etat_detecteur[ 0 ] corespond au détecteur physiqe 0, 1 au 1 ...
// La lecture des détecteurs met à jour ce tableau
// Dans le tableau v_canton, les membres za.num et zp.num font référence à ce numéro.
// Ce qui permet une "certaine" liberté dans le cablage et l'affectation des détecteurs aux Zp et Za des cantons

// f_vitesse : faire référence à la logique/fonction de gestion de la vitesse pour un canton :
// Note : Adapter indique augmenter ou diminuer ...
// ROUGE : indique que l'algorithme doit adapter la vitesse dans la Zp jusqu'à la vitesse de consigne feu ROUGE du canton ou la maintenir si elle est atteinte et mettre à 0 la ZA
// JAUNE : indique que l'algorithme doit adapter la vitesse des Zp et ZA à la vitesse de consigne feu JAUNE du canton ou la maintenir si elle est atteinte
// VERT  : indique que l'algorithme doit adapter la vitesse des Zp et ZA à la vitesse de consigne feu VERT du canton ou la maintenir si elle est atteinte
// ARRET : indique que les Zp et Za du canton sont à 0


Initialisation : cette fonction initialise le réseau à un état connu et simple. C'est pourquoi une étape manuelle peut être nécessaire en cas de coupure brutale.
// **** STEP MANUEL
Chaque convoi doit être sur un et un seul canton et dont au moins un essieu (détectable) sur la Za
// ****
Tous les signaux sont positionné au Rouge
Toutes les fonctions f_vitesse sont à ARRET
Lire l'état de tous les détecteurs dans le tableau v_etat_detecteur (cf logique plus bas)
Mise à jour des signaux (cf logique plus bas)
Mise à jour des fonctions f_vitesse pour tous les cantons dont le signal n'est pas ROUGE
A la fin de l'initialisation, les convois sont détectés et les vitesses à 0, les signaux positionnés en fonction de l'occupation réelle.


// Sortie : cette fonction initialise le réseau à un état permettant un redémarrage sans intervention manuelle
Mettre les signaux à R selon possibilité (cf règle plus loin)
Tant que vitesse de consigne de tous les cantons différent de ARRET
Calculer les vitesses de consigne
Transmettre instruction au cartes hardware
fin tant que
//**** STEP MANUEL
Chaque convois doit être sur un et un seul canton et dont au moins un essieu (détectable) sur la Za
// ****


Je m'arrête pour ce soir car je m'aperçois que si ce début est clair dans ma tête, mon écris n'est pas aussi limpide ...

A bientôt pour la suite

Alain

J'ajoute le lien pour le plan du réseau : https://servimg.com/view/18935398/4

Bonjour,

A la lecture de ton post, je me dis que le passage au digital, avec pilotage par PC/logiciel,  simplifierai beaucoup la réalisation de ce que tu veux faire ...   

A+
Georges

Bonjour à tous,

Le passage au digital est bien sûr une option, mais je comprends aussi le choix et l'intérêt de développer une solution analogique maison. Outre le fait de maîtriser totalement ce que l'on fait, le plaisir de l'avoir réalisé soi-même est inestimable.

Pour Alain, il est possible de publier du code source en conservant l'indentation à l'aide des balises code. On remarquera que les balises elles-mêmes sont nécessaires pour décrire des balises sans qu'elles soient interprétées !

Code:

[code]Copier le code source ici[/code]

Exemple:

Code:

...
#define TIMER_ARRET  100
...
void AttendreTrain(uint8_t nxAttente)
{
    if(nTimer == 0)
    {
        ...
    } // if
    ...
} // AttendreTrain

Bonne fin de semaine à tous.

Bonjour à tous,

Cela fait maintenant près de 4 ans que je planche sur ce projet et que je teste des montages divers et variés, que je lis des forums, des livres et étudie les différences entre Analogique et Digital.
Bien sur il y a des différences majeures en Digital et Analogique pur. C'est à dire sans électronique. Mais l'écart se réduit quand une couche, plus ou moins épaisse, d'électronique est ajouté à l'analogique pur.

D'un coté du presque tout fait, du quasi plug & play, mais tout n'est pas fait et une partie reste à faire et de l'autre, on réinvente presque tout d'où des prises de têtes, des tests, de retours arrière.

Mais je suis sur que pour les deux, quels plaisirs quand le résultat de la réalisation est e que l'on imaginait ou tout du moins s'en approche !!!


Je profite de cette réponse pour republier le pseudo code avec les balises (c'est vrai que c'est pus lisible, Merci SavignyExpress)

Code:

Logique générale

Début
   Initialisation
   Tant que non fin demandée
      Lire les détecteurs
      Lire le Tco
      Si non fin demandée
         Mise à jour des signaux en fonction des détecteurs et du Tco
         Action sur aiguillages, nécessaire et possible
         Calculer les vitesses de consigne
         Transmettre instruction au cartes hardware
      Fin si
   fin tant que
   Sortie


const   byte       NB_CANTONS   = 14;
const   byte       NB_SEGMENTS   = 24;
const   boolean    OQP       = true;

typedef struct {
   numero      int
   etat      boolean
} t_segment;

typedef struct {
   aig      t_segment
   talon   boolean // true = l'aiguille est prise en talon
   devie   boolean // true = l'aiguillage est dévié
   suivant   byte    // numéro du canton dévié
} t_aiguillage

typedef struct {
   rouge   boolean
   jaune    boolean
   vert   boolean
} t_signal;      


// la structure signal permet de garder le bit de la lampe à allumer
// elle permet d'envoyer directement les 3 bits (sans codage / décodage) vers une interface I/O TTL/CMOS)

typedef struct {
   num         byte
   switch      boolean      //true c'est un aiguillage
   aig         t_aiguillage // si switch est vrai alors aig est renseigné
   etat      boolean   // true si za ou zp occupée
   za         t_segment // zone arret
   zp         t_segment // zone pleine voie
   signal      t_signal         
   signal_svg   t_signal
   f_vitesse   byte       // permet de connaître l'algorithme de vitesse à appliquer au canton cf plus bas
} t_canton;

t_canton    v_canton[ NB_CANTONS ];
boolean      v_etat_detecteur[ NB_SEGMENTS ]; // les détecteurs sont numérotés. v_etat_detecteur[ 0 ] corespond au détecteur physiqe 0, 1 au 1 ...


// Explications sur les variables.
// t_signal
// Un signal est composé de 3 "lampes" Rouge, Jaune et vert. A voir si d'autres "lampes" sont nécessaires.
// Pour le moment, un boolean est affecté à une lampe : true allumée, false éteinte.

// v_etat_detecteur
// Chaque détecteur à un numéro "cablé" qui est le xème élément du tableau v_etat_detecteur.
// les détecteurs sont numérotés. v_etat_detecteur[ 0 ] corespond au détecteur physiqe 0, 1 au 1 ...
// La lecture des détecteurs met à jour ce tableau
// Dans le tableau v_canton, les membres za.num et zp.num font référence à ce numéro.
// Ce qui permet une "certaine" liberté dans le cablage et l'affectation des détecteurs aux Zp et Za des cantons

// f_vitesse : faire référence à la logique de gestion de la vitesse pour un canton :
// Note : Adapter indique augmenter ou diminuer ...
// ROUGE : indique que l'algorithme doit adapter la vitesse dans la Zp jusqu'à la vitesse de consigne feu ROUGE du canton ou la maintenir si elle est atteinte et mettre à 0 la ZA
// JAUNE : indique que l'algorithme doit adapter la vitesse des Zp et ZA à la vitesse de consigne feu JAUNE du canton ou la maintenir si elle est atteinte
// VERT  : indique que l'algorithme doit adapter la vitesse des Zp et ZA à la vitesse de consigne feu VERT du canton ou la maintenir si elle est atteinte
// ARRET : indique que les Zp et Za du canton sont à 0


//

// Initialisation au démarrage
// **** STEP MANUEL
   Chaque convois doit être sur un et un seul canton et dont au moins un essieu (détectable) sur la Za
// ****
   Tous les signaux sont positionné au Rouge
   Toutes les fonctions f_vitesse sont à ARRET
   Lire l'état de tous les détecteurs dans le tableau v_etat_detecteur (cf logique plus bas)
   Mise à jour des signaux (cf logique plus bas)
   Mise à jour des fonction f_vitesse pour tous les cantons dont le signal n'est pas ROUGE
   A la fin de l'initialisation, les convois sont détectés et les vitesses à 0, les signaux positionnés en fonction de l'occupation réelle.


// Sortie
   Mettre les signaux à R selon possibilité
   Tant que vitesse de consigne de tous les cantons différent de ARRET
      Calculer les vitesses de consigne
      Transmettre instruction au cartes hardware
   fin tant que
//**** STEP MANUEL
   Chaque convois doit être sur un et un seul canton et dont au moins un essieu (détectable) sur la Za
// ****

Bonjour à tous,

Un peu de détail sur le l'algorithme général.

Fonction Lire détecteurs.
Cette fonction est en charge de :
 1 - récupérer l'information d'occupation des segments de voie. Les détecteurs sont numérotés de 0 à 24 (correspondant aux 24 segments de la boucle).
La lecture physique met à jour un tableau de boolean v_etat_detecteurs. v_etat_detecteur[ x ] = TRUE si le canton est occupé, false si il est non occupé.
 2 - gére la valeur de signal_svg utilisé pour calculer f_vitesse : si le canton passe non occupé à occupé, la couleur du signal est sauvegardé dans signal_svg. Si le canton passe de occupé à libre, signal_svg est mis à null
 3 - mettre à jour l'état du canton. Si une des deux (ou trois) segment du canton est occupé alors le l'état passe à occupé. Si aucun des segments est occupé alors l'état du canton est non occupé (boolean FALSE).
Note : le membre etat est un boolean indiquant si le canton est occupé ou non occupé. Il serait plus judicieux que j'appelle ce membre oqp ...
Note 2 : cf explication des variables pour les relations entre v_etat_detecteurs et v_cantons

Fonction Mise à jour des signaux en fonction des détecteurs et du Tco

Règles : // Mise à jour des signaux
- le signal est rouge si la zone d’arrêt avale ou la zone pleine voie avale est occupée (le canton aval est occupé)
- le signal est jaune si le signal suivant est rouge et la zp avale est libre et la za avale est libre (le canton aval est non occupé et le signal suivant est rouge)
- le signal est vert  si le signal suivant n'est pas rouge et la zp avale est libre et la za avale est libre (le canton aval est non occupé et le signal suivant est non rouge)

Ci-après le pseudo code de ces trois règles appliquées à ma boucle

Code:

Si la zone avale n'est pas un aiguillage
   le signal est rouge si le canton aval est occupé
   le signal est jaune si le signal suivant est rouge et le canton aval est non occupé
   le signal est vert si le signal suivant n'est pas rouge et le canton aval est non occupé

Si la zone avale est un aiguillage en pris en aiguille (de 1 voie vers 2 voies)
    le signal est rouge si
          ( l'aiguillage est occupé
        ou l'aiguillage est dévié et le canton dévié est occupé
        ou l'aiguillage est droit et le canton droit est occupé )
     le signal est jaune si // attention aux parenthèses ...
           ( l'aiguillage est non occupé
         et (     ( l'aiguillage est dévié et le canton dévié est non occupé et le signal du canton dévié est rouge )
               ou ( l'aiguillage est droit et le canton droit est non occupé et le signal du canton droit est rouge ) )
      le signal est vert si // attention aux parenthèses ...
           ( l'aiguillage est non occupé
         et (     ( l'aiguillage est dévié et le canton dévié est non occupé et le signal du canton dévié n'est pas rouge )
               ou ( l'aiguillage est droit et le canton droit est non occupé et le signal du canton droit n'est pas rouge ) )

Si la zone avale est un aiguillage en pris en talon (de 2 voie vers 1 voies) // valable pour les deux voies convergentes vers l'aiguillage)
   le signal est rouge si
         ( l'aiguillage est occupé ou le canton aval est occupé ou le canton adjacent n'est pas rouge ou la position de l'aiguille ne correspond pas au canton )
   le signal est jaune si   
         ( l'aiguillage n'est pas occupé et le canton adjacent est rouge et le canton suivant est libre et le signal du canton suivant est rouge et la position de l'aiguille correspond au canton )
   le signal est vert si   
         ( l'aiguillage n'est pas occupé et le canton adjacent est rouge et le canton suivant est libre et le signal du canton suivant n'est pas rouge et la position de l'aiguille correspond au canton )

Envoyer signaux aux cartes

A noter que le Tco  n'est pas encore pris en compte.

A vos remarques  

Alain

Bonjour Alain90, J'ai commencé un projet identique en analogique avec Arduino et carte de DMarrion…
Je suis interessé par des photos et schemas et developpement de ton projet.
Alors si à un moment tu peux "detailler" celui ci…
Car j'ai cru comprendre que tu avais en plus quelques aptitudes en informatique…
pour info : Il y a le locoduino qui est un splendide projet et ou je trouve pas mal d'idées et d'info…
locoduino
(mais je suppose que tu l'as déjà vu depuis longtemps…)
Je suis persuadé que coupler les cartes cantons de DMarrion et l'arduino pour la gestion du trafic est une solution extrement "sympa"… Sans parler des automatismes supplémentaires possibles en PWM (avec une petite carte L298N ou autre), je dis cela parce que j'ai vu un post avec quelques petits problèmes d'alim Régulateurs à base de 317/338/350… Une carte L298N (pont en H) ne valant que 4 euros (Chine) et délivrant un ampérage suffisant pilotable manuellement ou automatiquement via un arduino, avec pourquoi pas une petite ligne prog pour l'inertie…cela devrait te faire "reflechir"…
exemple : http://www.dx.com/fr/p/l298n-h-bridge-stepper-motor-driver-module-for-arduino-red-147046#.V0RRmtcuPUE
En tout cas impatient de voir ton projet, car le mien est sur les mêmes bases…

Bonsoir Mistigris
Il est vrai que les détecteurs de Dominique sont top.
Je travaille sur une boucle simple à sens unique, avec 9 cantons, avec 4 aiguillages et 4 voie d'injection/éjection permettant d'introduire ou de sortir un convoi de la boucle.

La boucle :



Il y a un détecteur par zone, chaque canton à 1 zone d'arret et une zone pleine voie
Afin de gagner des ports sur l'Arduino, je passe par des 74HC4067.
une simple lecture et hop je sais qui est occupé. Après facile de calculer la couleur des signaux !

Une petite photo des détecteurs


A noter que les diodes sont très utiles pour le débug. Par contre j'aurais du les mettre sur le TCO !

Pour la partie alimentation, je passe par le même type de carte que celle de dx.com, dont la tension est donnée par une pwm et celle-ci dépend de la couleur du signal et de la zone occupée !

Rien de bien sorcier si ce n'est que parfois il faut se creuser la tête pour certaines situations mais ce n'est que de la logique, rien n'est gravé dans le marbre !

Belle soirée !

A ouais quand même Y a du fil
En ce qui me concerne pour gagner des ports et pouvoir avoir de nombreux detecteurs (ILS, infrarouge par exemple… et occupation DMARRION) Je passe par une carte que je suis en train de développer avec des 74HC165 et des 74HC595… cela doit me permettre de gérer un peu plus de 40 capteurs et environ 20 à 30 sorties (relais ou transitor) avec un Arduino Uno… apres la problématique sera la prog (je suis pas tres bon en prog) pour recupérer les données des Shift registrer (5X74HC165)… et puis l'Arduino reussiera t il à gerer tout cela… Bref j'en suis aux tests et j'avance tout doucement après une longue interruption.

Je suis sur une Boucle double sens avec 5 cantons (pareil) dans chaque sens gérer par la carte DMarrion, pour les voies d'ejections, on passe en "manuel" (sans Carte DMARRION)…

Heu… en HO il va faire combien ce reseau à 5 cantons de longueur ? en N je serai sur plus de 5 métres…

Bonsoir
Bon courage, je dois dépasser les 20000 lignes de code avec UTS. Au début c'est simple, mais les complications augmentent nettement avec la complexité du programme.
A+

Je suis assez surpris de la capacité de l'arduino !
Il y a les 30 détecteurs de Dominique (gérés via HC4067), 48 boutons (pour la gestion des itinéraires (gérés via hc134), 10 pwm (une par canton), la gestion des aiguillages (41), ( via hc4067), 13 signaux à trois couleurs (via hc595) et 4 relais d'inversion de sens pour les voies injection/éjection.
Pour la gestion de la gare voyageurs, je voudrais gérer le passage des convois ainsi que l'arrêt (manuel et/ou automatique) le "plus au milieu" du quai ! Je pense que je passerais par un arduino esclave.
Au niveau code, j'ai repris mes standards : fonction simple ne faisant qu'une action et ne devant pas dépasser plus de 20 lignes (page écran). Une fonction ne faisant qu'une action, c'est plus simple pour tester une évolution et une non régression. Exemple sur la fonction de lecture des détecteurs de Dominique :

Code:

void Read_All_Detector( t_all* p_all )
{
  int i, j;
  int v_base = 64; // first cell for captors 0 to 47 btn 64 to 92 captors
  int k;
  DEBUG_PRINT( "begin");

  for ( i = 0; i++; i < 4 )
    pinMode( v_4067_ax[ i ], OUTPUT );
  
  for ( i = 0; i < 2; i++ ) { // for the both cd4067 used for detectors
    for ( j = 0; j < 16; j++ ) { // read 16 inputs
      for ( k = 0; k < 4; k++) {
        //delay(4);
        digitalWrite( v_4067_ax[ k ], bitRead( j, k )); // send bit for a0 a1 a2 a3
      }
      //delay(6);
      if ( i == 0 )
        //p_all->capteur[ i * 16 + j + v_base ] = analogRead( CD4067_Z_DETECT_0 );
        p_all->capteur[ i * 16 + j + v_base ] = not digitalRead( CD4067_Z_DETECT_0 );
      else
        //p_all->capteur[ i * 16 + j + v_base ] = analogRead( CD4067_Z_DETECT_1 );
        p_all->capteur[ i * 16 + j + v_base ] = not digitalRead( CD4067_Z_DETECT_1 );
    }
  }
  DEBUG_PRINT( "end");
}

Pour les tests de mise au point, facile de passer d'une lecture analogique à digital. Autre exemple avec la fonction loop, seulement 20 lignes !
D'autre part, vilaine habitude de ma part, chaque objet à gérer à sa structure. Exemple sur les cantons :

Code:

struct t_segment {
  int         capteur;    // numero de capteur détecteur de courant
  int         oqp;
};

// définition d'un canton
struct t_canton{
  int           num;
  int           oqp; // true si za ou zp occupée
  int           oqp_svg;
  t_segment     za; // zone arret
  t_segment     zp; // zone pleine voie
}

Un canton est découpé en deux segments (ZA et ZP), chacune ayant son détecteur. Pour éviter de me prendre la tête lors du câblage, et également si je dois en changer un, les capteurs sont lus dans un tableau (cf fonction plus haut) et une autre fonction attribue le statut d'occupation au segment :

Code:

void Update_Cantons( t_all* p_all ) {
    // Maj du statut OQP des cantons par rapport au capteurs
 int i;

 // occupation de cantons
 for( i=0; i<NB_CANTONS_LOOP; i++ ) {
    p_all->canton[ i ].za.oqp = p_all->capteur[ p_all->canton[ i ].za.capteur ];
    p_all->canton[ i ].zp.oqp = p_all->capteur[ p_all->canton[ i ].zp.capteur ];
}

Bref c'est de l'indirection et en plus c'est paramétrable simplement lors de l'initialisation. De plus si j'ai un canton particulier (début ou fin par un aiguillage) la ligne de code est très simple. Cas du canton 0 avec un aiguillage en début et fin

Code:

  p_all->canton[ 0 ].oqp = p_all->canton[ 0 ].oqp || p_all->eje_loop[ 0 ].aig.oqp || p_all->inj_loop[ 1 ].aig.oqp;

Autre point sur les structures, toutes mes structures sont elles-mêmes dans une structure.
Ce qui me permet de ne passer qu'un paramètre à mes fonctions et en cas d'évolution, pas de paramètre à modifier.

A ce jour le code brut (avec les commentaires, lignes blanches ...) y compris les initialisations et déclaration de variables ne dépasse pas les 1500 lignes.

Par contre comme dans la vraie vie : pas de code sans spécification écrite des règles puis algorithme en pseudo code précis. Je ne sais combien d'heure j'ai passée pour écrire la spéc de gestion de la vitesse en fonction de la position du train (za/zp), tiré ou poussé, sur un seul canton ou deux (j'ai décidé qu'n convoi ne sera jamais sur trois cantons). Un fois écrite, le pseudo code permet de le faire tourner sur tous les cas possibles, qui vont être difficiles à tester en réel. La mise au point du code c'est faite en une paire d'heures et le plus long et pas encore fini est l'arrêt au plus près du signal. A noter que pour le moment, seul le pwm est géré sur le L298, je n'ai pas encore pris en compte "la roue libre" et "l'arret immédiat".

Alain

Bonjour Alain

Je ne vais pas souvent voir la rubrique "exploitation" sur le forum, et c'est un peu par hasard que je découvre ton fil.

Tout d'abord je te remercie de me citer pour certains éléments de schémas (tu n'es pas obligé c'est libre de droits) et surtout je te félicite pour ton travail impressionnant.

Ensuite, sans rentrer dans les détails de ce que tu as déjà cogité (car il y a de quoi faire !!!), je me permettrais juste la remarque ci-après.
Dans les hypothèses générales, tu expliques la manière dont tu insères les aiguillages dans les cantons :
- Aiguilles en talon intégrées dans le canton aval
- Aiguilles en pointes intégrées en dernier segment du canton amont
Pour moi, ce dernier principe est une erreur (peut-être pas du point de vue technique, mais du point de vue signalisation ferroviaire).
Je sais que tu as expliqué en préambule que tu ne copierais pas intégralement la réalité et que tu souhaitais surtout t'en approcher, mais dans la réalité, en pointe ou en talon d'une aiguille tu trouveras un carré pour protéger les manœuvres de ladite aiguille.
A ta place, j'intégrerais toujours les aiguilles dans le canton aval et pour commander l'accès à ce canton je remplacerais le signal 3 feux (1 rouge 1 vert 1 jaune) à plaque F, c'est à dire un sémaphore,  par un signal 4 feux (2 rouges 1 vert 1 jaune) à plaque nF, c'est à dire un carré.

Bonsoir Dominique,

Il est normal que je te site quand je parle de tes détecteurs. D'une part il sont super, tant du point de vue de la réalisation que de leur utilisation, ils sont de plus , à mon sens, universel et en plus tu n'hésites pas à répondre aux questions qui te sont posées.

Je reviens sur les aiguillages, et je pense que ma présentation manque de précision ou bien, j'ai fait quelques (plusieurs) modifications en cours de route (trop vieux pour m'en souvenir !!!!).

Chaque canton à une zone pleine voie (Zp) et une zone d'arret (Za) qui sont chacun munis d'un détecteur mais d'une alimentation électrique unique. Les aiguillages sont aussi munis de détecteurs et sont rattachés électriquement au canton amont pour ceux pris en pointe et aval pour ceux pris en talon. Le cantons C0 a une pointe et un talon !
Les signaux, non présent dans le schéma précédents, sont en fin de Za et avant tout aiguillage, cf le schéma ci-après :




Donc ils protègent les cantons avals. Par exemple, le signal S3 protège l'aiguillage pris en pointe Aig1 et donc les cantons avals C10 et C4. L'aiguillage pris en talon Aig3 est protégé par les signaux S12 et S8.

C'est l'algorithme qui protège le canton aval. Par exemple (extrait) le signal S0 est RED si l'aiguille est déviée (vers C9) et si C9 est OQP. Le signal SO est RED si l'aiguille est non déviée (dans le sens de la boucle) et si C1 est OQP.

La logique complète :

REGLE 2 : LE SEGMENT AVAL EST UN AIGUILLAGE, PRIS EN AIGUILLE (DE 1 VOIE VERS 2 VOIES)
• le signal est rouge si
o l'aiguillage est occupé
o ou le signal est forcé au rouge
o ou l'aiguillage est dévié et le canton dévié est occupé
o ou l'aiguillage est droit et le canton droit est occupé)

• le signal est jaune si
o l'aiguillage est non occupé
o et (
 ( l'aiguillage est dévié et le canton dévié est non occupé et le signal du canton dévié est rouge )
 Ou ( l'aiguillage est droit et le canton droit est non occupé et le signal du canton droit est rouge )
)
• le signal est vert si
o ( l'aiguillage est non occupé
o et (
 ( l'aiguillage est dévié et le canton dévié est non occupé et le signal du canton dévié n'est pas rouge )
 ou  ( l'aiguillage est droit et le canton droit est non occupé et le signal du canton droit n'est pas rouge ) )

Ma convention : le signal Sx est en fin de la Za du Canton X (Cx) et protège l'entrée du canton X+1 : Si Sx est RED, alors le convoi s'arrête en zone d’arrêt de Cx.

Comme il n'y a pas de gestion câblée, c'est la gestion de l'occupation ou pas d'un segment (Za, Zp, Aig) qui calcule "la couleur" du signal aval.

Par conte, la tension électrique est commune à tout un "canton". C'est à dire qu'électriquement, C0, sa ZA, sa ZP, Aig3 et Aig0 ont la même alimentation. Pourquoi ? Quand on sort de la boucle (éjection), par exemple de C0 à C9, l'alimentation de Aig 0 est donnée par C0, car en cas de pousse, c'est lui le maître. Oui mais en bon maître, il regarde droit devant et voit la couleur de S9 (si aig0 est dévie) (actuellement forcé à RED) et, l'algorithme le sait, C0 et C9 sont OQP par le même convoi, donc l'alimentation C0 est calé sur "ralentir signal rouge" (S9 en fin de C9).

Pour moi cela semble simple ... je me suis relu quelques fois quand j'ai écris puis codé les règles. Mais dans l'ensemble c'est ok. Je dis dans l'ensemble mais pour le moment, à trois convois tout est ok.

Par contre à le réexpliquer maintenant c'est pas du limpide, enfin tu connais un peu la gestion des signaux ... Ca devrait t'aider !!! Si tu as des question ... Envoie les !!!!

Pour les signaux, pour le moment, est prévu que du trois couleurs. Mais un peu plus tard ... Car dans ma logique 1 lampe rouge ou deux lampes, c'est le même algo. "Juste" allumer une lampe de plus ! Bon ok, la logique est écrite, la technique connue (à base de HCT595) mais c'est tout !!!

Mais je peux me tromper, alors n'hésite pas à me faire part de tes remarques.

Belle soirée.

Je pense avoir compris comment tu as procédé :
- Même si une aiguille en pointe est ratachée au canton amont du point de vue alimentation, la gestion de son occupation est faite comme si elle appartenait au canton aval (canton de la voie déviée ou canton de la voie droite suivant la direction donnée).

Du coup, j'ai 2 questions :
1) Soit un canton C terminé par une aiguille en pointe. Lorsqu'un train arrêté dans le canton C redémarre et que la loco quitte le segment Za pour entrer dans le segment Aiguille, comment fais-tu pour que l'occupation de ce segment ne fasse pas recouper l'alimentation dans tout le canton C ? Je suppose que le logiciel identifie précisément cette séquence et gère la situation en conséquence...

2) Quand on "sort de la boucle", comme dans ton exemple du C0 vers le C9, pourquoi avoir choisi l'alimentation du canton C0 comme "maitre" ?

Dans mon PRS, j'ai choisi exactement l'option inverse : c'est le segment de destination qui fournit l'alimentation à tout l'itinéraire.
- D'une part, rien n'empêche de prévoir la tension fournie par cette alim en fonction de la situation (dans ton exemple, une tension réduite car le C9 est une impasse terminée par un rouge)
- D'autre part, cette disposition permet de libérer les aiguilles et de les faire changer de position pour tracer un autre itinéraire au fur et à mesure que le dernier wagon est passé dessus (transit souple). Si j'avais choisi l'alimentation depuis l'origine de l'itinéraire, je serais obligé de le garder tracé jusqu'au dégagement du dernier segment (transit rigide).

Je vais essayer de répondre simplement.
1. Comment ne pas couper l'alimentation.
Soit C(x) le canton sur lequel on "calcule" la vitesse, S(x) le signal en fin du canton C(x) et C(x-1) le canton précédent.
Chaque canton à un flag. Celui est levé si le canton est oqp && la za est oqp && le signal associé est soit RED soit YELLOW. Il est baissé si le canton est libre.
Dans tous les autres cas, le flag n'est pas mis à jour. En effet, quand le convoi entre dans C(x+1), S(x) passe à RED mais le flag n'étant pas mis à jour à ce moment.

La valeur du flag (levé ou baissé) l'occupation ou non de c(x) et c(x-1) permet de savoir si un convoi est à cheval entre deux canton. Dans ce cas, l'alimentation de c(x-1) prend la valeur de l'alimentation de c(x).

2. Pourquoi l'alimentation des aiguilles est celle de la boucle.
Plusieurs solution sont possibles (que j'ai tout du moins "étudiées" ) :
 - les aiguilles sont alimentées indépendamment, comme un canton, cela nécessite un L298 de plus et donc une PWM de plus !
 - les aiguilles sont alimentées par le canton aval (C9 ou C1 selon le sens de l'aiguille) il faut un relai pour basculer l'alimentation entre l'aiguille et C0 ou l'aiguille et C9
 - les aiguilles sont alimentées par le canton de boucle.

J'ajoute un point non décrit jusqu'à présent : les cantons de sortie et d'entrée peuvent servir de canton de manœuvre et de stationnement et peuvent être alimentés par la même alimentation que la gare. La PMW du 298 de ces cantons est donc soit calculée par le programme de la boucle, soit par "le potentiomètre" de gestion manuel de la gare.
C'est la seule façon simple que j'ai trouvé pour basculer l'alimentation d'un canton d'une alim à un autre. (mis à part le relais).

N'hésite pas si tu as besoin de plus de détail.

Belle journée