Catégorie : Uncategorized

La dernière saison du de découverte du micro-contrôleur Arduino s’était terminée sur un bémol: A quoi bon mettre en oeuvre des cartes garnies de relais et autre composants pour transmettre l’état des blocks entre les gares, surtout si ces blocks et gares sont gérées par d’autres micro-contrôleurs et qu’il s’agit en fait d’une série de données binaires qui transitent par le câble 15 pôles de la norme du club Train-Passion!

La carte Mega supporte plusieurs ports de communication série. A priori, il serait donc possible de se coordonner avec les deux blocks voisins par ce moyen. Il s’agirait de communication point à point par deux fils qu’il faudrait programmer de cas en cas selon la configuration du réseau.

Sur le net, des solutions sont proposées basées sur le bus CAN (abréviation de Controller Area Network).

Le bus CAN est un bus système qui permet une transmission sérielle, et il est fréquemment utilisé dans l’industrie, notamment le domaine de l’automobile. Il permet de raccorder plusieurs équipements et unités de contrôle sur un seul bus ayant seulement deux lignes (CANH, CANL) sur des distances bien plus importantes que le bus I2C initialement envisagé.

Arduino et CAN: un peu de technique

Au niveau du matériel, les cartes UNO, MEGA et certaines cartes NANO sont raccordées à des modules  MCP 2515 et communiquent par l’interface SPI.

Pour la communications entre cartes arduino, il existe différentes librairies à inclure.

Grand avantage de l’utilisation de ce bus: Ce sont les modules MCP 2515 qui gèrent la communication, conflits et priorités.

Ainsi, Pour rester simple: après déclaration, la communication dans le programme du micro-contrôleur peut se résumer à: 

Les messages sont émis sans destinataires.

Chaque utilisateur doit traiter les messages qui l’intéressent. Il est également possible de définir des filtres pour traiter au niveau du module CAN les messages à faire suivre jusqu’au micro-contrôleur (à mettre en oeuvre si le trafic sur le bus devenant important freinerait le travail du micro-contrôleur!) 

Le protocole CAN transmet prioritairement les message des ID les plus petits.

Application au réseau modulaire

Compte-tenu de ces observations, les principes suivants sont retenus pour un projet de réseau modulaire.

Chaque entrée-sortie d’une gare porte un identifiant séparé, pour différencier une requête touchant l’une ou l’autre des possibilités.

Chaque block écoute ses deux gares voisines, ou plus précisément ses entrées-sorties.

Ainsi, sur l’exemple ci-dessous, le block 10 écoute les messages ayant pour entête l’ID 102 à sa gauche et 201 à sa droite.

La gare centrale écoute les messages d’état de ses blocks voisins pour vérifier les disponibilités. Lors de la configuration, il devra être précisé si le sens gauche-droite du block est entrant ou sortant pour la gare. Elle demandera une sortie sur sa gauche en libellant son message avec l’adresse 201 pour autant que le block 10 soit libre et que la gare de gauche ne soit pas saturée (mais ce sera encore validé par le block par l’adaptation de son état!). Par analogie avec le développement de block de Train-Passion, la saturation des gares sera communiquée par l’intermédiaire du block, pour éviter de devoir créer des interactions directes de gare à gare et multiplier les messages.  

Pour tenir compte des priorités du protocole CAN, les ID des blocks communiquant leur état sont plus petits et ainsi prioritaires aux messages des gares qui communiquent essentiellement des commandes basées sur l’analyse d’états des blocks.

Le block communique son état à l’initialisation, à chaque changement et à la demande:

• Libre, Réservé (demande sortie validée), Verrouillé (la composition est engagée sur le block) ou Manoeuvre (…quand ça ne se passe pas bien et qu’il faut prendre la main manuellement!)
• sens de marche (1: de gauche à droite, 0: de droite à gauche)
• saturation de la gare de gauche 
• saturation de la gare de droite
• consigne de vitesse (ce dernier paramètre est un bonus de la communication numérique, il permet d’ajuster la consigne de vitesse du régulateur de la gare en entrée)

