La gestion des cantons par Arduino !!

Tu vas dire que j'insiste, mais du point de vue câblage, tu aurais intérêt à décentraliser :

Avec 3 zones par canton + l'alim PWM, ça te fait 4 fils qui partent de la carte et vont vers la voie, par contre 2 seulement vont vers l'arduino (l'entrée analogique et la commande du PWM). Si tu développes 1 carte pour 12 cantons, c'est 48 fils qui partent vers les voies.

A ta place, je ferais une petite carte par canton que j'installerais au plus près physiquement de chaque canton, et il n'y aurait "que" 24 fils à tirer jusqu'à l'arduino.

Evidemment, sur un réseau compact de 3 m x 2 m, ça n'a guère d'importance, mais pour un réseau tour de pièce de 6 m x 5 m, ça vaut le coup d'y réfléchir.

Je me permets également de t'encourager à essayer de développer une autre fonctionnalité du block que je n'ai pas intégrée dans mon système à logique câblée : la gestion des rames réversibles avec loco en pousse.

En effet, avec une loco en pousse, dès que la voiture de tête entre dans le canton B, elle le met à l'occupation et par conséquent le canton A entre en procédure de ralentissement - arrêt, mais comme la loco s'y trouve encore, le train se piège lui-même...
Le même phénomène se produit pour les locos en UM ; la machine de tête piège la seconde. Les 2 locos étant très proches, j'ai pu résoudre ce problème par une simple temporisation d'une à 2 secondes, mais pour les rames réversibles de 5 voitures ou plus, on ne peut pas s'en sortir avec des tempos plus longues sous peine de transformer le block en passoire !
Seule une analyse séquentielle avec scénario approprié pour chaque cas de figure peut résoudre élégamment ce problème, et c'est typiquement là, plutôt que dans la logique combinatoire, que la souplesse des systèmes programmés présente un intérêt majeur par rapport aux systèmes câblés.

Pour ceux qui ne connaissent pas la terminologie :
- Logique combinatoire = Pour chaque combinaison des données d'entrée, il y a un seul état possible des données de sortie. On peut exprimer dans une "table de vérité" les états des sorties en face de chaque combinaison possible des entrées.
- Logique séquentielle = L'état des sorties ne dépend pas uniquement de la valeur des entrées, mais également de de qui s'est passé avant (notion de séquence).

Typiquement, le block 3 feux relève de la logique combinatoire. Par contre, la gestion de l'alimentation traction avec machine en pousse ne peut pas être traitée par la logique combinatoire et relève de la logique séquentielle.

DMARRION a écrit:

Si tu développes 1 carte pour 12 cantons, c'est 48 fils qui partent vers les voies.

Le "+" peut être commun, il n'y a que les "-" qui viennent à la carte. donc 36 fils pour 12 cantons.
Etant électricien de métier, j'ai trop l'habitude de "centraliser" ! Le tableau électrique d'une maison centralise toutes les protections. Et les raccordements, à la rigueur, on met des boites de dérivation. Mais pour le modélisme, j'aime avoir toutes les connexions au même endroit. De cette manière, lorsque je dois intervenir, je n'ai pas à me coucher partout sous le réseau ! Je sais que c'est "ici", c'est à dire là où j'ai mes cartes... Chacun à sa vision de la chose. Mais, si je veux que mon réseau participe à des expos plus tard, je pense que c'est plus simple d'avoir un câble par module relié à une centrale...

DMARRION a écrit:

la gestion des rames réversibles avec loco en pousse.
En effet, avec une loco en pousse, dès que la voiture de tête entre dans le canton B, elle le met à l'occupation et par conséquent le canton A entre en procédure de ralentissement - arrêt, mais comme la loco s'y trouve encore, le train se piège lui-même...

Mon système ne fonctionne pas du tout comme le tien. En fait, c'est uniquement lorsqu'un train entre dans la zone d'arrêt du canton "n" qu'il libère le canton "n-2" en le passant au feu "jaune". Le canton "n-1" sert de "tampon" car contrairement à la réalité, où le conducteur d'un train est capable de s'arrêter n'importe où s'il voit un train arrêté devant lui lorsqu'il est en ralentissement, en modélisme, on ne peut compter que sur le comportement "normal" de nos trains. Imaginons qu'un train franchisse le signal du canton "n", il commence donc à entrer dans le canton "n+1", si juste après ce moment, il stoppe pour une raison x ou y, que va-t-il se passer si le canton "n-1" a été placé au "jaune" ralentissement ? Eh bien, le train suiveur va lui rentrer dedans, car la rame (si elle n'est pas équipée de wagons consommant du courant) se trouve toujours sur le canton "n" et n'est pas détectée !!
C'est pour cela que je laisse un canton "tampon".

De ce fait, mon système fonctionne parfaitement pour les unités multiples, à 2, 3 ou 4 machines sans problème. Idem, pour les locos en pousse, ou les rames réversibles, je n'en ai pas pour tester, mais logiquement, ça ne pose aucun problème ! La seule condition à respecter, c'est que la rame la plus longue ne doit pas dépasser la longueur du plus petit canton !!
J'essayerai de faire un petit dessin pour vous montrer les différentes étapes de franchissement de cantons de mon système.

De même, je vous soumets une autre petite question, serait-il intéressant d'intégrer une régulation de vitesse ? (sachant que je peux mesurer le temps passé sur les zones à longueur fixe et donc connaitre la vitesse, je peux la réguler !!)

Oui, je pense qu'une régulation de vitesse serait un plus.

Sinon, bizarre cette histoire de canton tampon... Mais pourquoi pas. Evidemment sans cette astuce, si les wagons ne sont pas détectés, le block serait "une passoire" (j'aime bien cette expression).

Cela dit, je pense que ne pas graphiter les essieux de tous les wagons, c'est dommage. En effet, l'intérêt de la détection d'occupation ne se limite pas au cantonnement.

Quelques exemples :
- En zone de gare, c'est facile à utiliser pour sécuriser les itinéraires en empêchant la manœuvre d'un aiguillage lorsqu'au moins un essieu est détecté sur la zone où se trouve l'aiguillage.

- Pour actionner un passage à niveau, c'est bien plus simple (et plus fiable) qu'un système à ILS ou barrière optique. Il suffit de créer une zone géographiquement bornée par le point voulu pour l'origine de l'annonce du PN d'un coté, et le point voulu pour la libération du PN de l'autre, et ainsi la seule occupation de cette zone active le PN. Nul besoin d'enregistrer puis réarmer, pas de discordance possible donc pas de réinitialisation à prévoir, et surtout la barrière se relève juste après passage du dernier wagon quelque soit la longueur du train.

Bien sûr, ces dispositifs ne sont exploitables que si tous les wagons ont des essieux graphités.
Beaucoup n'osent pas le faire, pensant que c'est fastidieux, mais franchement, avec le bon produit ça va tout seul à faire et c'est très fiable : mes premiers wagons en N graphités au début des années 80 sont toujours détectés en 2016.

Je ne crois pas trop à la régulation de vitesse telle que tu la décris, car tu vas toujours agir à posteriori avec un décalage d'un canton ou d'une zone.

En revanche un asservissement de la vitesse avec mesure de la FCEM serait intéressant.

Favorable également au graphitage de tous les essieux, c'est facile et tellement sécurisant que cela ne vaut pas de s'en priver.

Mon système fonctionne essieux graphités ou non (au moins au niveau des distances; si un décrochage survient, là, effectivement seuls les wagons graphités seront protégés)

Pour la régulation, effectivement, j'agis après une mesure, mais comme j'ai 2 zones avec des distances fixes qui se suivent, on peut mesurer la première, agir et vérifier sur la deuxième, et ce dans chaque canton. Je ne pense pas pouvoir faire une "vraie" régulation, mais un système permettant par exemple de demander à ce que les trains roulent à 100 km/h à l'échelle, et que les trains roulent effectivement à une vitesse approchante...

Petit dessin illustrant l'ordre de mes cantons :

Je suis avec intérêt ton travail, c'est chouette, j'espère que tu participeras à Locoduino (ou que tu ouvriras un blog dédié) pour centraliser de bons articles bien "théoriques" !

Juste une question au milieu de vos questions de cantons et de feux, comment gères-tu l'inversion de marche ? J'ai l'impression que ton système est surtout prévu pour automatiser des circulations dans un seul sens, probablement bien pour automatiser une longue double voie dédiée, mais quid d'une voie unique ? Ou d'une double voie au milieu de laquelle il y aurait un embranchement particulier pour lequel on voudrait pouvoir faire des manoeuvres ? (ce n'est pas une critique, juste une question)

sierramike a écrit:

Je suis avec intérêt ton travail, c'est chouette, j'espère que tu participeras à Locoduino (ou que tu ouvriras un blog dédié) pour centraliser de bons articles bien "théoriques" !

Juste une question au milieu de vos questions de cantons et de feux, comment gères-tu l'inversion de marche ? J'ai l'impression que ton système est surtout prévu pour automatiser des circulations dans un seul sens, probablement bien pour automatiser une longue double voie dédiée, mais quid d'une voie unique ? Ou d'une double voie au milieu de laquelle il y aurait un embranchement particulier pour lequel on voudrait pouvoir faire des manœuvres ? (ce n'est pas une critique, juste une question)

Si je trouve la motivation, j'irai voir sur Locoduino...pour poster quelque chose...
Pour ce qui est de l'inversion du sens de marche, effectivement, mon système repose sur des circulations à sens unique, donc particulièrement des doubles voies avec sens de circulation normalisé.
Pour une voie unique, il faudrait que les zones soient doublées (au bout des cantons dans chaque sens) et il faudrait que le programme sache dans quel sens on circule... Il faudrait aussi prévoir un relais pour inverser la polarité des fils, commandé par l'arduino.
Pour les voies doubles avec des appareils de voies, je pense que tant que ces appareils ne se trouvent pas dans les zones "à risque" (c'est à dire les zones de mesure et d'arrêt), il doit y avoir moyen d'inverser le sens uniquement sur la partie concernée au niveau des rails directement. Si tu regardes mon schéma, si tu retournes le rail, la loco roulera dans le sens inverse, donc une inversion des fils au niveau du rail ne posera pas de problème. Là où ça posera un problème, c'est que tu vas faire entrer un train dans un canton en "plein milieu" et donc le changement des feux ne se fera pas correctement. La solution serait de "forcer" le canton que tu dois traverser à l'arrêt par le biais de la commande des appareils de voies...
Pas simple, effectivement, mais réalisable.
Ce que je vais faire, c'est que je vais noter quelque part, toutes vos remarques et questions, et dès que je pourrai, je ferai un plateau de test avec toutes ces éventualités pour bien les tester et les montrer !! C'est trés intéressant en tout cas... J'avais pensé à la gare qui pourrait se trouver dans la file des cantons mais pas avec des appareils de voie...

Tu as raison sierramike, le contresens n'est au départ pas possible en mode block automatique tel que le schéma est présenté.

Cependant :

- Dans la réalité, l'écrasante majorité des cantons de BAL est installée sur des doubles voies non banalisées. En modélisme, vu la compression des distances, c'est différent, mais sur un réseau tour de pièce important, il y a largement moyen de faire une double voie sur plusieurs cantons.

- Pour les manœuvres, par exemple pour desservir un embranchement, il faut s'inspirer de la réalité. En effet, pour desservir un embranchement, il y a un petit poste local qui permet de fermer le carré de protection en amont, puis de manœuvrer les aiguilles et permettre la desserte par refoulement.
Rien n'empêche de faire pareil : un relais peut à la fois basculer le canton concerné sur une alimentation "manuelle" et donner au block l'information d'occupation du canton afin d'assurer la protection de la manœuvre.

Reste le problème de la voie unique. Dans la réalité, une voie unique n'est pas exploitée en BAL, ou alors ce n'est plus de la VU, mais de la voie banalisée. Moyennant des commutations appropriées, il est toutefois possible de faire du cantonnement automatique dans les 2 sens. Dans ma gare, beaucoup d'itinéraires comportent des zones parcourues dans les 2 sens (dont les voies à quai, qui bénéficient d'un réglage individuel de sens et de vitesse), et la continuité du block est pourtant assurée. J'ai développé une carte spécifique pour ça, sur la même technologie de mes cartes BAL, afin d"être totalement compatible avec.
Nul doute qu'on pourrait aussi trouver une solution à base d'arduino.

