LOCODUINO - l'Arduino pour le train miniature

La programmation de CV est possible avec la librairie qui produit des signaux DCC. D'ailleurs, je l'ai fait sur mon controleur DCC maison pour changer au moins l'adresse d'une loco. Aller plus loin est plus difficile. Un décodeur, lorsqu'il reçoit une ordre de lecture de CV, pour remonter la valeur courante vers le contrôleur, provoque de minis court-circuits sur la voie en décrivant la valeur. Nous n'avons encore rien planifié pour tenter d'interpréter ces court-circuits... Mais des pistes sont explorées !

Sauf erreur de ma part, il y a deux solutions pour lire les  CV d'un décodeur.

- Le décodeur connaît le RailCom et la centrale aussi, dans ce cas c'est simple, la centrale demande le CV en question et reçoit la réponse.

- Le décodeur n'est pas RailCom et la centrale non plus : Il faut alors utiliser la seule réponse possible du décodeur qui est l’acquittement d'une commande, qui se manifeste par une très courte consommation de courant (ACK = au moins 60mA pendant 6ms).
Les commandes disponibles en DCC sont:
- écriture d'un octet pour le CV x
- vérification d'un octet pour le CV x
- écriture du bit b du CV x
- vérification du bit b du CV x

Si l'écriture se passe bien, le décodeur répond "ACK", sinon il ne répond rien.
Si la vérification se passe bien, c'est à dire si l'octet ou le bit du CV est identique à celui envoyé pour vérification, le décodeur répond "ACK".

Pour lire un CV, il faut donc faire une vérification bit par bit du CV étudié avec un  bit "1" par exemple, si le décodeur répond "ACK" alors le bit du CV est à 1, sinon c'est un 0.

Évidemment c'est un peu long !

Bonsoir,

2e article sur la PWM et premier d'un serie sur la commande de moteurs.

La PWM : qu'est ce ? (2)

Bonne lecture.

Bonjour jlb..

merci pour tés messages de bienvenue et pour tés articles .je trouve ce sujet super de part

sa convivialité et son niveau de technicité je profite pour remercier les autres rédacteurs tout

aussi talentueux. j’espère un jour arriver a utiliser Arduino sans trop de handicaps ...

bonne journée..
Christian 04

Merci Christian

Voici deux nouveaux articles sur Locoduino :

Une animation sonore

Une horloge à l'échelle H0

Bonne lecture

La modélisation de votre propre réseau en vue d'une gestion sophistiquée, personnelle et libre est un sujet rare que Locoduino traite avec courage.

Voici justement une nouvelle approche (après celle de DDEF : SGDD): celle de Pierre59 que j'intègre avec succès dans mon réseau.

La genèse d'un réseau 100% Arduino

Un gestionnaire en C++ pour votre réseau (1ère partie : Aiguilles et Zones)

Bonne lecture !

SixtyFive a écrit:

La modélisation de votre propre réseau en vue d'une gestion sophistiquée, personnelle et libre est un sujet rare que Locoduino traite avec courage.

Voici justement une nouvelle approche (après celle de DDEF : SGDD): celle de Pierre59 que j'intègre avec succès dans mon réseau.

La genèse d'un réseau 100% Arduino

Un gestionnaire en C++ pour votre réseau (1ère partie : Aiguilles et Zones)

Bonne lecture !

Bonjour,

Dans le projet "100% Arduino", il y a une assertion qui montre que malheureusement beaucoup de ceux qui se lancent dans le challenge ne connaissent pas comment marche un réseau DCC automatisé par logiciel "dans la vraie vie".

Je cite:
Une autre raison m’a amené inexorablement à choisir cette architecture : je veux que les positions de mes trains (couple train + zone) soient automatiquement reconnues par le gestionnaire pour assurer le pilotage en DCC.

Or cette fonction de reconnaissance n’existe pas avec les centrales et les logiciels du commerce ! [1] Je me devais de relever ce challenge.