exemple: 10, 5, V,1,0,0,50

Le block 10 informe en 5 paramètres qu’il est verrouillé de gauche à droite, qu’aucune des deux gares n’est saturée et que la consigne de vitesse est 50.

Les commandes d’entrées-sorties sont les suivantes:

• Demande de sortie: pour autant que le block soit libre et la gare voisine ne soit pas saturée. En retour le message du block indiquera qu’il est réservé sortant (après interprétation du paramètre sens du block) ce qui permet de valider un vert sortie.
• Autorisation d’entrée: (vert entrée) quand le block est verrouillé entrant. Le block réactive la traction s’il l’avait coupée ou prend note du vert entrée.
• Annulation: renonce à une sortie quand le block est réservé sortant. Le block devient libre.
• Détection: sortant, le block devient verrouillé. Entrant, la traction est coupée s’il n’y a pas eu d’autorisation d’entrée. Cette option permet d’arrêter sur le block une composition en pousse. 
• Libération: Quand le block est verrouillé entrant et que la composition est à destination. Le block devient libre.

Avantage du numérique, il est aussi possible de joindre une consigne de vitesse à une demande de sortie, de même il est possible de contrôler la vitesse du block verrouillé (et donc sous contrôle du module traction du block) avec des commandes « + », »- » plutôt que de contacter, parfois laborieusement, l’opérateur à proximité du pupitre de block! Une commande « STOP » d’arrêt d’urgence en cas de problème coupe la traction sur le block et déclenche un passage en mode Manoeuvre du block. Il devra être verrouillé sur le pupitre pour revenir en fonctionnement normal ou libéré si la composition est retirée!

Raccordement à un réseau-tiers

Les cartes développée l’année dernière ne sont pas perdues!

Solution la plus simple: Une carte interface avec un micro-contrôleur dédié convertit les signaux de block du réseau tiers en message CAN et réciproquement. Il communique avec un ID de block.

La deuxième solution est de développer une block hybride, avec prise du réseau tiers d’un côté et communication CAN de l’autre.

De gare en gare:

Après un premier test de communication avec des messages élémentaires entre deux micro-contrôleurs, il est temps de mettre en pratique les principes présentés.

Dans un premier temps, le micro-contrôleur Uno est programmé en tant que Block. Les routines déjà développées (écran OLED, interface 4 boutons, objet traction) permet de développer rapidement le logiciel.

Le micro-contrôleur Mega est programmé pour générer les messages de la gare de départ et de destination.

Dans un deuxième temps, le programme de la carte Mega est amélioré pour passer en structure objet.

La routine commande() convertit les requêtes en protocole CAN. Par simplification, les commandes sont accompagnées de la consigne de vitesse, mais elle ne sera pas toujours exploitée par le block.

La routine Analyse() convertit les messages CAN en état du Block, entrant ou sortant, et saturation distante. Particularité: la convention est prise que le sens de gauche à droite du block doit correspondre au sens entrant de la gare, autrement, il doit être corrigé en adaptant les informations reçues.

Ainsi, il y a 4 paramètres à la définition des objets blocks de la gare: son nom pour la communication interne, son identifiant CAN, l’identifiant CAN du block à écouter et l’éventuelle correction (0,si le sens G-D du block est entrant, 1 s’il faut le corriger)

Et maintenant:

Le programme de gestion de la gare à deux voies testé l’an dernier va être adapté au protocole CAN pour la gestion des entrée-sorties.

Compléments:

lien locoduino:

https://www.locoduino.org/spip.php?article130

Lien librairie

https://github.com/autowp/arduino-mcp2515

De gare en gare

Après une première saison hivernale de découverte du micro-contrôleur Arduino, une deuxième saison d’application sur un réseau test « fermé » ou entièrement maîtrisé par le micro-contrôleur, il était temps d’envisager de travailler sur un réseau ouvert interfacé avec un système conventionnel de block. Le club Train-Passion a défini une norme très précise d’interface entre les gares et les blocks de lignes. Cette norme servira de base au test… mais, pour le plaisir, le réseau conventionnel y est remplacé par un deuxième micro-contrôleur qui gérera la pleine voie et un terminus.

