Une page faisait autorité, elle existe encore dans la wayback machine (ouf) :
https://web.archive.org/web/20120729085546/http://www.alice-dsl.net/mue473/mfxrahmen.htm
1 « J'aime »
Merci Julaye,
Je ne vois plus le post avec le lien sur la doc CS2 can protokoll (peut-être l’as-tu retiré) mais j’ai eu le temps de charger le document.
Il n’y a pas de discussion quant à la supériorité de la technologie Marklin. Les deux protocoles utilisés, le CAN et l’Ethernet sont ce qu’il y a de mieux sur les réseaux de modélisme ferroviaire.
Les deux documents que tu m’as communiqués fournissent la structure des messages CAN pour les différentes instructions (commandes de locomotives, fonctions, retro-signalisation…). Ce sont rigoureusement les structures des messages CAN « classiques », il ne devrait pas être trop difficile de retrouver avec un Arduino (ou mieux un ESP32) équipé d’un transceiver CAN, l’UID dans les messages échangés. Je suppose en effet que les décodeurs MFX (comme en Railcom) retournent ces informations très régulièrement à la centrale.
1 « J'aime »
Bonsoir
Je remets la page sur le protocole de la CS2
(J’ai pense qu’elle était moins intéressante que l’autre mais manifestement elle donne des infos)
Bonsoir
Julie, la doc que tu donnes c’est la norme pour la communication entre l’ordi, la centrale et les différents périphériques (booster et autre). Il ne décrit (presque) en rien le signal qui passe dans la voie.
Boby: à ma connaissance ce document Beschreibung des mfx®Schienenformats est le seul qui décrit le signal mfx qui passe dans la voie. Quoique depuis que je l’avais remarqué, il y a éventuellement un autre qui est sorti.
Comme souvent, il faut apprendre l’allemand.
Je sais qu’il existe et je sais le retrouver, par contre je ne l’ai pratiquement pas lu, je ne pourrai pas plus aider.
Très honnêtement, je ne sais pas si ce que tu veux faire est possible, car cela n’existe pas sur le marché, malgré les presque 20ans que le protocole existe.
Ne pas oublier que le RailCom est plus jeune, c’est normal qu’il y aie plus de fonctionnalités.
Sylvain
1 « J'aime »
C’est pour ça que je l’avais retiré 
mais comme Boby la trouvait intéressante … je l’ai remise.
Merci à tous les deux,
@Delias Ce n’est pas tant le signal qui passe dans la voie qui est important ici que la structure du message CAN que l’on doit envoyer au 60113. C’est lui qui va moduler le signal sur les rails en fonction du message CAN reçu.
Ce que je souhaite faire est assez simple, j’aimerais connaître l’UID du décodeur d’une loco. C’est exactement l’opération de découverte que font les centrales quand on pose la locomotive sur la voie. La locomotive envoie un message à la centrale (contenant ce fameux UID) qui permet à la centrale de savoir exactement à quel modèle elle à faire et de retourner une adresse au décodeur. C’est bien sûr l’adresse qui m’intéresse mais il faut au préalable connaître l’UID.
Ce processus est très similaire au fonctionnement de Railcom (bidirectionnel).
A partir de là, on peut faire de la détection, non pas seulement de présence mais aussi de l’identification et déclencher des événements personnalisés. J’ai ainsi mis au point des petits détecteurs sur des cantons qui, en fonction de l’adresse de la loco présente, peuvent leur envoyer des commandes personnalisées (arrêt, ralentissement, fonction sonore…) mais il leur faut connaître l’adresse. Ca fonctionne en DCC, ce serait sympa de le faire aussi en MFX.
J’ai pu constater dans le document de Julie que le protocole de messagerie CAN est rigoureusement conforme à la norme, il ne sera pas très difficile d’installer un sniffer.
De ta demande initiale, je comprends que tu veux faire l’équivalent du MARCo d’Uhlenbrock ou le LRC120 RailCom Adressanzeige de Lenz mais pour mfx. Puis d’utiliser l’adresse lue pour lancer des actions prédéterminées.
Et pour cela il faut faire un détecteur de rétro-signalisation par consommation avancé qui lit le retour que le décodeur envoie dans la voie et donc s’intéresser au protocole voie et non au protocole CAN.
Ce type de décodeur de rétrosignalistion en mfx n’existe pas, c’est pour cela que je pense que ce n’est pas possible (pas prévu dans le protocole).
En analysant le bus CAN du 60113 qui est la partie booster des centrales MS2, tu pourras savoir que telle ou telle loco est enregistrée dans la centrale, éventuellement qu’elle est présente sur les voies (je ne connais pas assez le protocole pour savoir si cette information est connue ou pas de la centrale) mais il est exclu de pouvoir déterminé où elles sont sur le réseau (pas de localisation par tronçon isolé). Et il est exclu de pouvoir mettre plusieurs 60113 sur un seul réseau.
Ensuite l’UID est très peu échangé, c’est surtout à l’enregistrement du décodeur, puis la communication se fait avec l’adresse courte, et le décodeur ne se manifeste que si la centrale n’a plus son adresse en mémoire. Les trames avec l’UID ne sont que sporadique sur le bus CAN une fois l’enregistrement terminé.
Sylvain
Bonjour,
l’un de vous a-t-il réussi à capter et déchiffrer les messages qui s’échangent sur la voie de programmation entre la loco et la centrale? On pose bien la question “dit moi qui tu es?” puis on lui dit maintenant je te baptise nn. Donc ces fonctions existent dans la centrale, le challenge est de savoir comment les déclencher lorsque la loco entre sur un canton.
Je suis très fortement intéressé par la solution.
ROZ
La difficulté c’est de faire en sorte que le canton se comporte comme la voie de programmation … mais se pose le pb de la transition du signal numérique quand le patin va être à cheval entre deux cantons, l’un géré par la centrale principale et l’autre géré par une centrale bis essayant de déterminer l’UID … mais faisant quand même office de Gateway (comme les booster) pour les autres commandes en provenance de la centrale principale. ça me parait bien scabreux …
Ou alors il faut une zone d’exclusion sans signal numérique entre les deux cantons, sur le principe du module de freinage (cf Avontuur in Miniatuur) … ce qui n’est pas forcément idiot de faire freiner la locomotive avant qu’elle rentre sur la zone de détection de son UID.
@Roz La voie de programmation n’entre pas en ligne de compte, en MFX j’entends bien sûr. En effet, si l’on pose une locomotive sur la voie principale et que la station ne la connait pas, cela va déclencher tout même le processus de découverte et l’attribution de l’adresse.
le challenge est de savoir comment les déclencher lorsque la loco entre sur un canton.
Avec Railcom, c’est le décodeur envoie à intervalles réguliers (toutes les 100 µSec environ) son adresse et d’autres informations. J’ai vu quelque part que c’est pareil pour le MFX et MFX+ qui envoie encore plus d’informations comme Railcom+ d’ailleurs. C’est amusant ces similitudes.
Avec Railcom toujours, il faut bien sûr une zone isolée et c’est la même chose avec MFX comme vous l’avez bien compris. Le signal émis est alors reçu par une carte électronique ad hoc, pour chaque canton. Cette carte décode le paquet qui contient l’adresse et la rend disponible, soit en push, soit en get pour tous les périphériques qui en ont besoin. En Railcom, j’ai fait cela sur un bus CAN spécifique puisque c’est une communication broadcast, toutes les cartes CAN reçoivent l’ensemble des messages qui circulent sur le bus. Elle peut aussi filtrer ce qui l’intéresse mais je ne vais pas entrer dans les détails.
Le message CAN envoyé est de type, « je suis le canton X et j’ai actuellement la locomotive n° XXX qui est sur mon canton ». Les cartes périphériques qui reçoivent ces messages en font ce qu’elles veulent, soit rien, soit lire une bande sonore, voire même envoyer une commande à la locomotive (arrêt, ralentissement, actionnement d’une fonction…).
@Julaye : se pose le pb de la transition du signal numérique quand le patin va être à cheval entre deux cantons,
C’est quelque chose qui se règle de manière logicielle. Si une carte périphérique reçoit des messages CAN de deux cantons qui déclarent avoir la même locomotive, on peut programmer l’action souhaitée à la condition que l’on ne reçoive plus de message de l’un des deux cantons dans un laps de temps donné, 1 seconde, 2, 3…
J’ai développé une carte de détection Railcom et le soft qui va avec. Si certains sont intéressés, je veux bien détaillé la chose.
D’autant que je pense que le fonctionnement est sans doute le même en MFX (envoi à intervalles réguliers de l’adresse). Si ce n’est pas le cas, c’est pour cela que je cherche à connaitre le message CAN pour obtenir l’UID. Je pense envoyer cette commande quand la détection de courant est active et espérer avoir en retour du décodeur son UID qui me permet de savoir à quelle locomotive j’ai à faire.
1 « J'aime »
@Delias, De ta demande initiale, je comprends que tu veux faire l’équivalent du MARCo d’Uhlenbrock ou le LRC120 RailCom Adressanzeige de Lenz mais pour mfx. Puis d’utiliser l’adresse lue pour lancer des actions prédéterminées.
Oui, c’est exactement cela, comme Railcom en effet.
Et pour cela il faut faire un détecteur de rétro-signalisation par consommation avancé qui lit le retour que le décodeur envoie dans la voie et donc s’intéresser au protocole voie et non au protocole CAN.
Oui c’est vrai, il faut s’intéresser au signal sur la voie. Je ne me sers pas du 60113 pour cela mais d’une carte dédiée pour chaque canton isolé comme en Railcom.
J’espère avec un sniffer lire ce que le décodeur envoie sur la voie quand il reçoit une demande d’UID (cette fois au travers du 60113). C’est très certainement un signal série comme Railcom.
Il faudra aussi sniffer à la sortie du 60113 le codage binaire du message d’interrogation de l’UID qui est envoyé au rails pour pouvoir le reproduire.
Ca mérite d’être essayé d’autant que ça risque d’être très long mais pas très compliqué à faire avec un Arduino ou plus probablement un ESP32.
Et si ça ne marche pas, au moins j’aurai essayé !
Bonsoir
Je ne comprends toujours pas ton message #6.
Ce que tu dois analyser c’est le signal voie, ce qui passe sur le bus CAN te sera presque inutile.
Le 60113 est un GFP (Gleis Format Processor) que l’on peut traduire par “processeur du signal voie” dans le langage de Märklin. Il est fortement autonome et ne communique avec les GUI (la MS2) que pour les “choses utiles” ou autrement dis les commandes, la programmation des CVs et le processus d’annonce d’un nouveau décodeur, qui ne se produit qu’à la première mise sur le réseau de chaque décodeur. Le bus CAN c’est la communication entre les GUI et les GFP et la rétrosignalisation (L88 pour les CS)
Tout ce qui concerne la détection permanent d’un nouveau décodeur présent sur le réseau de même que la présence ou pas des décodeurs mfx enregistré ce fait au niveau du GPF et ne remonte pas aux GUI.
5 minutes de lecture en diagonale du document que j’ai mis en lien, m’a permis de voir que c’est faisable, que l’info est bien là-bas et non sur le CAN, par contre l’identification ne sera pas immédiate. (J’ai mis plus de temps à relire tes messages pour être sur que j’avais bien compris ta demande).
Sylvain
Et pour être un peu plus précis, dans une CS2 ou CS3, il y a un GUI et un GFP. La rétrosignalisation présente dans les CS2 et CS3 (l’hôte du bus s88) est géré par le GFP, mais c’est à voir comme un module L88 également présent dans la centrale selon mon explication ci-dessus.
Tout d’abord merci de t’intéresser à ce sujet.
Je ne vois pas de document joint !!!
Merci et je regarde cela puis te répond
Christophe
Quelques nouvelles suite à ma demande d’infos. Grace au doc que m’a transmis Julie (cs2can-protokoll) j’ai pu communiquer avec un ESP32 et deux de mes locos en MFX.
Je récupère bien l’UID ce qui me permet d’envoyer des commandes aux locomotives. Je commandes les fonctions (lumières, sons…) et je vais monter un petit réseau de test pour les faire rouler. Je ferai alors une vidéo que je posterai.
Je n’ai besoin que d’un Gleisbox 60116 (ou 60113), d’un ESP32 et de rails et de locos bien sûr. Et cela grace à la communication en CAN entre l’ESP32 et la Gleisbox.
Le second ESP sur la photo est un sniffer pour tracer les messages échangés entre les décodeurs et la Gleisbox.
2 « J'aime »
Bonjour,
BodyAndCo je suis impatient de voir ta démo et d’avoir un schéma de branchement entre tous les composants que tu sites.
j’ai une simple CS2 et de S88 et L88 le tout en voie M que je peux substituer par de la voie VB, les rails VB sont isolés contrairement à Marklin et ils s’emboitent très bien les uns avec les autres.
Merci par avance.
ROZ
Bonjour Roz,
La CS2 est déjà une belle station !
Peux-tu préciser ce que tu voudrais faire. Car ce dont je parle dans ce post est un simple envoi de messages CAN (commandes de traction et commandes de fonctions) et aussi réception en retour du décodeur comme l’UID. Mais on est loin de ce que peut faire une CS2 ou une CS3.
Si ton souhait est de remplacer ta CS2, il n’y a pas d’autres solutions viables que d’utiliser un logiciel de type Rocrail, TrainController, CDM-Rail, JMRI ou autres. Ces logiciels sont vraiment très complets (complexes), je crois qu’il ne serait pas très sérieux de vouloir développer son en propre soft. Interfacer ces logiciels avec un Gleisbox (sans passer par une CS2 ou 3) n’est pas très compliqué mais limité à moins de 2A (environ 5 à 6 locos MFX roulant en simultané ce qui est déjà bien).
Avec ces logiciels, tu trouveras, à mon avis, des fonctionnalités supérieures à ce qu’apportent les CS2, CS3 et aussi plus d’ergonomie.
C’est quelque chose que j’envisage de faire prochainement en utilisant dans un premier temps le CC-schnitt qui convertit un signal série (USB de l’ordinateur) en messages CAN. Par la suite, je chercherai à réaliser une passerelle Serial / CAN et mieux Ethernet (Wifi) / CAN. Ce qui est le fonctionnement avec une CS2 CS3 et qui est le must. (*).
Tu parles aussi du S88 (et L88). Est-ce quelque chose que tu souhaites remplacer par du CAN ? Si c’est cela ton projet, surtout sur de la voie VB, sache que c’est quelque chose de très réaliste (et très performant). J’ai moi-même fait toute ma rétro sur mon réseau avec un bus CAN à 1Mbs (à comparer au S88 à 9600 Bauds).
Merci de préciser ce que tu souhaites faire.
(*) Au passage, si quelqu’un peut m’orienter sur les protocoles de messagerie (Serial et UDP) entre Rocrail et la CS2/CS3 je suis très intéressé. Merci par avance.
Bonjour BodyAnsCo,
Voici ce que je désire réaliser.
Lorsque qu’une loco passe sur certains cantons je récupère son UID et lui donne une séquence d’ordres à réaliser : ralentir, siffler, klaxonner, s’arrêter, étendre les phares et l’éclairage cabine, attendre 30 secondes, rallumer toutes les lumières, klaxonner, accélérer.
Le tout dans une procédure (Itinéraire) générique où l’UID capté par un S88 est le paramètre de chacune des actions.
En programmation logique j’aurais écrit:
Capte UID Gare1-Voie1.
Call “Quai-standard” using UID.
Et Quai-standard serait ; Ralentir UID, Activer Klaxonne UID, etc
Donc pour chaque canton on aurait une procédure (itinéraire) qui enchaine la procédure (itinéraire) de captation de l’UDI et la seule et unique procédure (itinéraire) d’actions standard quelque soit le quai de gare et la loco. On s’adresse à une loco donc nous n’avons pas besoin du numéro du canton.
L’itinéraire Gare1-Voie1 enchaine “Capte UID Gare1-Voie1” et “Quai-standard”.
Pour résumer autant de procédures de captation que de cantons, et autant de types de procédures d’actions et pour chaque canton une procédure qui enchaine captation de l’UID et les actions à réaliser sur ce canton.
Voilà ce que je désire réaliser, ce qui implique techniquement de capter un UID et de paramétrer chaque action par cet UID.
Même avec un logiciel comme Rocrail je n’ai pas trouvé la solution.
Beau sujet de pilotage des trains.
ROZ
Ok je comprends bien. Mais sur du 3 rails, je n’ai pas (encore ?) la réponse à cela mais c’est un sujet que je cherche à approfondir.
Comme je l’ai montré, il est facile d’envoyer une commande à un décodeur ou lire l’UID, ceci grâce à la simplicité du protocole CAN, autant ça devient compliqué de lire l’UID dans un environnement de cantonnement avec, c’est la raison d’être du cantonnement, plusieurs locomotives sur le réseau. On peut envoyer une commande de lecture d’adresse via la (le ?) Gleisbox mais si plusieurs locos répondent, c’est inexploitable.
Avec Railcom, le canton est totalement isolé, on place alors un détecteur Railcom sur chaque canton pour lequel on souhaite obtenir l’adresse. Le signal renvoyé par le décodeur est assez « basic », c’est un signal série à 500 Kbauds qu’on amplifie et que l’on décode ensuite avec du logiciel embarqué (Arduino ou ESP32).
En 3 rails, le principe est forcément le même (signal série), mais ce signal est-il disponible sur le rail isolé ? Si oui, il faut le « sniffer » à l’oscillo pour décrypter les informations binaires : 7 ou 8 bits, parité de trame ? Et encore, Marklin a t’elle repris le protocole série ? Ca on peut le trouver dans le document transmis par Julie mais je pense que oui.
Mais je ne suis pas électronicien et ce n’est donc pas mon domaine de compétence.
Delias soulevait le fait que l’UID n’est que peu échangé mais on voit bien que l’on peut commander cette demande aussi souvent qu’on le veut.
Il n’y a pas de problème d’amplification du signal série. En effet, on constate bien que le décodeur MXF sait communiquer dans le sens retour sur le même protocole qu’en sens aller (ce qui n’est pas le cas en DCC). C’est déjà beaucoup !
Ensuite, c’est du logiciel, là je sais faire même si parfois c’est tordu. Pour ceux que ça intéresse, je vous renvoie par exemple page 6 chapitre 2.4 du document NMRA sur le 4/8 encoding ! Si le protocole n’était pas publié, il y a peu de chance de le découvrir à moins peut-être d’être expert en cryptologie : https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.3.2_bi-directional_communication.pdf
En résumé, il faut avant tout répondre à deux questions :
- Le retour d’information « binaire » du décodeur à une commande est-il disponible sur le rail isolé ?
- Est-il possible d’avoir le protocole de communication du décodeur vers la Gleisbox et la structure du message pour l’adresse UID ou, faute de mieux, des captures d’écrans oscillo ?
Si certains ont des compétences en traitement de signaux et sont intéressé, je peux m’intéresser à la partie logicielle.
Christophe
Bonjour à tous,
Voici la petite vidéo qui montre comment je pilote une locomotive MFX en utilisant simplement un ESP32 (équipé d’un transceiver CAN MCP2562) et la Gleisbox 60116 de Marklin.
En parcourant le forum, j’ai trouvé un fil où il était question de la bibliothèque Railuino de Joerg Pleumann qui est particulièrement bien écrite et complète : Homemade Marklin - création d'un circuit intelligent
Je suis par contre en train de la réécrire en profondeur car elle a maintenant 11 ans d’âge et n’incorpore pas, en particulier, les nombreuses avancées de la normes C++11 (et suivantes). Elle n’est de toutes les façons plus compatible avec les bibliothèques CAN récentes et pas supportée sur l’ESP32 (qui n’existait même pas à l’époque) !
La vidéo montre bien (j’espère) qu’il est possible avec un simple microcontrôleur à 10€ de commander totalement des locomotives et apporter des animations sur le réseau : ralentissement dans certaines zones, sifflet, allumage des feux, annonces en gare etc…
A noter que l’on peut placer un ou plusieurs microcontrôleurs sur le même bus CAN qu’une CS2 ou CS3 par exemple. Et j’ai même pu constater que les informations des CS étaient mises à jour en temps réel en fonction des commandes des microcontrôleurs comme la vitesse ou les fonctions activées par exemple.
Merci encore à Julie pour la documentation « cs2can-protokoll-2_0 » car toutes les commandes CAN y sont documentées et souvent commentées. Très précieux !
PS : A l’attention des auteurs du fil cité plus haut, ça pourrait être sympa de réactiver le sujet avec ces nouveaux éléments ?
Christophe.
1 « J'aime »
@TroisRoz Pour répondre (partiellement) à la demande de Roz, j’utilise une carte ESP32 sur un PCB que j’ai dessiné avec son transceiver CAN MCP 2562. Je peux fournir le GERBER si demande.
La broche CAN H de la carte est reliée dans la broche 4 de la prise DIN de la Gleisbox et la broche CAN L à la broche 8 de la Gleisbox. J’ai relié les masses entre elles (broche 2 de la Gleisbox) bien que cela ne soit sans doute pas nécessaire.
Comme on le voit sur les photos, l n’y a rien d’autre hormis l’alimentation 18V.
Christophe.