Petite vidéo ZOOM sur l'arrêt et le démarrage progressif. La demande d'arrêt est faite par forçage (simulation présence sur canton précédent)
Essai réalisé avec une rame de 25 wagons (pour tester)

Est-ce que certains d'entre vous ont déjà "joué" avec les signaux PWM ? J'ai testé différentes fréquences et je trouve des vitesses de roulement différentes... Je ne me l'explique pas...

Je pense que si tu changes la durée de l'impulsion ou la fréquence de cette impulsion, ca change la valeur de la tension moyenne équivalente.
Mais je suis pas spécialiste

Oui Michel, mais pour un même signal (disons 25% à 1 et 75% à 0) tu peux demander à ce que ce signal se fasse à 490 Hertz ou à 3000 Hertz par exemple. La valeur moyenne reste la même mais cependant, je constate des vitesses différentes...

Es tu sur que la valeur moyenne reste la même?

Si tu alimente une résistance c'est le cas en théorie

Sur un moteur qui est une charge inductive c'est différent le courant s'annule aprés l'annulation de la tension (d'où la diode de roue libre)

à basse fréquence le cycle est constitué:
T1: temps sous tension (transistor fermé)
T2: phase de roue libre tension nulle mais courant non nul.
T3: Tension égale à la fem du moteur (proportionnelle à sa vitesse)

