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