Dans la réalité, la problématique est inverse: le logiciel connait en permanence la position d'un train puisque c'est lui qui le pilote. Une fonction de paramétrage permet préalablement au logiciel de connaître la vitesse réelle pour chaque cran de décodeur. Lors de la conduite, une simple addition des distances parcourues pour chaque niveau de vitesse programmée (L = VxT) permet d'estimer la position sur le réseau. Les changements de canton permettent de "rattraper" les éventuelles écarts de distance.

Qui plus est, dans le texte cité- ci-dessus, le petit [1] renvoie vers une interrogation sur une hypothétique faisabilité avec du Railcom alors que ce dernier n'a rien à voir avec la problématique.

J'ai peur que si on part sur des bases fausses, cela conduise à une usine à gaz qui sera totalement inopérante dans les faits.

JPGO a écrit:

Bonjour,

Dans le projet "100% Arduino", il y a une assertion qui montre que malheureusement beaucoup de ceux qui se lancent dans le challenge ne connaissent pas comment marche un réseau DCC automatisé par logiciel "dans la vraie vie".

Je cite:
Une autre raison m’a amené inexorablement à choisir cette architecture : je veux que les positions de mes trains (couple train + zone) soient automatiquement reconnues par le gestionnaire pour assurer le pilotage en DCC.

Or cette fonction de reconnaissance n’existe pas avec les centrales et les logiciels du commerce ! [1] Je me devais de relever ce challenge.

Dans la réalité, la problématique est inverse: le logiciel connait en permanence la position d'un train puisque c'est lui qui le pilote. Une fonction de paramétrage permet préalablement au logiciel de connaître la vitesse réelle pour chaque cran de décodeur. Lors de la conduite, une simple addition des distances parcourues pour chaque niveau de vitesse programmée (L = VxT) permet d'estimer la position sur le réseau. Les changements de canton permettent de "rattraper" les éventuelles écarts de distance.

Qui plus est, dans le texte cité- ci-dessus, le petit [1] renvoie vers une interrogation sur une hypothétique faisabilité avec du Railcom alors que ce dernier n'a rien à voir avec la problématique.

J'ai peur que si on part sur des bases fausses, cela conduise à une usine à gaz qui sera totalement inopérante dans les faits.

Bonjour JPGO,

J'ai bien compris la réponse, mais pas la question !!!

Le logiciel (ou la centrale) qui pilote les trains en DCC, les connait forcément par son adresse DCC (sinon, comment pourrait-il envoyer une commande ?). La relation entre le cran DCC mis dans la commande et la vitesse réelle relève de l'étalonnage, c'est un autre sujet, important aussi.
Mais ce logiciel ne connait pas à priori la position des trains sur le réseau tant qu'elle n'a pas été déterminée au préalable, d'une manière ou d'une autre.

TrainController a besoin qu'on lui désigne la position de chaque train au départ. Sinon, je ne vois pas comment il pourrait le suivre. Ensuite il s'arrange pour ne plus le perdre, de la façon que tu as fort bien décrite, c'est bien évident.

Certains logiciels (je ne les connais pas tous) mémorisent la position des trains avant l'extinction de l'alimentation pour la restaurer au prochain allumage (à condition de ne pas les bouger à la main).

Railcom est une technologie propriétaire qui permet à un train équipé du décodeur ad hoc, sur une zone particulière équipée d'un détecteur compatible Railcom, de communiquer son adresse DCC. Quand un train est détecté avec Railcom, au passage dans cette zone, on associe donc l'adresse DCC du train avec sa position (la zone en question) sur le réseau. Ensuite, c'est pareil, il ne faut pas le perdre (on le revoit au tour suivant, ouf !).

Maintenant, il existe probablement d'autres solutions. En tout cas dans ma vraie vie, je n'utilise ni TrainController, ni Railcom et je n'ai pas prévu d'interface pour dire à mon logiciel que tel train X est placé sur la zone Y. Je compte simplement faire autrement. Si ça peut intéresser un modéliste, j'en serais heureux. Pour le moment c'est seulement à l'étude (bien que j'ai déjà utilisé avec succès la technologie RFID qui donne un résultat équivalent à Railcom).

Mais je n'empêche personne d'utiliser sa propre technique.

SixtyFive a écrit:

Railcom est une technologie propriétaire qui permet à un train équipé du décodeur ad hoc, sur une zone particulière équipée d'un détecteur compatible Railcom, de communiquer son adresse DCC. Quand un train est détecté avec Railcom, au passage dans cette zone, on associe donc l'adresse DCC du train avec sa position (la zone en question) sur le réseau. Ensuite, c'est pareil, il ne faut pas le perdre (on le revoit au tour suivant, ouf !).

Tu as tout à fait raison de préciser qu'il faut qu'au "début du jeu", le logiciel connaisse la position des trains. Cela correspond aux conditions initiales nécessaires à toute étude de processus évolutif. Railcom pourrait paraître une solution mais la encore, la réalité est un peu plus compliquée. Ce qui doit être piloté, ce n'est pas uniquement une loco, mais une rame, qui va avoir une longueur différente selon le nombre de wagons. Et par exemple pour arrêter un train avec le milieu de la rame au milieu du quai, quelque soit le nombre de wagon, Railcom ne sert malheureusement à rien. De même pour éviter d'arrêter un train dans un canton trop court.

Mais bon, les projets généralement présentés sont au stade de l'étude préalable. On aura les idées plus claires lorsque tout ça tournera pour de vrai.

Voila qui est plus clair.

Sur mon réseau, j'ai un décodeur Railcom par canton, ce qui me permet de connaître la position des trains au départ. En cours de jeu, les adresses DCC sont lues uniquement pour faire un contrôle de cohérence et pour l'insertion d'une nouvelle loco.
Pour le reste c'est la transition d'un canton à l'autre qui valide le déplacement d'un train.

Mais je n'ai pas de système permettant d’arrêter les trains au milieu du quai, seulement au pied du feu, à développer un jour ou l'autre; il y a tellement de chose à faire.

Le Railcom a été proposé par Lenz il y a des années,  le protocole et les interfaces électriques sont connues et utilisées par d'autres fabricants (ESU, Uhlenbrock...) , on ne peut donc plus parler d'un système propriétaire, de plus il est dans la norme NMRA .

CleoN a écrit:

Le Railcom a été proposé par Lenz il y a des années,  le protocole et les interfaces électriques sont connues et utilisées par d'autres fabricants (ESU, Uhlenbrock...) , on ne peut donc plus parler d'un système propriétaire, de plus il est dans la norme NMRA .

Merci pour cette précision utile à rappeler. Je ne le savais pas  

Je ne connais pas non plus le coût d'un détecteur Railcom : un par canton, ça a du te coûter un doigt ?

SixtyFive a écrit:

Je ne connais pas non plus le coût d'un détecteur Railcom : un par canton, ça a du te coûter un doigt ?

Dans la mesure ou c'est un développement maison et intégré au reste de la gestion d'un canton, ça ne coûte pas cher.

Sans compter que je n'ai pas beaucoup de cantons, 14 pour l'instant et une vingtaine à terme.

Voici un nouvel article sur Locoduino :

La réalisation pratique d'un décodeur DCC pour les signaux à deux ou trois feux sur Arduino NANO/UNO

Bonne lecture

Voici le premier article d'une série qui promet d'être passionnante sur Locoduino :

Gestion d’une gare cachée (1)

Bonne lecture

Bonjour

Sauf erreur de ma part, le lien ne renvoi pas à l'article en question... certainement très intéressant...comme tout le site...

Merci

Sergio11 a écrit:

Bonjour

Sauf erreur de ma part, le lien ne renvoi pas  à l'article en question... certainement très intéressant...comme tout le site...

Merci

si, si ça marche maintenant

Bonjour,

La gare cachée étant une problématique récurrente, je suis allé lire l'article sur le site Locduino.

Je trouve que l'approche n'est pas assez "généraliste". A titre d'exemple, on ne voit pas bien ce qui déclenche le départ de train. Vu de ma fenêtre, j'aurais tendance à dire que c'est la libération de "l'ILS Sortie" mais sa brève description semble indiquer le contraire.