à plus haute fréquence la période du cycle étant plus courte le courant n'a pas le temps de s'annuler, on appelle ce cas la conduction continue.
Il n'y a plus que les phases T1 et T2

Pas facile d'être clair en quelques lignes si j'arrive à retrouver une doc simple avec des illustrations des signaux je te la met de coté (mais je ne te promet rien)

J'ai trouvé cet article : http://modelleisenbahn.triskell.org/spip.php?article44
C'est très clair... mais je trouve quand même les différences de vitesse bizarres...
Je vais refaire quelques essais et mesures...

Prometteur ! Mais ta PWM a une fréquence trop basse, elle fait "chanter" le moteur.

Le courant pulsé fait toujours chanter les moteurs, sauf lorsque la vitesse est élevée (rapport cyclique presque égal à l'infini). Ils chantent aussi lorsque la fréquence est plus élevée, mais ça tient plus du sifflement que du grognement et ça semble sans doute moins inquiétant.

Il existe un autre problème avec le courant pulsé. Tout le monde a déjà entendu parler des moteurs à rotor sans fer qui n'aiment pas du tout les courants pulsés à basse fréquence, mais il n'y a pas que les rotors sans fer qui sont concernés. Pour faire simple :

- La conduction discontinue donne un meilleur ralenti que la conduction continue, et ce d'autant plus que la fréquence est basse.
En effet, avec une fréquence basse, l'effort moteur n'est pas constant mais saccadé et c'est très efficace pour "décoller" la mécanique. Pour prendre un exemple, lorsqu'on construit un mur, c'est plus facile de positionner avec précision un parpaing en lui donnant des petits coups répétés qu'en essayant de le déplacer avec une force constante.

Mais malheureusement :
- Le couple moteur est peu ou prou proportionnel au courant moyen qui traverse le moteur, tandis que l'échauffement du moteur est proportionnel au carré de la valeur efficace du courant qui le traverse. Ce point n'est pas favorable à la conduction discontinue, où le moteur chauffe plus que pour un couple équivalent en conduction continue.
Quand il s'agit d'un moteur assez gros avec une certaine masse (HO ou plus), ce n'est pas très grave car les calories se dissipent assez facilement, mais dans nos petits moteurs à l'échelle N, le bobinage est très fin et peut griller rapidement.

C'est tout le dilemme du comportement de nos petits moteurs avec le courant pulsé : Meilleur ralenti mais risque de surchauffe, ou pas de risque de surchauffe mais ralenti pas franchement meilleur qu'en continu lisse.

A défaut d'une amélioration sensible du ralenti, l'emploi d'une PWM à fréquence élevée présente tout de même quelques avantages par rapport au continu lisse :
- Les LED s'éclairent pour un rapport cyclique même très faible, ce qui permet de garder les phares et l'éclairage des voitures même aux très basses vitesses
- On s'affranchit du "seuil électrique" sur les locos trop rapides qu'on a "calmé" avec des diodes zeners

C'est les conclusions auxquelles j'étais arrivé après mes essais d'adaptation de mes cartes BAL à la PWM.

Je vais apporter un peu d'eau au moulin. Après quelques essais, voici ce que j'ai pu remarquer :
Avec une fréquence de signal de 490 Hz ou 3900 Hz, les locos fonctionnent parfaitement bien, avec un léger mieux en 490 Hz pour les ralentis. Mais, avec ces deux fréquences, on perçoit un sifflement grave pour 490 et aigu pour 3900 Hz qui est assez insupportable !
De, plus, à la fréquence de 3900 Hz, mes locos roulent moins vite, quelque soit la loco d'ailleurs pour une même consigne !!??
J'ai essayé ensuite une fréquence de 31000 Hz, et là, quasi impossible d'avoir un ralenti... Démarrage immédiat sans progression possible ! Pire, avec la Piko 25500, elle roule quasiment tout le temps à fond, même avec une consigne très basse !!!
Dernier essai, je suis descendu à 120 Hz, là, ralenti super impressionnant, pas de sifflement, pas de grognement, toutes les locos marchent nickel, je n'ai pas constaté d'échauffement particulier... C'est à cette fréquence que j'ai les meilleurs résultats, en ralenti, en vitesse, en bruit...
Je vais rester à cette fréquence pour faire un essai en laissant le ralenti assez longtemps et surveiller l'échauffement, pour voir...

Driving Railway de feu Pegase fonctionne aux alentours de ces fréquences, de mémoire (environ 100Hz, faudrait que je replonge dans la doc pour avoir la valeur exacte....).
Je ne constate en tout cas aucun grognement/ sifflement ou échauffement des moteurs.

Salut,

Je suppose qu'en analogique il y a un filtre (self + condo) on a donc un effet de filtrage qui expliquerait ton observation.

A+
Yves

Bonsoir à tous,
Après quelques mois de silence, je reviens ! On ne peut pas être partout à la fois !
J'apporte deux trois infos sur l'utilisation que je fais de l'arduino mega.
Ok il parait suffisant en terme d'E/S. Enfin au début ! 54 E/S au total ça fait court après quelques mois de conception, développement, utilisation ! Je me suis fait avoir ! C'est pas grave, il faut juste revoir un peu la conception technique (utilisation de mux pour la pwm (tlc5940) ou pour le e/s interrupteurs (mcp23017) ) et la programmation ...
Mais bon c'est notre passe temps. On prend le rôle de Pénélope : faire et défaire !
Bonne soirée
Alain

J'ajoute ;
Pas mal l'idée d'un canton de longueur fixe pour calculer la vitesse, donc la pente de décélération.
Le paramétrage de la longueur de la zone plein voie dans un tableau / structure de tableau pour chaque canton et l'utiliser dans le calcul serait plus "portable". Cela évite une zone de détection supplémentaire et de la câblerie !
C'est comme ça que j'essaie de calculer cette fumeuse/fameuse pente avec tous les inconvénients que cela à !
Alors j'explore, en brasse coulée, une autre piste pour calculer cette pente : à quel voltage/tension/ratio (j'utilise des L298) le convoi s’arrête/démarre/atteint sa vitesse maxi ? Pour cela il est nécessaire de calculer sa consommation ! Un peu comme un lave linge qui fait quelques tours pour peser le linge ! Comme j'utilise des L298, avec les pins "sens" quelques résistances et hop cela est fait ... euh doit être ... facile !!!! C'est pas compliqué, c'est pas facile !
A oui mais comme la voie monte, descend, est à plat, il faut capter partout ! Eh ben il faut multiplexer encore une fois ! (54 E/S ...)
M'enfin si on arrive à trouver la relation poids / intensité / tension / distance / inertie / moteur , quel pied !
Ben, bonnes réflexions et nœuds au cerveau et belles soirées !
A+