Le réseau test est complété par une extension avec 3 zones d’arrêt en enfilade.

Ajout du côté existant d’une carte d’interface block qui analyse les signaux du câble de liaison 15 pôles à la norme du club Train-Passion et les transmet sur le bus I2C du micro-contrôleur 2021. L’idée d’utiliser le bus I2C avec un nombre limité de raccordements aux micro-contrôleur devrait permettre de s’adapter à d’autres normes de block par simple remplacement de l’interface. Mais la faible longueur tolérée du bus pourrait remettre en cause ce choix.

Côté extension, les entrées-sorties du « demi-block » sont directement traitées par le micro-contrôleur.

A noter que dans un monde purement numérique, les modules blocks pourraient probablement être remplacés par de la communication par le port série,  mais l’objectif final est bien de tester l’interface avec le système de gestion conventionnel.

Test d’un moniteur I2C OLED

Lors de la dernière saison, un affichage LCD de 2×16 caractères complété par 4 boutons de navigation avaient été testés comme pupitre rudimentaire. Outre un graphisme limité, cet affichage et les 4 boutons de navigation mobilisaient 10 canaux du micro-contrôleur.

La nouvelle saison de tests a commencé par la prise en main d’un écran de moins de 2.5 cm de large (128×64 pixels). Intégré au bus I2C, il ne mobilise plus que les 4 canaux nécessaires aux boutons de navigation. Sa librairie permet des graphismes plus élaborés, mais attention à ne pas multiplier les fontes, car elles occupent de la mémoire sur le micro-contrôleur. Malgré sa petite taille, l’écran reste très lisible. Au niveau de la programmation, les procédures graphiques doivent être bien séparées des autres procédures d’entrées-sorties… un bien pour une programmation plus structurée!

Sur ce test, la ligne du haut présente l’état des blocks de chaque côté de la gare et le mode d’utilisation de la gare, la zone du bas présente les 4 fonctions des boutons. L’affichage est complété au centre par un indicateur de vitesse, du sens de marche de la gare et d’itinéraire. Sur la photo, le block de gauche est réservé sortant avec un feu vert de sortie. Au passage sur le détecteur, le block deviendra verrouillé. Le block de droite est libre.

L’interface block en gare

Ce module est essentiellement composé de relais pour convertir les signaux de la liaison 15 pôles (0-12V) en signaux TTL pour le micro-contrôleur. De plus, les signaux provenant du block doivent être galvaniquement séparés de la gare. Pour limiter le nombre de raccordements entre le module et le micro-contrôleur, un module d’extension MCP 23017 (testé lors des épisodes précédents) rassemble les entrées-sorties de la carte. Un module ULN 2803A amplifie les signaux de commandes.

Erreur de débutant

Lors des premiers tests de la carte interface, le block a été remplacé par des interrupteurs. Leur action entraînait irrémédiablement un blocage du micro-contrôleur… Erreur de débutant: il se produit une surtension lors de l’ouverture d’une charge inductive. Cela est le cas lorsqu’on pilote des relais. L’installation d’une diode dite de roue libre permet de protéger l’électronique de cette surtension. Ce composant est intégré au module ULN 2803A, ce qui m’avait évité tout problème lors de mes montages en 2021, mais il était à prévoir pour des relais actionnés directement par contacts ou autres interrupteurs!

La carte « demi-block »

Dans le respect de mon principe « un connecteur-une carte »… et par simplification pour le test envisagé, une carte « demi-block » est créée. Les entrées-sorties sont reprises directement sur le micro-contrôleur de l’extension 2022. Les commandes sont également amplifiées par un ULN 2803A. Comme toute la carte et les retours de la gare sont sur la même alimentation, les signaux 12V en retour de la gare sont convertis en signaux TTL par des condensateurs. Le signal mis à la masse par la gare est directement repris par le micro-contrôleur qui dispose d’une option pull-up intégrée.

