Le projet LaBox ne cesse d’évoluer. Depuis la version 2.0.0 qui constituait le point de départ de la version dérivée de CommandStation-EX, le successeur de DCC-EX, puis la 2.4.x qui a enfin permis le reconnaissance de l’adresse de la loco via la lecture du CV 1, le projet a suscité beaucoup d’engouement et de participation des membres du forum, en témoignent les 36 pages du projet. Voyons sous quelle forme Railcom, les menus, la programmation, les interfaces simplifiées vers le monde extérieur et d’autres améliorations encore sont apparues.
LaBox, la centrale DCC de Locoduino
LaBox, Une Centrale DCC polyvalente et abordable (4)
La suite du retour de la vengeance...
.
Par :
DIFFICULTÉ :★★★
Quelques pépites sont venues grossir le code et, outre les corrections toujours de rigueur dans un projet de développement, des changements architecturaux ont aussi permis de s’ouvrir sur l’avenir. A noter que le fichier version_labox.h présent dans le répertoire de développement décrit les modifications apportées version par version depuis la 2.4.0 . Le fichier d’origine version.h venant de CommandStation-EX est toujours là et témoigne de la version utilisée. La version courante 2.10.0 de LaBox est bâtie sur la version 5.4.10 de CommandStation-EX.
Railcom
Copyright Lenz
Le premier gros changement était attendu depuis longtemps par la communauté, en tout cas sur Locoduino. Du côté du code de base, CommandStation-EX ne semblait pas très pressé d’y arriver, sans doute aussi parce que leur produit est censé tourner sur plusieurs plateformes, là où notre adaptation LaBox est dédiée à l’ESP32...
Depuis un certain temps, Christophe faisait la promotion du Railcom et poussait, avec raison, pour son adoption par LaBox (Détection RailCom© avec ESP32 (ou Arduino)). Marc (dit ’Lebelge2’ sur le forum), récent arrivé, a relevé le défi et a fourni une première version fonctionnelle utilisant les particularités de l’implémentation DCC de CommandStation-EX sur ESP32 ([https://forum.locoduino.org/index.p...]). En effet, la génération des trames DCC utilise sur l’ESP32 un dispositif matériel fourni par la puce et appelé RMT. C’est à la base un générateur de signal censé être utilisé pour faire du son ou des modulations infrarouges de télécommande... En contournant un peu le fonctionnement, le code original de CommandStation-EX pour l’ESP32 génère des trames DCC très propres (notre sniffer en témoigne). Marc a greffé par dessus un Cutout, c’est à dire une interruption de cette trame pendant un temps déterminé, et à un moment déterminé, permettant à un décodeur de locomotive d’émettre une série de signaux qu’un détecteur Railcom comme celui de Christophe peut analyser.
Un cutout au milieu d’un signal DCC. Le décodeur de la loco en profite pour causer !
Source https://usuaris.tinet.cat/
Cette nouvelle fonctionnalité ne change rien au fonctionnement du DCC, même si personne ne profite de ces Cutouts, mais elle est débrayable dans config.h .
EXComm
En parlant de changement architectural, je pensais à lui... Jusqu’à présent, ajouter une nouvelle interface ou un nouveau comportement imposait de modifier le fichier de base CommansStation-EX.LaBox.ino afin d’y insérer au moins une ligne dans le setup : NouvelleInterface::begin(); et un autre dans le loop : NouvelleInterface::loop();’ et je trouvais cela plutôt envahissant. L’autre but était de polluer le moins possible le code original de CommandStation-EX (CSEX pour les intimes) afin de faciliter l’intégration de leur corrections et nouveautés qui passe souvent par de simples comparaisons de fichiers source... Enfin l’isolation du code d’une interface à ses seuls fichiers sources est une meilleure garantie de maintenabilité, a priori sans risque pour le reste du code.
Je me suis donc inspiré de la classe TrackManager de CSEX pour créer une classe conteneur des différentes interfaces. Chacune d’entre elle devant fournir un constructeur avec en argument les éléments matériels de leur configuration : broches, vitesses, identifiant, etc... Un begin marquant le début officiel du fonctionnement de l’interface doit aussi être fourni, ainsi qu’un loop.
L’intervention de EXComm dans le .ino se résume donc à EXComm:begin(); dans le setup qui lance les begin de toutes les interfaces présentes, et un EXComm::loop(); dans le loop pour le fonctionnement. Si demain une nouvelle interface devait surgir, comme S88 ou Loconet (soyons fous), nul besoin de modifier le noyau, il suffit de bien la déclarer dans le config.h et le tour est joué.
A ce sujet, une modification importante du config.h a été nécessaire pour autoriser tout ça :
// Enable Railcom Cutout frame during DCC signal generation. ONLY FOR ESP32 !
#define ENABLE_RAILCOM
#if not defined(ARDUINO_ARCH_ESP32) && defined(ENABLE_RAILCOM)
#undef ENABLE_RAILCOM
#endif
// Use EXComm items to get orders
#define ENABLE_EXCOMM
#ifdef ENABLE_EXCOMM
// Use EXComm CAN bus using Marklin protocol
#define ENABLE_CANMARKLIN
#ifdef ENABLE_CANMARKLIN
#define CANMARKLINCOMM new CanMarklin(253, GPIO_NUM_4, GPIO_NUM_5, 250UL * 1000UL, false)
#else
#define CANMARKLINCOMM NULL
#endif
// Use EXComm Z21 Throttle via Wifi UDP.
#define ENABLE_Z21
#ifdef ENABLE_Z21
#define Z21COMM new Z21EXCommItem(Z21_UDPPORT)
#else
#define Z21COMM NULL
#endif
// Use EXComm SProg protocol via Serial2 in prog mode only
#define ENABLE_SPROG
#ifdef ENABLE_SPROG
#define SPROGCOMM new SProg(16, 17)
#else
#define SPROGCOMM NULL
#endif
// Use EXComm XPressNet protocol via Serial2
#define ENABLE_XPRESSNET
#ifdef ENABLE_XPRESSNET
#define XPRESSNETCOMM new XPressNet(12, 13, 15)
#else
#define XPRESSNETCOMM NULL
#endif
#define LABOX_EXCOMMS \
Z21COMM, \
CANMARKLINCOMM, \
SPROGCOMM, \
XPRESSNETCOMM
#endifAprès la nouvelle activation de Railcom qui peut être retirée avec un // devant la ligne ENABLE_RAILCOM, se trouve le bloc EXComm.
D’abord il est possible de retirer d’un coup tout EXCOMM en désactivant ENABLE_EXCOMM. Le comportement revient alors à celui d’un simple LaBox version 2.0.0 .
A l’intérieur de EXCOMM, se trouve quatre sections qui décrivent quatre interfaces possibles. Chacune d’entre elle peut être désactivée par son ENABLE comme ENABLE_CANMARKLIN par exemple. Si ENABLE_CANMARKLIN est activé, alors CANMARKLINCOMM est définie comme le constructeur de la classe d’interface, avec en argument les broches, la vitesse de transmission et l’identifiant utilisé. S’il n’est pas défini, alors CANMARKLINCOMM est défini comme NULL.
Les quatre interfaces sont ainsi activées ou pas, et le résultat est la déclaration de LABOX_EXCOMMS qui fabrique une liste des interfaces avec soit NULL, soit un appel de constructeur.
Le regroupement de toutes ces interfaces sous une même classe a permis de factoriser le comportement dit ’Broadcast’ que CommandStation-EX réservait seulement à ses propres interfaces WiThrottle et liaison série. Une fois qu’une appli a fait quelque chose sur une loco ou un aiguillage, CommandStation-EX envoie à toutes les autres applis l’état de ce qui a changé. Ainsi tout le monde sait ce qu’il se passe à tout moment. EXComm a permis de propager ça à tout ce qui est connecté et qui est intéressé par ces informations. Ainsi les applis Z21 ou SPROG connectées reçoivent maintenant les changements, ce qui n’était pas le cas. De même en commandant LaBox via le bus Can, on voit évoluer l’écran Oled, le numéro, la vitesse, direction et fonctions des locos commandées via Can.
Pour info, dans le répertoire Release_Notes se trouve toute la documentation liée à ces quatre interfaces et quelques autres comme Railcom ou Loconet qui ont été glanées -légalement- sur le net.
Z21
Application Z21 iOs/Android
Copyright Fleischmann/Roco
L’interface vers les applications Z21 était déjà fournie par LaBox avant EXComm, mais j’ai choisi de l’intégrer dedans pour plus de simplicité... Au niveau comportement, quelques modifications sont intervenues pour gérer enfin les aiguillages, et permettre de renvoyer l’état des locos gérées par l’application aux autres applis. Enfin la partie POM (Program Over Main) qui permet théoriquement de programmer les décodeurs sur la voie principale, mais sans retour d’information a également été implémentée, mais pas testée.
CAN MARKLIN
Le CAN est un bus qui a la cote chez nous, et particulièrement chez Christophe (encore lui !) qui a développé une interface pour piloter les centrales MS2 et CS2/3 de MARKLIN (Commander sa centrale Marklin® MS2 en WiFi à partir de Rocrail®, JMRI®, iTrain® ou autres gestionnaires.). Le CAN est un support matériel, et permet de faire transiter des octets sur un bus, mais la nature et le format des données transportées dépend du programme qui exploite ce bus. Les données qui transitent sur un bus CAN d’Airbus ou de voiture n’ont évidemment pas le même contenu que pour un train électrique ! Donc ici, c’est le protocole ouvert de Marklin qui a été implémenté, mais d’autres pourraient apparaître pour d’autres usages comme nos cartes satellites...
XPressNet
Marc a continué sur sa lancée après le succès de Railcom dans LaBox. Il a repris et adapté une interface XPressNet (https://forum.locoduino.org/index.p...). Je n’ai pas pu tester faute de matériel compatible mais il assure que ça marche, et je lui fais confiance ! A noter que XPressNet utilise l’interface série Serial2. Tout autre utilisation de Serial2 est donc à proscrire si XPressNet est activé.
SPROG
J’ai implémenté là le protocole utilisé par les petites centrales de programmation SPROG bien connues. Ce protocole est dans leur documentation et assez facile à implémenter. J’ai pu le tester avec le programme Windows Centre DCC via USB et un petit adaptateur UART/USB. Par contre JMRI est censé pouvoir travailler avec ce protocole SPROG, et je ne suis arrivé à rien. La faute sans doute à ma grande méconnaissance de JMRI. SPROG utilise Serial1, avec donc la même limitation d’utilisation de cette liaison série que XPressNet.
Commandes
Un nettoyage du menu a eu lieu pour retirer les commandes qui ne faisaient rien, comme l’activation/désactivation WiFi ou CAN... Cinq nouvelles commandes sont apparues au menu de LaBox.
Lecture et Ecriture CV
LaBox ne dispose que d’une seule sortie DCC. Cette sortie est évidemment dédiée au pilotage des machines sur une voie dite ’principale’. Afin malgré tout de pouvoir lire et écrire des variables de configuration (CV en anglais) situées dans le décodeur des engins moteur, un mode ’programmation’ a été mis en place. Pour atteindre ce mode, je n’ai trouvé qu’une seule solution : redémarrer l’ESP32 avec une configuration n’ayant que la voie de programmation. Dans ce mode, outre les commandes fournies par LaBox via son menu, les applications comme Z21, WiThrottle/EngineDriver ou son extension EX-ToolBox, JMRI et sans doute beaucoup d’autres peuvent aussi lire et écrire des CVs. Une fois le besoin de programmation rempli, le fait de quitter la commande initiée au début va redémarrer silencieusement l’ESP pour repasser en mode pilotage.
Dans config.h, les deux configurations utilisées sont
#define LABOX_MAIN_MOTOR_SHIELD F("LABOXMAIN"), \
new MotorDriver(LABOX_MAIN_PINS, 0.80, 2500, UNUSED_PIN) /* MAIN ONLY */
#define LABOX_PROG_MOTOR_SHIELD F("LABOXPROG"), \
NULL, \
new MotorDriver(LABOX_MAIN_PINS, 0.80, 2500, UNUSED_PIN) /* PROG ONLY */Si une configuration différente comme
#define LABOX_MAIN_PROG_MOTOR_SHIELD F("LABOXMAINPROG"), \
new MotorDriver(LABOX_EXT1_PINS, 0.80, 2500, UNUSED_PIN), /* MAIN */ \
new MotorDriver(LABOX_MAIN_PINS, 0.80, 2500, UNUSED_PIN) /* PROG */ avec à la fois une voie principale et une voie de programmation déclarées en utilisant le port d’extension (les broches inutilisées à gauche de l’ESP32) alors le redémarrage ne se justifie plus et disparait.
Identification du décodeur
Autre commande, l’identification du décodeur de la loco sur la voie. Via la lecture des CV7 et 8, la marque du décodeur et son pays d’origine sont affichés, ainsi que la version du décodeur. Cette version est une donnée gérée par les fabricants, et sa signification dépend évidemment de la marque. D’autant que certaines utilisent d’autres CV (65, 100 et plus) pour y stocker le même genre d’information... Difficile donc d’identifier précisément le modèle de décodeur, mais la marque est déjà une bonne info. JMRI est de ce point de vue plus précis.
DCC On/Off
Il est maintenant possible au menu de mettre le courant sur les rails ou de le couper via la commande. L’affichage revient maintenant sur l’écran de démarrage si le courant est coupé.
Va et Vient EXRail
Dernière commande ajoutée : le Va&Vient EX-Rail. Pour ceux qui ne connaissent pas CommandStatrion-EX, EX-Rail est un moyen via des macros de fabriquer des automatismes DCC. Ainsi, faire un va et vient entre deux capteurs est l’un des exemples fournis par le Github de CSEX via les sources myAutomation.example.h et myEX-turntable.example.h . J’ai simplifié l’exemple de va et vient pour le conditionner à un délai plutôt que sur des capteurs, ce qui permet de simplement tester le fonctionnement d’un engin moteur dont on donne l’adresse DCC sur le petit écran... Attention, j’y ai laissé les appels de fonctions sonores présents dans l’exemple d’origine, ça peut être assez bruyant ! Cette commande est d’abord une preuve de concept de ce que peut faire EX-Rail, et permet de tester le fonctionnement du DCC... Vous noterez que le lancement et l’arrêt par code d’une séquence EXRail n’est pas possible dans CSEX. J’ai dû adapter le code d’origine pour pouvoir le faire.
Config.h
Deux nouvelles options sont apparues :
HMI_DASHBOARD_TRAIN_NB
Ce define permet de fixer le nombre de locos affichées par défaut dans le mode pilotage. Le menu offre effectivement le moyen de voir une, deux ou trois locos sur le petit écran, mais cette configuration n’est pas conservée si l’on éteint LaBox. Sur mon réseau T-Trak, deux voies seulement sont disponibles, et deux matériels moteurs seulement circulent simultanément, je voulais donc pouvoir être en vue deux locos dès le démarrage. A noter que cette vue a été corrigée, elle était décalée... De plus l’affectation d’une nouvelle loco pilotée à l’un des affichages a été revu pour être plus logique.
HMI_SCREEN_ROTATION
Prévu pour fixer l’orientation du petit écran OLED. L’utilisation d’un boitier fait maison peut conduire à monter l’écran différemment de son connecteur originel sur le PCB LaBox. Attention malgré tout à rester en orientation 2 (180°), celui d’origine, ou 0 (0°) pour retourner l’écran. Les orientations 1 et 3 (90° et 270°) obligeraient à revoir le code du HMI pour modifier toutes les coordonnées de tracé, l’affichage passant de 128/64 à 64/128 !
Comment se servir de tout ça ?
Comme d’habitude, le logiciel est disponible sur notre Github. Une fois les sources récupérés, vous devrez copier config_Labox.h dans config.h et y apporter vos modifications, comme les identifiants Wifi par exemple. Et si vous aviez déjà les sources, faites attention de bien prendre config_Labox.h comme base, d’y reporter les modifications de votre ancien config.h, puis d’en faire votre nouveau config.h .
Le projet a été compilé et testé sur Arduino IDE 2.3.6, Arduino IDE 1.8.19 et Visual Code 1.99.3 avec PlatformIO IDE for VSCode 3.3.4 sous Windows et Linux (merci Github).
Il faut cependant respecter deux règles :
- Le framework ESP32, qu’il soit fourni par Arduino ou Expressif, doit rester en version 2.0.xx . La plus récente version 3.x.xx n’est pas compatible avec CommandStation-EX qui constitue la base de LaBox.
- La bibliothèque ACAN_ESP32 doit rester en version 1.1.2 . Les versions suivantes ayant besoin du framework ESP32 3.x.xx !
Prochain article à venir, le matériel a lui aussi évolué !