Alain

Les difficultés que vous rencontrez viennent du principe utilisé : vous partez d'une mesure de la vitesse entre 2 points fixes. Cette mesure vous donne bien une information fiable (la vitesse du train pour X volts à la voie), mais ne vous donne pas le comportement de ce même train pour une autre tension à la voie, vous êtes donc obligés d'extrapoler en faisant des suppositions sur la loi de variation du comportement du train selon la tension. Nous sommes donc dans la recherche du compromis qui ira à peu près.

Je pense que la clé est de ne pas se référer à une courbe de décélération de type Tension / Temps, mais à une courbe intégrant 3 paramètres : Tension / Vitesse / Distance.

Ceci implique une autre façon d'asservir la tension PWM, il ne faut pas l'asservir uniquement à la vitesse mesurée en un point, mais à la vitesse mesurée en tout point de la zone de décélération-arrêt.

Si je voulais pondre un système pour assurer une décélération douce avec arrêt toujours au même endroit, j'utiliserais un radar et j'asservirais la tension à la voie à une courbe de décélération type vitesse/distance en comparaison de la mesure en temps réel du radar.

En effet, le radar est capable de fournir instantanément à la fois la vitesse réelle et la distance qui reste à parcourir. C'est la seule solution qui me vienne à l'esprit pour être totalement indépendant de tous les paramètres du type "qualité du ralenti de la loco, vitesse de pointe de la loco, inertie de le rame, rampe ou déclivité..."