Premiers tests en simulation

Le micro-contrôleur de l’extension est programmé pour gérer le block et l’extension (Pleine voie et les 3 zones d’arrêt). L’utilisation de l’écran OLED et l’adaptation des procédures graphiques du premier test permettent de disposer rapidement d’un outil de mise au point intéressant. 

Gestion automatique d’un réseau ouvert

greffe de l’interface block sur le réseau 2021 (programmation)

platine laboratoire de commande de l’extension

Le défi le plus intéressant de cette saison la mise en place d’une gestion automatique de la gare avec une extension »ouverte ». Lors de tests de 2021, le cycle automatique était essentiellement un enchainement séquentiel des étapes dont il suffisait de déterminer l’étape initiale à la reprise du cycle.

Comme l’opérateur d’une gare en réseau ouvert, le micro contrôleur doit gérer 3 éléments.

• Entrées

• Sorties

• Communiquer sa saturation aux gares voisines pour conserver des options de sorties. C’est souvent ce qui est oublié par les opérateurs et conduit à des situations…compliquées!

Saturation de la gare

L’analyse des blocks verrouillés entrants et de l’état d’occupation des voies définit la saturation de la gare. Elle pourrait être affinée en ne la définissant que vers une des deux gares adjacentes.

Si les deux voies sont ou vont être occupées dans le même sens, il ne faut pas admettre de convoi du côté opposé. (Situation 1,2 et 3).

Les situations 2 et 3 sont en fait des anticipations de la situation 1.

Le côté gauche du réseau test (ouest) peut poser problème. Saturée avec une seule composition, elle doit de toute manière envoyer un train vers la gare… et la gare devra forcément le faire suivre à l’Est, cela revient à anticiper d’un niveau supplémentaire.

Cette analyse impose de mémoriser le sens d’arrivée sur les voies.

Recherche des mouvements possibles

En phase de repos (itinéraire libre ou voie=0), le micro-contrôleur analyse les entrées possibles en fonction des annonces de blocks (signal Entrée possible) et des occupations des deux voies. La voie 2 est occupée en priorité.

Pour les sorties, La priorité entre les voies 2 ou 3 est définie selon « l’heure de départ » définie à l’arrivée des convois. Puis l’itinéraire dépend du sens souhaité (maintien du sens de réception) et de l’état du block correspondant.

Dans les deux cas, la recherche aboutit à une proposition d’itinéraire et de sens de marche appelant les routines existantes pour le mode Exploitation. Ces dernières peuvent encore annuler les opérations si les conditions ont changer pendant l’établissement de l’itinéraire.

Dans un premier temps, les platines de blocks, et le code ont été testés en simulation avant de passer sur les rails.

Gestion de compositions en pousse

Bien souvent, la gestion des entrées en gare passe par un tronçon de voie isolé, non alimenté tant que le signal d’entrée ne passe pas au vert, sur lequel s’immobilise la locomotive privée d’énergie. Cette solution n’est pas satisfaisante avec des compositions en pousse qui une fois ou l’autre se retrouveront voiture-pilote en tête.

La norme de block du club Train-Passion comprend depuis peu la communication au block de l’état du signal d’entrée ce qui permet de couper la traction en pleine voie.

Pour ce faire, il convient de détecter correctement l’entrée d’une composition. Pour ne pas multiplier les aimants sous les compositions, le club Train-Passion a choisi un système de barrière optique. Pour ma part, j’ai choisi de tester la détection de présence sur le tronçon à l’aide d’un montage de diodes et optocoupleur.

Les locomotives et voitures-pilotes d’ancienne génération (Arst 151-152) sont détectées dès l’entrée du premier bogie. La prise de courant de ma dernière acquisition (Ast 117) est plus problématique. La prise de courant est répartie sur les deux bogies, ce qui évite par ailleurs des éventuels courts-circuits lors de passages entre modules de traction mal gérés, et l’éclairage à LED nécessite un minimum de tension sur le tronçon de détection pour en dépasser le seuil de conduction. En théorie, la détection n’est possible que quand le deuxième bogie entre sur le tronçon isolé… cela na pas toujours été le cas lors du test.