Il est évident que ma conception n'est pas forcément celle de tout le monde. C'est pourquoi il faudrait commencer par définir les différents cas d'utilisation, puis ensuite les décliner avec des diagrammes de type état/transition ou des diagrammes de collaboration. Cette approche permettrait de recueillir des avis afin de construire un système plus versatile.

La modélisation devrait également faire apparaître que le nombre de voies n'est qu'une variable parmi d'autres, de façon à ce que la logique marche de deux à "N" voies.

L'ILS n'est qu'un des moyens de récupérer l'information d'occupation. Je pense que c'est donc une classe "SIGNALEUR", qui possède des sous-classes ILS, CONSOCOURRANT et BARRIEREIR (voir d'autres).

Une classe SIGNAL (avec des sous classes 2FEUX et 3FEUX) permettrait, de par leurs relations avec les classes AIGUILLAGE et OCCUPATIONVOIE, de les gérer et ainsi de pouvoir aussi gérer des gares non cachées.

Vola, c'est tout pour mes élucubrations du matin.

Ah si, dernier point, il est écrit : Pour arrêter les trains en gare, il est nécessaire de commander l’alimentation des locomotives. En analogique, on se contentera de couper l’alimentation des voies au moyen de 4 relais. En numérique cela nécessitera l’envoi d’information à la centrale via un bus comme XpressNET. Sauf si les normes DCC ont été réécrites cette nuit, c'est faux. La liaison centrale vers voie ne mets pas un éventuel bus à contribution.

Bonjour,

Le principe de la commande d'arrêt des trains n'est mentionnée dans l'article que pour mémoire, la commande réelle étant une problématique particulière, tant du coté analogique que numérique. L'auteur étant réalisateur en analogique ne voulait pas traiter exhaustivement le coté digital.

Moi, je développe en digital et je suis d'accord de toute façon qu'il faut envoyer des informations à la centrale pour qu'elle puisse connaitre l'adresse DCC de la loco à stopper.

Maintenant je dirai que l'ensemble détecteurs + centrale peut prendre de nombreuses formes selon les types de détecteurs et les types de centrale, y compris le superviseur ou gestionnaire de réseau.
Personnellement je développe moi-même le gestionnaire de mon réseau et j'y intègre un système de détection automatique des locos pour que le gestionnaire connaisse leur adresse DCC, à la fois pour le suivi des trains et pour leur transmettre la signalisation à respecter.

SixtyFive a écrit:

Bonjour,

Le principe de la commande d'arrêt des trains n'est mentionnée dans l'article que pour mémoire, la commande réelle étant une problématique particulière, tant du coté analogique que numérique. L'auteur étant réalisateur en analogique ne voulait pas traiter exhaustivement le coté digital.

Moi, je développe en digital et je suis d'accord de toute façon qu'il faut envoyer des informations à la centrale pour qu'elle puisse connaitre l'adresse DCC de la loco à stopper.

L'erreur sur le rôle du bus n'était qu'une information pour qu'éventuellement une correction du texte soit faite afin de ne pas laisser subsister des points qui suscitent des erreurs d'interprétation.

Le fond de mes remarques porte plus sur la modélisation qui me semble insuffisante pour spécifier un système réellement opérationnel. A moins que "arrêter un train" soit une méthode de la classe "Aiguillage" (ce dont je doute), on ne voit nul part comment le système fonctionne. Ce qui arrête les trains, ce qui les démarre, ....

C'est pour cela que je proposais de préciser les cas d'utilisation ainsi que de compléter le modèle de classe en conséquence. L’alimentation (en analogique), ou la centrale DCC sont à mon sens des classes, non ?

Bonjour,

C'est moi l'auteur.

Effectivement je ne rentre pas dans les détails du dialogue entre l'Arduino et la centrale. Mais il faut bien un moyen de communication entre l'Arduino et la centrale si l'on veut donner des ordres aux locomotives puisque c'est du ressort de la centrale. Si vous utilisez une centrale du commerce, ça sera un bus de type XPressNet. Si vous faites votre propre centrale, ça peut être ce que vous voulez, CAN par exemple. (en aparté à sierramike, le bus Centrale -> Locomotive, c'est pas le DCC ?   ). Que puis je préciser de plus pour ne pas laisser d'ambiguïté ?

Cet article est une introduction et le premier d'une série de 5 ou 6 articles (le 5e est en cours de rédaction). Il ne prétend donc pas tout dire d'un coup (notez le (1) à la fin du titre) et ne pose que le contexte. Par conséquent, les capteurs et les actionneurs seront traités plus tard dans les articles suivants. Il me semblait que c'était pourtant clair.

Concernant le coût de la POO, ça dépend de ce que l'on fait et notamment du langage. Le C++ est très peu gourmand car il n'y a pas de runtime et tout est traité statiquement à la compilation. La surcharge coûte un pointeur de fonction dans la vtable. L'héritage ne coûte rien. L'appel de méthode est un appel de fonction avec this comme premier argument implicite. L'appel de méthode virtuelle est un appel de fonction via un pointeur dans la vtable. Donc ça coûte marginalement plus cher que le C et il n'y a pas de consommation de mémoire additionnelle à chaque appel.

Salut jlb,

Oui c'est ce que je disais en fait, le DCC pour communiquer à la locomotive, et le bus est entre l'Arduino et la centrale, donc on est d'accords

Pour le coût des appels de fonctions, je me base sur mes expérimentations, où je voyais le coût en mémoire augmenter à l'appel d'une fonction externe par rapport au traitement dans la même fonction. En fait ça va surtout dépendre aussi de la quantité d'arguments que tu passes à la fonction, évidemment ...

Mais tu as totalement raison, tout est traité statiquement lors de la compilation donc le surcoût n'est pas aussi élevé que sur des langages type .NET.

JPGO a écrit:

sierramike a écrit:

1) Concernant le modèle de classes, c'est très bien, mais il ne faut pas oublier qu'on développe pour le l'embarqué, possiblement pour de petits Arduino Uno, la mémoire programme est limitée, la mémoire "RAM" l'est encore plus. La POO (Programmation Orientée Objet) avec surcharges et héritages impose un tas d'appels de fonctions l'une après l'autre, ce qui consomme de la RAM à chaque appel. Il vaut donc mieux éviter les diagrammes de classe trop étendus.

Pour l'instant, on parle de modèle logique, ce qui ne préjuge en rien du modèle physique.

Après, si on peut même pas monter une instance MySQL sur un Arduino, c'est une autre problématique...

Si ton modèle logique comprend une large hiérarchie de classes, tu vas avoir du mal à la convertir en procédural (cela dit je ne milite pas pour le procédural, loin de là !!!)

Je comprends la démarche de jlb et il faut le remercier pour toutes les informations mises à disposition de la communauté. Ca reste une démarche bénévole, pour faire partager la connaissance. On peut toujours faire mieux, plus, etc., mais tout ça a le mérite d'exister et permet d'en apprendre beaucoup. Le but c'est que chacun lise, comprenne, expérimente, et mette au point son propre système correspondant à ses besoins. On est dans la démarche pédagogique, pas de fournir un logiciel chiadé paramétrable en 3 clics de souris pour tout faire fonctionner. Ca, ça a un prix !

Alors quoi qu'on fasse, un cours sera toujours perfectible, les conseils c'est bien, mais moi je commence par remercier l'auteur pour le temps qu'il passe à rédiger tout ça !

sierramike a écrit:

Je comprends la démarche de jlb et il faut le remercier pour toutes les informations mises à disposition de la communauté. Ca reste une démarche bénévole, pour faire partager la connaissance. On peut toujours faire mieux, plus, etc., mais tout ça a le mérite d'exister et permet d'en apprendre beaucoup. Le but c'est que chacun lise, comprenne, expérimente, et mette au point son propre système correspondant à ses besoins. On est dans la démarche pédagogique, pas de fournir un logiciel chiadé paramétrable en 3 clics de souris pour tout faire fonctionner. Ca, ça a un prix !

Alors quoi qu'on fasse, un cours sera toujours perfectible, les conseils c'est bien, mais moi je commence par remercier l'auteur pour le temps qu'il passe à rédiger tout ça !

Tu as tout à fait compris la démarche sierramike