Je vois alain90 que nous tombons sur les mêmes problèmes !
Petite précision sur ton idée d'entrer "en dur" dans le programme les longueurs des différents cantons : Oui dans l'absolu, mais je veux que mon programme fonctionne pour n'importe quel réseau, et donc le programme ne peut pas être modifié à souhait. Il doit se "débrouiller".
Par ailleurs, je pense avoir trouvé une solution "alternative", qui pourrait marcher et qui n'a pas besoin de mesure de vitesse ou quoique ce soit d'autre...
Je fais quelques essais pour vérifier la théorie et si ça fonctionne bien, je vous livrerai mon secret !!!
D'ailleurs, je vais en profiter pour ajouter une petite modification qui va permettre au programme de savoir "tout seul" combien de cantons sont utilisés !!
A+

Bonjour Michael,
Si tu veux que le programme fonctionne pour n'importe quel réseau, il faut une sacré dose d'intelligence pour le programme. Comment est elle apportée au programme ? Par des capteurs ou équivalent ? ou par du paramétrage ? ou par ... ?
De mon coté, j'ai choisi le paramétrage pour coder en dur les valeurs quasi immuable pour mon réseau (canton précédent, suivant, aiguillage, longueur, port pwm ...), idem pour tous les capteurs pour lesquels je joue avec l'indirection (pointeur). C'est la souplesse du code qui permer à peu de frais (temps) d'ajouter des cantons, de modifier mes hub de capteurs ...