Cette adaptation permet également d’arrêter une double traction sans patinage de la deuxième machine.

Un intérêt pour le modélisme ferroviaire et l’informatique m’ont poussé à découvrir le pilotage de réseau à l’aide d’un micro-contrôleur arduino. Cette approche devrait permettre de remplacer la laborieuse logique câblée par relais et contacts divers par du logiciel pouvant évoluer ainsi que la création d’un synoptique informatique plutôt qu’un pupitre figé.

Voici un lien vers un site mariant modélisme et arduino: https://www.locoduino.org

Les premiers pas

Le fournisseur propose un  kit de démarrage bien documenté avec une carte Arduino Uno et divers composants qui m’a bien occupé ce printemps au premier « confinement ». La carte dispose de 14 entrées/sorties numériques, 6 entrées analogiques et d’un espace mémoire de 32 kB pour le programme. Le programme est préparé sur MAC ou PC et transmis à la carte par le port USB. Le langage de programmation IDE est un mélange de C et C++. Les exemples fournis permettent de progresser rapidement. 

De ces exemples, un premier exercice ferroviaire est entrepris, la définition de position d’aiguilles (LEDs) à partir d’actions sur les boutons. Cela ne remplace qu’une carte à diodes…mais ouvre la porte à un contrôle depuis un PC

C’est également l’occasion d’exercer la programmation objet. Une approche qui permet de structurer des opérations répétitives et gérer nominativement des données. 

• Chaque aiguille doit avoir un port attribué sur la carte arduino ou une extension
• La position doit pouvoir être connue et la consigne attribuée
• Chaque aiguille doit être configurée (configuration du port et position initiale) à la mise sous tension (Setup)
• La position de chaque aiguille doit être adaptée selon l’itinéraire choisi. De plus pour éviter les surcharges, les aiguilles sont manoeuvrées avec un délai entre elles (T_action)
• A terme, la position des aiguilles devra être validée par les fins de courses

Chaque classe d’objets contient des données privées (utilisables par la classe seulement) ou publiques (utilisables par tout le programme) et des routines spécifiques.

 Pour ce qui est de la commande d’un moteur, j’opte directement pour le module  MotoDriver2 proposé par Conrad. Il permet le contrôle de deux moteurs. Chaque moteur est commandé par 2 ports analogiques de la carte (un par sens de marche… attention lors de la programmation)

La routine principale de la classe traction adapte la vitesse avec rampes d’accélération ou de freinage de l’objet en fonction de la consigne et d’une éventuelle urgence (sans rampe!), actionne les ports de la carte arduino et communique au PC les changements par le port série.

Prise en charge d’un block

Une des finalités du développement sera de traiter les signaux provenant de blocks voisins de clubs avec leurs spécificités de câblage.

• Etats des blocks à afficher pour les prises de décisions de l’opérateur. 
• Envoi des quittances (entrée/sortie du block) et des demandes.

L’isolement restant de mise, une nouvelle simulation est lancée selon l’illustration ci-dessous. Le micro-contrôleur analyse la platine transformée en block sur un ovale reliant les extrémités de la gare (faute de réseau, des boutons simulant les cellules sont ajoutés aux extrémités). Il se comporte également comme traitant à chaque extrémité de la gare les informations du block… de quoi lui infliger des troubles de la personnalité! Ce test a aussi pour objectif de progresser dans la communication entre le micro-contrôleur et le PC sur lequel tourne un programme de synoptique développé sur Processing.

En résumé: un block peut être libre, réservé ou verrouillé. Quand les états sont verrouillés et réservés, les signaux sont complétés (plus ou moins clairement selon les spécificités du câblage entre gare et block voisin!) par un sens de marche… qui se transforme en entrant ou sortant selon l’extrémité de la gare.

