La commande par micro-contrôleur

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 ».