Dominique, je suis d'accord avec toi pour les trois paramètres Tension / Vitesse / Distance ( E=VT !) et encore plus pour le radar qui répond parfaitement à notre questionnement : tu es où, à quelle vitesse, combien te reste t il à parcourir jusqu'au signal ... dans un canton de pleine voie ...
car si aujourd'hui c'est s'arrêter au plus près du signal sans le dépasser qui nous intéresse, savez vous arrêter un convoi au milieu (à peu près ) d'une gare et ce quelque soit la longueur du convoi ? Un radar devant, un radar derrière (il faut bien connaître la longueur du convoi !) ...
Avant d'avoir ce système à l'échelle de nos réseaux et à un coût modéré, pour les voies de la gare j'ai "saucissonner" le canton, en fonction des convois susceptibles de s'arrêter. Avec les capteurs, les segments occupés sont connus donc la longueur du convoi (enfin à peu près) et donc le segment d'arrêt est connu (à peu près) !
A peu près ! Mais dans la vraie vie qui n'a pas râlé quand un corail de 8 voitures s'arrête au pied du signal de sortie de gare et que le quai est prévu pour 16 voitures !!!!
Bonne journée

Alain

alain90 a écrit:

.../... dans la vraie vie qui n'a pas râlé quand un corail de 8 voitures s'arrête au pied du signal de sortie de gare et que le quai est prévu pour 16 voitures !!!!

En principe, sur les quais il y a des pancartes qui indiquent aux conducteurs le point d'arrêt souhaité en fonction de la longueur habituelle des trains (par exemple pour 6 voitures : Pancarte "6V"), ou "TGV1" et "TGV2" suivant qu'il s'agit d'une rame simple ou d'une UM de TGV.