Dans l’illustration, l’opérateur a créé un itinéraire de 2 à gauche, le vert sortie a déclenché la réservation sortante du block. Le block sur la platine est réservé de gauche à droite, et à droite de la gare s’affiche un block réservé entrant. Le passage du convoi sur la cellule verrouillera le block. Mais cette étape pourrait être dictée par un autre critère du micro-contrôleur et transformé en signal correspondant au passage sur la cellule dans l’interface avec le block.

Puis l’été est arrivé!

Une étape plus concrète:

Avec le retour de l’hiver et d’une nouvelle limitation des contacts, de nouveaux objectifs plus concrets sont posés pour la découverte de ce micro-contrôleur: Le pilotage automatique d’une gare de croisement. Cela pourrait être les voies 2 et 3 de la gare de Saanen en cours de construction (plan de voies début des années 2000).

Au niveau matériel, le réseau est constitué de voies tillig, un système qui me semble idéal pour un réseau temporaire de test et qui me rappelle le premier montage « provisoire » en voie C sur la table de la salle à manger familiale! De plus, les éclisses isolantes noires permettent de bien identifier les secteurs. L’absence de stock d’éclisses de raccordement me permet de m’exercer à la soudure sur rail et de bien visualiser les raccordements!!!

En bas, à gauche, en jaune, le kit de démarrage. Sa platine laboratoire sert dans ce test à contrôler le démarrage de la locomotive active (GO, STOP) puis à régler sa vitesse de consigne (+ et -)…tel le passage de touches qui ne me fait pas regretter l’installation d’un potentiomètre. Ce qui n’aurait pas de sens, la demande de puissance des locomotives pouvant être très différentes en réseau ouvert, oublier le potentiomètre en position élevée quand une locomotive moins gourmande arrive peut mener à une catastrophe. Je préfère choisir une vitesse de base avec possibilité de correction!

En bas à droite, le module de traction (la pile et le moteur ne sont plus utilisés, restes des tests du module de traction). Alimenté en 12V, il fournit également du 5V à une partie des composants. A terme, il permet de commander deux moteurs… ou deux itinéraires pour rester dans le monde ferroviaire.

En haut à gauche, les modules de détection d’occupation des voies, car dans tout automatisme, il faut mesurer pour réagir. Ces modules permettent de se passer d’aimants sous les machines déclenchant des contacts Reed sur le réseau ou de capteurs optiques à cacher.

En haut à droite, un module de 8 relais. Pour ce test, j’y commande les deux aiguilles et l’alimentation des 4 segments de voies (les deux voies de croisement et les deux voies d’accès). Les sorties de la carte ou d’un module a donnent directement les ordres aux relais via une séparation galvanique. ATTENTION: L’alimentation de la carte Arduino ne suffit pas pour alimenter l’étage de puissance des relais.

Au milieu, deux modules d’extension MCP 23017 qui permettent en théorie de gérer 16 entrées-sorties chacun (On pourrait aller jusqu’à 8 modules). En plus de l’augmentation du nombre d’entrées/sorties, l’intérêt de ces modules et de limiter la concentration du câblage autour de la carte. car ils ne sont reliés à cette dernière que par deux fils de communication, une masse commune et, si l’alimentation le permet, une seule alimentation.

Le composant dispose de 28 broches. Les broches 1 à 8 et 21 à 28 sont les entrées/sorties configurables.

Le composant est équipé de résistances internes Pull-Up de 100kOhms activables à la configuration de qui permet de câbler simplement les entrées.

Les autres branchements indispensables sont: 

# 12 sur la broche Analog 5 de la carte arduino

#13 sur la broche Analog 4 de la carte arduino

Ces deux branchements servent à la communication selon I2C

#9 au +5V local

#10 à la masse commune

#18 au +5V local

# 15, 16 et 17 servent à définir l’adresse du module (de 0 à 7)

