Ceci dit, vous pouvez toujours utiliser des Arduinos pour faire:
- des passages à niveau,
- des postes à souder,
- des affichages en gare,
- . . .
- voir Appli sur LOCODUINO
C’est pas mal pour débuter
@Al1rc30 al1rc30
Alain,
Le monde du 3R a portant beaucoup à apprendre du 2R comme le 2R a à apprendre du 3R. Je suis par exemple un des fervents promoteurs du bus CAN (spécifique à Marklin) dans le domaine du 2R (Rétro-signalisation, commandes de locos etc…).
Par ailleurs, je comprends et je respecte les choix de chacun. Celui en particulier de ne pas vouloir s’em****r avec la technique. J’attends juste que ce soit réciproque.
Tu es motard je crois comme je le suis aussi. J’ai passé ma jeunesse les mains dans le cambouis à trafiquer des moteurs. Aujourd’hui j’en ai plus envie, cela ne m’intéresse plus alors j’ai acheté une moto allemande sur laquelle tout est parfait… et j’ai aussi acheté une voiture allemande pour la même raison ! Mon plaisir maintenant c’est de rouler sans me soucier de la mécanique. C’est dire si je comprends.
Pour ceux qui auraient oublié ou qui ne le connaissent pas, voici le sketch de Fernand Raynaud : https://www.youtube.com/watch?v=GlcooNBZi38&ab_channel=Àgauche
1 « J'aime »
Le bus de données CAN (Controller Area Network) est un bus système série très répandu dans beaucoup d’industries, notamment l’automobile.
Il a été normalisé avec la norme ISO 11898.
Il met en application une approche connue sous le nom de multiplexage, et qui consiste à raccorder à un même câble un bus un grand nombre de calculateurs qui communiqueront donc à tour de rôle.
Cette technique élimine le besoin de câbler des lignes dédiées pour chaque information à faire transiter (connexion point-à-point).
Dès qu’un système (voiture, avion, bateau, réseau téléphonique, etc.) atteint un certain niveau de complexité, l’approche point-à-point devient impossible du fait de l’immense quantité de câblage à installer et de son coût (en masse, matériaux, main d’œuvre, maintenance).
Merci beaucoup pour toutes ces informations.
Il y a cependant un point que tu ne mentionnes (ou que je ne comprends pas bien), c’est la présence de la MS2 dans mon motage avec le PC, Arduino et RR.
Je pensais, sans doute à tord, que dans cette configuration la partie Arduino ne servait que à faire le pont (traduction de protocole) entre RR/PC et la MS2/Gleisbox. Et que donc, pas besoin de programmation. Je pourrais utiliser RR exactement comme si j’avais une CS3. Avec les limitations due à la MS2.
Ai-je mal compris ?
Merci,
Olivier
Dans l’arduino, il y a quand même de la programmation:
Une librairie CAN à installer
La lecture des entrées/sorties et l’envoi sur le CAN
La lecture / écriture du bus S88
La structure (voir LOCODUINO) est: LOCODUINO - Une Passerelle entre le bus S88 et le bus CAN pour la rétro signalisation
//Gateway 1
#include “CAN_S88_Gateway.h”
void setup() {Setup(1);}
void loop() {Loop();}
//Detector1:2 (capteurs 2:1 à 2:15, Detector 1:1 non utilisé)
#include “CAN_S88_Detector.h”
void setup() {Setup(1,2);}
void loop() { Loop();}
//Gateway 2
#include “CAN_S88_Gateway.h”
void setup() {Setup(2);}
void loop() {Loop();}
//Detector2:1 (capteurs 5:1 à 5:15)
#include “CAN_S88_Detector.h”
void setup() {Setup(2,1);}
void loop() { Loop();}
//Gateway 3
#include “CAN_S88_Gateway.h”
void setup() {Setup(3);}
void loop() {Loop();}
Detector3:1 (capteurs 9:1 à 9:15)
#include “CAN_S88_Detector.h”
void setup() {Setup(3,1);}
void loop() { Loop();}
Oui effectivement tu as un peu mal compris. Relis bien mes posts :
qui présente CC-Schnitte utilisé avec un PC et Rocrail par USB. Dans ce cas, nul besoin d’Arduino ni de programmation.
Si j’ai laissé la CS2, c’est juste pour montrer que l’on peut avoir aussi d’autres centrales sur le bus CAN en plus du PC avec Rocrail.
Puis :
qui présente un montage avec Arduino+Shield CAN. Pas de MS2 ni CC-Schnitte ici. Il faut bien sûr un programme dans l’Arduino qui est relié à Rocrail du PC par un cordon USB.
L’Arduino et son programme jouent le rôle de CC-Schnitte et permettent donc de s’en dispenser. Par contre, le programme en l’état ne permet que la commande des locos mais pas la rétro signalisation S88.
L’ESP32 que l’on peut voir sur la photo sert de sniffer sur le bus CAN pour visualiser les messages échangés. Il n’est pas nécessaire en utilisation normale.
Ce que je te conseille et qui répond bien à ta demande initiale « piloter pour tester des locomotives » c’est la seconde solution, qui est bridée (S88) mais qui n’est effectivement pas trop onéreuse. Ca fonctionne, ma vidéo le montre bien.
Ensuite, si tu te sens à l’aise avec Rocrail, tu peux envisager de faire l’acquisition de CC-Schnitte + StartPunkt (pour le S88). Tu disposeras alors d’un système très complet pour le pilotage des locos et la rétro signalisation.
Bien cordialement
Christophe
Benoit,
C’est pour cette raison de complexité que je ne conseille pas de faire de l’Arduino avec le S88.
Par ailleurs, je connais bien l’article de Jean-Pierre CLAUDE que tu évoques. Il parle de quelque chose de bien spécifique : Les perturbations du bus S88 sur des longueurs assez importantes, et ce, avant que les bus S88 ne soient en Ethernet RJ45.
Jean-Pierre proposait une solution pour que les grandes longueurs soient reliées en CAN, d’où la multiplicité de gateways. Ce sont juste des passerelles mais pas des dispositifs de retro signalisation.
Bien cordialement
Christophe
Hello
À vous lire je réalise ce qui me déplaît ( c’est trop fort comme mot mais je n’en trouve pas d’autre ) dans l’évolution actuelle d’un peu tout
C’est que l’informatique s’invite partout et si elle apporte sans aucun doute des améliorations. Elle amène avec elle un paquet de problèmes qui font qu’on passe un paquet de temps derrière son écran d’ordinateur alors qu’on veut jouer au petit train
Et cette remarque est aussi valable pour Märklin
Je ne pense pas que c’est un “combat” 2 ou 3 rails
C’est juste effectivement une différence d’approche de notre hobby
Il y en a qui aiment la possibilité de concevoir du hard et du soft d’autres qui aiment comme les vaches voir passer des trains dans un beau décor 
Pour l’ironie je n’en ai vraiment pas vu , en tout cas pas de mon côté , de l’humour oui 
Bon courage avec le pont tournant je suis impressionné par le boulot et la qualité du résultat !
Merci Francis, ceux auxquels je fais allusion se reconnaîtront.
Pour le pont, un projet en commun avec Olivier, je suis un peu en standby car j’ai des boulots à finir, mais je suis presque à la fin. Reste principalement à coller les rails et un encodeur que j’ai ajouté.
Bonjour à tous,
J’ai retrouvé ce fil un peu par hasard alors que je cherchais autre chose. Je l’avais totalement oublié, preuve sans doute que je ne suis pas rancunier.
Comme il n’y a pas eu de suite, je ne sais pas si Olivier a trouvé la réponse qu’il cherchait.
Ce que j’ai proposé sur un autre fil répond me semble t’il exactement à sa demande : Pilotage circuit avec Gleisbox & MS2 + Arduino + PC avec RocRail
J’ai rapidement expliqué l’essentiel du montage ici : Homemade Marklin - création d'un circuit intelligent - #68 par bobyAndCo
Et je rappelle que j’ai écrit un article détaillé sur Locoduino :
https://www.locoduino.org/spip.php?article361
Sur ce, bonnes vacances à tous !
Christophe
1 « J'aime »
Bonjour à toutes et à tous,
J’ai une bonne nouvelle pour ceux qui s’intéressent à Rocrail pour piloter leur réseau avec juste une MS2 et la Gleisbox.
La passerelle que je vous ai présentée plus haut permet de piloter les locomotives et d’activer ou désactiver les fonctions. Je viens de terminer un programme de test qui permet aussi la reconnaissance du S88 dans Rocrail avec cette même passerelle. Cela veut dire qu’il est possible de faire de la rétro signalisation S88 pour ceux qui possèdent une MS2 ce qui jusque là n’était pas possible avec cette central.
Mes capteurs sur le bus S88 sont bien reconnus et dans mon programme de test, je les vois bien s’activer ou se désactiver sur le graphique du réseau comme dans le mode trace du moniteur.
Il faut que je mette de l’ordre dans mon programme et je vous le communiquerai alors.
Christophe
5 « J'aime »
Bonjour à tous,
Voilà j’ai terminé et testé le programme et je l’ai publié. Je précise bien que c’est une version Beta et qu’elle peut présenter des bugs. J’ai noté l’importance d’être précis sur ce point !
Après le pilotage des locomotives à partir de Rocrail® en utilisant une MS2 et une Gleisbox, je me suis donc attaqué à la reconnaissance des capteurs de voie reliés à la centrale par un bus S88.
L’un des objectifs est de pouvoir profiter de la commande automatique des trains et de la gestion des itinéraires dans Rocrail quand on ne possède qu’une MS2.
Il s’agit d’une passerelle dont le principe est similaire à celle qui sert au pilotage des locomotives.
C’est un ESP32 qui d’un côté lit les données du bus S88 (bus série) au rythme d’une lecture tous les 1/10 secondes, qui vérifie pour chaque capteur si l’état (actif / inactif) a été modifié depuis la précédente lecture et, s’il y a eu modification, transmet à Rocrail l’information au protocole MBUS, celui de Marklin.
Il existe trois possibilités de liaison avec Rocrail. Par le même bus CAN que celui de la commande des locomotives. En WiFi ou par une liaison filaire de type Ethernet. On est alors en TCP pour ces deux derniers cas.
Pour mes tests, j’ai adopté une liaison filaire Ethernet (exactement sur le même principe que le Link S88), cette passerelle ayant exactement la même fonction. C’est le mode que je recommande.
Le code du programme est ici : GitHub - BOBILLEChristophe/S88_to_Rocral_gateway
Dans la petite vidéo, les capteurs s’allument comme un sapin de Noêl mais il s’agit d’une simulation où tous les capteurs sont activés de manière aléatoire et surtout à grande vitesse pour mesurer le comportement de Rocrail.
https://www.youtube.com/watch?v=fdxofCAm-OY
N’hésitez pas si vous avez des questions, je répondrais volontiers.
2 « J'aime »
Bonjour Christophe,
Mise à jour,
Pour finir, j’ai opté pour la cc Schnitte comme module intermédiaire.
Pour le S88, j’ai acheté le module ZEUS de TAMS.
Les deux relié par USB à un Raspberry Pi 4 (pour faire simple) car avec Windows, j’ai des problèmes de communication sur le bus USB entre le PC la cc Schnitte.
Mais je reste très à l’écoute de tes conseils/epériences car mon setup (pas très classique) ne fonctionne pas à 100% comme je voudrais (cfr post de Julie sur cc Schnitte)
Olivier
L’essentiel est que ta configuration te donne satisfaction quelque soit le moyen pour y arriver.
Bon train !
Christophe
Bonjour Christophe,
Bravo pour tes derniers développement avec l’ESP32.
si j’ai bien compris, on a une interface ESP32_GW qui permet de se connecter en Ethernet câblé (ou Wi-Fi) à Rocrail et d’autre part au CAN bus (ce module peut remplacer donc CC Schnite)
Ensuite une autre interface ESP32 (S88_GW) avec d’un côté le bus S88 ancestral mais toujours
utilisé et d’autre part la connexion ethernet filaire (ou wi-fi).
Dans les 2 cas, l’usb local va permettre un mode console pour visualiser le trafic sur les bus.
Est-ce bien cela ?
On est fort intéressé par ces deux interfaces.
Peux-tu les fournir montés (ce qui simplifie les choses car je ne suis pas expert en ESP32) ?
Bon dimanche
Alain3R
1 « J'aime »
Je suis assez surpris de ce graphisme qui pour moi est assez polémique (et ne fait donc pas avancer la réflexion). De plus, il est sensiblement faux - si on a un bus CAN, ce n’est certainement pas par un Bus S88 qu’il est relié à une “console”, sans même considérer que l’image montre comme “console” une centrale Viessmann qui est une centrale 3-en-1 comme la CS des différentes générations en unissant en son boîtier la surface d’entrée et sortie (boutons, manettes, écran), la centrale et le booster - une “console” serait plutôt la MS2 qui n’est que l’appareil d’entrée et, rarement, sortie de commandes. Ce n’est pas non plus par des “detectors” ce qui ne veut rien dire d’aure que capteurs que l’information passe du booster à la voie, et les “gateway” seraient, si on prend le mot par le mot, des connexions, des passerelles, mais pas des éléments actifs du contrôle du réseau.
J’ose penser que la remarque de Jean suppose la programmation par mfx. Ce qui est le plus confortable, notamment en ce qui concerne les décodeurs Märklin/Trix, on est certainement d’accord là-dessus.
Rocrail permet de programmer des décodeurs par DCC, je ne l’ai jamais expérimenté et ne me prononcerai pas là-dessus, même si je trouve intéressante l’idée de changer des configurations telles que l’accélération ou la courbe de freinage en cours de jeu.
JMRI et DecoderPro utilisent également DCC, la surface graphique est un peu “linuxoïde” et se démarque des surfaces hautes en couleur dont nous avons l’habitude, mais c’est bien efficace surtout pour les décodeurs complexes et compliqués à programmer par DCC en l’absence de l’appareil et logiciel de programmation proposés par le constructeur.
Juste pour clarifier, en mfx (donc avec une CS ou MS de toutes les générations) d’autres locomotives peuvent être sur le réseau, la connexion entre centrale et loco se fera quand même. (Avec des centrales un peu anciennes il vaut mieux ne pas avoir trop de décodeurs en même temps quand même, l’ouïe souffre avec l’âge. Plaisanterie. Une CS3 ou une MS2 moderne n’aura pas de soucis. Une centrale ECOS par contre pourra mettre longtemps à bien connecter une nouvelle loc…
Voilà qui est le plus important - et j’oserais dire, que “passion” ne soit pas à comprendre littéralement c’est-à-dire au sens “souffrance” !
Et je fais un 2e message, la thématique étant une toute autre… enfin, dans ma tête au moins.
Si j’avais eu ça il y a 10 ans, je n’aurais peut-être jamais acquis une RedBox.
Juste pour bien comprendre : quelle est la vitesse de données transmise par le bus s88 ? Il est réputé comme lent (quoi que normalement suffisant pour un réseau domestique), est-il possible pour un bus de longueur maximale (512 contacts) de relever tous les contacts 10 fois par seconde ? Je sais que la longueur des connexions joue aussi, pour une supposée longueur maximale de 30 mètres Monsieur tams indique 200 ns …
On dit aux enfants de tourner leur langue sept fois dans la bouche avant de parler. Il devrait en être de même pour ceux qui clavardent. Il faut parfois passer un peu de temps à lire et ne pas hésiter à poser des questions. Ce que présente Jean-Pierre Claudé dans cet article, c’est justement des passerelles qui permettent d’avoir l’ensemble du bus de rétrosignalisation en CAN. Puis, infine, de “convertir” les messages CAN en messages S88. C’est le boulot des passerelles qui sont placées à proximité de la centrale pour éviter les problèmes bien connus sur les anciens S88 (5v - fils plats). La centrale n’est pas une Veissman mais une ECOS.
Tout est parfaitement expliqué dans l’article.
Enfin, je précise que Jean-Pierre Claudé est quelqu’un de très rigoureux. Tout ce qu’il a publié a été testé sur son propre réseau (c’est plus facile quand on en a un). Il est l’un des rares en France qui se soit vraiment passionné pour le DIY au service du 3R et surtout qui a publié, c’est-à-dire partagé.
C’est vrai que pour des petits ou moyens réseaux, on parle de queues de cerises. Mais le processus qui cherche à savoir si le couple IUID et locID du décodeur est bien enregistré dans la centrale est tout de même consommateur de ressources. Il se répète toutes les 12 secondes environ. La centrale envoie un message à toutes les décodeurs « actifs » dans la centrale. Ceux-ci répondent. Ceux qui ne répondent pas sont désactivés dans la centrale. Pour ceux qui répondent, la centrale vérifie le couple UID-locID et envoie un nouveau locID si le précédent était inconnu. Pour ceux qui ne sont pas enregistrés, la centrale procède à cela. La fameuse reconnaissance. Puis le décodeur confirme. Bref, c’est pas mal d’échanges et un peu lourds en datas puisqu’un UID c’est 32bits, un locID, 16 bits.
On le constate concrètement car la reconnaissance prend parfois un peu de temps.
De plus le bus MFX, n’est pas de plus un foudre de guerre, environ 10 000 bits / seconde. Et ça n’aide pas les choses quand en plus on envoie des commandes en DCC comme les commandes d’aiguilles.
Petite confusion ici également. Quand je parle de 100ms, ce n’est pas du tout la fréquence du bus S88 mais celle à laquelle la passerelle va envoyer ses informations à Rocrail. Ceci afin de ne pas saturer la connexion TCP avec Rocrail qui peut en avoir beaucoup d’autres actives.
Et encore, pas forcément toutes les 100ms car j’ai installé un processus qui compare, pour chaque décodeur S88 si des données ont changées (changement d’état de capteurs). Alors là seulement, l’information est envoyée à Rocrail.
C’est cette ligne dans le programme :
if (module[idModule].value != (uint16_t)frameIn.data16[0])
En réalité, le programme scrute les réceptions du bus S88 toutes les millisecondes soit 1000 fois par secondes ! Ceci est possible avec un Raspberry Pi Pico qui est cadencé à 132MHz et dispose de deux cœurs indépendants.
Pour les 200ns de Tams, je suis un peu dubitatif, ça fais tout de même 5 millions de fois par seconde, mais si tu le dis !!!
1 « J'aime »
Alors c’est une ECOS ; ça n’y change rien.
Reste quand même que ce graphisme (présenté par @Benoit92 dans le message #4 du fil ! et répété par la suite par Benoît), sans explication aucune, montre des infos venant des passerelles et allant via S88 dans la centrale. Et là, tu es certainement d’accord, c’est absurde.
D’ailleurs, je ne vois nulle part dans ce fil que ce graphisme est de la plume de Jean-Pierre Claudé ! S’il en est ainsi, il serait nécessaire car obligé par la loi de lui demander son autorisation avant de reprendre l’image ici, dépourvu des explications que son auteur y avait associées.
C’est clair. Néanmoins, les centrales Märklin peinent beaucoup moins que les centrales ESU (y compris la CS1 reloaded ou non).
D’où la vive recommandation de séparer ces commandes d’aiguilles de celles pour les locos, en utilisant des boosters séparés - je ne sais maintenant pas si Märklin permet de séparer les infos à la sortie, ma RedBox peut le faire. Mais en Märklin ce serait vachement utile d’envoyer les infos DCC seulement sur les boosters réglés pour et les infos mfx seulement sur les autres.