Expérience faite, je recommande de brancher une LED de contrôle avec une résistance en série sur une des sorties et de la faire clignoter dans le programme pour contrôler le fonctionnement du module. Si elle ne clignote pas, le module est en carafe. Dans mon cas, cela générait des erreurs de détection incompréhensibles. Si j’avais installé cette LED dès le début, je me serais posé moins de questions! Cela était dû à une alimentation insuffisante ou instable.

Le programme:

Le processus suivant est retenu: Le premier train vient de l’ouest et rentre en voie 2, le plus proche du bâtiment. Chaque étape définit un itinéraire (positions aiguilles et tronçons alimentés) et un sens de marche. L’étape 4 ramène à la situation 1.

Pour la programmation, deux nouvelles classes d’objets sont créées.

Les capteurs:

Chaque capteur se voit attribuer un port de lecture et mémorise un état. Sa routine importante est la mise à jour de l’état. Si l’état passe à 1, un délai est pris en compte pour admettre un passage à 0 pour éviter des parasites. Un changement d’état peut être transmis au PC si nécessaire (en l’état, passé en commentaire pour ne pas surcharger le port série)

Attention: la mesure est valide pour autant que de la tension soit présente sur le tronçon de voie. En amont de l’appel à la mise à jour de l’état, il faudra s’en assurer. 

En programmation objet, il y a des notions d’héritage… mais je ne me suis pas lancé!

Les segments:

Chaque segment se voit attribuer un port d’écriture (action du relais), mémorise un état (alimenté ou non), une occupation, et mémorise la consigne de vitesse de la locomotive l’occupant (bonus d’un réseau fermé). Il est ainsi possible de recharger la vitesse de consigne de base pour son redémarrage.

Une routine importante est le calcul de la vitesse de consigne en fonction des capteurs lui ordonnant une réduction de vitesse ou l’arrêt. Cette routine met également à jour la variable globale Adestination pour la suite du cycle.

Dans le programme principal (loop), la gestion des mouvements se résume à appeler cette routine avec les bons capteurs:

Par exemple, pour la voie 2 de droite à gauche en provenance de l’est (indiquant que la voie 2 est une destination), le capteur de réduction est le 22, celui d’arrêt le 21 et inversement de gauche à droite depuis le secteur Ouest: Le capteur de réduction de vitesse est le 21, celui pour l’arrêt est le 22.

Le comportement à destination, ainsi que la détermination de la phase initiale à la mise sous tension de la carte, aurait pu se résumer à une démarche du genre ci-dessous, mais du code complémentaire a été ajouté pour contrôler que la prochaine destination est bien « indiquée comme libre » suite à des défauts du module MCP mesurant les détections. Je vous en épargne!

A noter que dans la phase initiale, il suffit de donner un minimum de tension (sans mettre en mouvements les locomotives) sur tous les segments pour que la détection fonctionne normalement pour déterminer les occupations de voies.

Mise en garde: je me suis servi à plusieurs reprises de la commande delay(x) ou x est un temps d’attente en millisecondes, pour espacer l’action sur les relais par exemple alors que les convois sont arrêtés. Cette commande interrompt le programme pendant cette durée. Elle est à proscrire en réseau ouvert où d’autres événements peuvent être à détecter, sur les blocks par exemple.

Et maintenant?

Ce test reste très théorique, il me permet de dégourdir les bogies de matériel resté longtemps à l’arrêt!… et d’en tirer quelques enseignements.

Le choix de la détection par les voies et la mise sous tension de l’itinéraire complet permet des doubles-tractions sans patinage de la deuxième machine et d’arrêter correctement une voiture-pilote éclairée en pousse.

Attention à prévoir des outils de dépannage dans les montages (LEDs de contrôle par exemple)

Attention aux alimentations. La capacité de la carte est limitée.

Dans un réseau ouvert, il faudra tenir compte de l’état des blocks voisins pour déterminer les étapes du cycle.

Dans l’intervalle, je vais travailler sur l’interface avec le PC développé sur Processing pour des commandes plus « manuelles ».