Arduino - Bloc automatique

[Ramboman]

Beau travail Michael... une question cependant, tu écris : "les cantons doivent mesurer au minimum la longueur du plus grand convoi à faire circuler + 25 cm pour les zones de fin de canton"... est-ce que c'est impératif, ou peux-tu gérer un train à cheval sur deux cantons ?

[Nicozea57]

Merci Ramboman,

Pour ta question, je dirais, ça dépend!

Si les wagons du convoi sont graphités (ou au moins le dernier), c'est impératif, car le fait qu'une loco arrive dans la zone de freinage du canton N, nécessite que le canton précédent soit libre, sinon le système va déduire qu'un ou plusieurs wagons se sont décrochés, et signaler un défaut, en gardant les cantons précédents au "rouge"... au moins jusqu'à ce que les wagons détectés sortent...
Si les wagons ne sont pas consommateur de courant et donc non détectés, alors, ça ne pose aucun problème !
Mais, je suis en train de faire des tests plus "poussés" pour voir justement si cela pose réellement un problème au système d'avoir un convoi plus long que le canton...
Je te repréciserai dès que j'en aurai la certitude...

[Arduino]

Pour avoir suivi le projet depuis le début sur le forum du N, le projet de Nicozea57 est beaucoup plus abouti que tout ce qui a pu être étudié avant.
...
Y'a pas à dire, quand on prend les problèmes dans le bon sens....

Je n'ai aucun intérêts dans l'affaire, mais quand on voit un truc bien né et aussi riche fonctionnellement, autant le faire savoir.

Mon cher JPGO,

Les buts poursuivis par Nicozea57 et moi n'ont jamais été les mêmes, lui développe son propre système et y consacre tout son temps, moi mon but était de faire cogiter ceux qui suivaient mon cours d'électronique programmable sur un B.A.L qui se devait de rester simple pour que des débutants puissent arriver au bout sans se décourager.

J'ai lu le cahier des charges du B.A.L de Michael ; c'est un projet ambitieux et le résultat actuel vu en vidéo ne permet pas de conclure que tout fonctionne déjà (UM, train en pousse, etc.) car comme le dit Michael, cela devient vite compliqué et il a encore des problèmes de mise au point (voir sa réponse à Ramboman). Mais au moins, il a attaqué le problème et je suis persuadé qu'il en viendra à bout petit à petit, et que nous pourrons débattre (en toute amitié) des solutions adoptées.

Quant à ta réflexion sur la prise du problème dans le bon sens, elle me fait plutôt rire de la part de quelqu'un qui n'a jamais rien conçu par lui-même et qui ne comprend pas la philosophie du DIY alors que tout existe dans le commerce... Comme toujours, la critique est facile mais l'art est difficile.

Bien cordialement.

[Arduino]

Beau travail Michael... une question cependant, tu écris : "les cantons doivent mesurer au minimum la longueur du plus grand convoi à faire circuler + 25 cm pour les zones de fin de canton"... est-ce que c'est impératif, ou peux-tu gérer un train à cheval sur deux cantons ?

Quelle que soit la longueur qu'on donne à ses cantons, il y aura toujours un moment où le train est à cheval sur deux cantons et c'est bien là une des grandes difficultés du B.A.L. Cette difficulté est pire si on veut faire circuler des trains en pousse, où l'engin moteur à arrêter est à l'arrière du train dont il faut connaître la longueur si on veut que la tête s'arrête au pied du signal. Le système doit donc s'inspirer de ce que sont capables de faire les logiciels de circulation de trains, en prenant en compte vitesse, accélération, longueur de convois, longueurs de cantons etc.

Cela devient très vite compliqué, mais c'est réalisable puisque ces logiciels le font. Pour ma part, je pense qu'un débutant peut déjà se faire plaisir à concevoir un B.A.L beaucoup plus simple puis à l'améliorer au fil du temps en lui faisant faire de plus en plus de fonctionnalités. Les B.A.L de Chennevez à partir de simples relais ont su nous émerveiller à une certaine époque, avec l'informatique en plus, on ne peut que faire mieux. Mais cela demande du temps à y consacrer...

[JPGO]

Quant à ta réflexion sur la prise du problème dans le bon sens, elle me fait plutôt rire de la part de quelqu'un qui n'a jamais rien conçu par lui-même et qui ne comprend pas la philosophie du DIY alors que tout existe dans le commerce... Comme toujours, la critique est facile mais l'art est difficile.
Bien cordialement.

Ayant appris le Fortran 66 et le Cobol en 1974 et ayant encadré quelques centaines de concepteurs, développeurs, testeurs et chefs de projets durant mes 30 ans de direction de projet puis de programme, voyant passer les projets du mainframe au client-serveur pour finir par les web services (après j'étais en retraite) j'ai acquis une petite expérience quant au cycle de vie des applications, mais bon, certainement pas à ton niveau.

Malgré mes lacunes, j'ai suivi avec plaisir l'avancée des travaux de Nicozea57 et réussi à me faire mon opinion.

A propos de ce projet, je m'étonne que tu ne fasses que relever les difficultés de mise au point. Remarque que ce n'est pas une première sur les forums, ou certains présentent des technos plus pour frimer que pour partager. Leur jalousie fait craquer la carapace dès qu'un participant semble en connaître plus qu'eux....

[Arduino]

A propos de ce projet, je m'étonne que tu ne fasses que relever les difficultés de mise au point. Remarque que ce n'est pas une première sur les forums, ou certains présentent des technos plus pour frimer que pour partager. Leur jalousie fait craquer la carapace dès qu'un participant semble en connaître plus qu'eux....

Une fois de plus tu t'égares complètement !

La plupart de mes posts en Arduino sont livrés avec schéma de montage et programme fonctionnel ; si ce n'est pas du partage, qu'est-ce c'est ?

Mon cours d'électronique classique et mon cours d'électronique programmable, si ce n'est pas du partage, qu'est-ce c'est ?

Mes fiches pratiques et mes articles sur LR, si ce n'est pas du partage, qu'est-ce c'est ?

J'ai été le premier à affirmer, souvent critiqué par toi d'ailleurs, qu'Arduino pouvait faire beaucoup de choses sur un réseau de trains miniatures. Je me cantonne à des réalisations simples pour que les débutants puissent faire de même, alors où est la frime ?

Tu passes ton temps à faire état de tes années glorieuses de salarié (dont on se fout complètement d'ailleurs, et là c'est bien toi qui frime !) et à écrire des posts (souvent conspués par la communauté comme tes dernières interventions sur l'impression 3D) mais toujours pour critiquer, voire délirer comme la fois où tu as écrit que j'avais besoin d'un psy (retiré par la modération) simplement parce que je crois au train à énergie embarquée (voir à ce sujet le dernier HS LR article de Gesuelli).

Je pense simplement que parfois, tu ferais mieux de t'abstenir sur certaines de tes interventions car tu n'as pas grand chose à apporter de toi-même. Rajoutes en une couche si tu veux, je n'y répondrai plus ; tout le monde sait qu'on ne se porte pas dans nos cœurs, mais s'ils ont bien suivi, ils savent aussi pourquoi.

[Nicozea57]

Messieurs, pourquoi prenez vous les remarques comme des attaques ?
Un forum est un lieu de partage, que ce soit de connaissances, de recherches, de découvertes, de passion ou d'envie...
Personnellement, je ne m'inscris pas sur un forum pour venir "critiquer" ou faire des remarques désobligeantes...

Bref, si je viens parler de mon système, c'est pour le faire connaitre et pour avoir des avis de passionnés de modélisme comme moi, afin de mettre au point un système qui s'adaptera à des réseaux autres que le mien !!

Cela étant dit, je vous demanderai, autant qu'il se peut, de répondre à mes messages uniquement si cela concerne le BAL automatisé, pas pour vous chamailler !!

Pour arduino : mon système fonctionne parfaitement bien, même quand un train est "à cheval". Le problème qui se pose vient des conditions nécessaires à la libération d'un canton.
Quelles sont-elles ? Pour ma part, j'ai décidé que pour libérer un canton, il faut qu'il soit libre, c'est à dire qu'aucune détection ne soit faite dessus.
Ca parait simple, mais, si une locomotive vient à perdre le contact sur un canton, et que les wagons qu'elle tracte ne sont pas graphités, le canton, aux yeux du système est libre... hors, il ne l'est pas du tout.
C'est pour cela que j'ai mis en place la libération d'un canton uniquement si le train est détecté sur le canton suivant, mais dans la zone de freinage, qui se trouve au bout du canton. De cette manière, si le train se trouve dans cette zone, cela veut dire qu'il a bien quitté le canton précédent, et seulement maintenant, le système peut le libérer.
Je ne sais pas si mes explications sont claires, mais il y a un schéma explicant cela sur le Fdn.

Bien à vous, et soyez sages !

[Ramboman]

En m'inspirant comme beaucoup de chenevez, j'ai formulé mon projet de la manière suivante :
1. à un moment donné le train se trouve sur un canton "virtuel" constitué d'un ensemble de cantons physiques successifs, en tenant compte de la position des aiguilles... la commutation des cantons par relais décrite par chenevez convient parfaitement... le DCC est inutile... le positionnement du train est connu avec suffisamment de précision grâce à une détection appropriée.
2. la vitesse du train est contrôlée en fonction de la consigne et de la signalisation... la notion de "bal" est étendue à l'ensemble de la signalisation.
3. les cantons successifs sont alloués de manière dynamique au fur et à mesure de l'avancement du train... encore chenevez...
4. les itinéraires en transit sont protégés.
Vu comme ça, c'est assez facile à réaliser...
mais il y a moyen de rêver de faire beaucoup plus compliqué...

[JPGO]

Cela étant dit, je vous demanderai, autant qu'il se peut, de répondre à mes messages uniquement si cela concerne le BAL automatisé,

De mon point de vue, je trouve que l'idée de gérer les gares n'est pas aussi pertinente que la première partie du projet qui consiste à gérer le BAL.

Je m'explique: dans les faits, quand on gère un réseau de manière " automatisée" (par le logiciel RRTC dans mon cas) la notion de gare n'existe pas. Une gare, c'est un ensemble de canton participant à des itinéraires. Par exemple, un omnibus va s'arrêter en gare pour laisser passer un rapide. Dans d'autre cas, c'est simplement le canton de départ ou d'arrivée d'un trajet. On peut avoir envie que le train finisse obligatoirement sur le quai n°1 ou avoir envie qu'il s'arrête sur une des voies libres, et ça en fonction des rames. Faire du LIFO (par exemple) n'est pas du tout le cas général.

Tout cela pour dire qu'il y a une multitude de cas possibles en fonction de la manière de "jouer". Pas facile d'établir des specs couvrant tous les cas de figures et encore moins d'établir un modèle de paramétrage les implémentant.

Une version 1 finalisée, documentée et paramétrable du BAL serait déjà un truc de la mort qui tue.

Ce n'est bien évidemment que mon avis.

[Nicozea57]

Je ne veux automatiser que les gares cachées. Les gares visibles seront gérées manuellement afin d'envoyer le train sur la voie voulue justement !
Mais, jusqu'à présent, je ne connais pas de système de BAL qui permette d'inclure des voies de gares afin d'y stocker des trains "en attente". Ni même qui gère les gares cachées automatiquement...
Coupler le BAL à un système de gestions de trains garés permet d'augmenter le plaisir du jeu (avec plus de convois différents) en gardant toujours la sécurité sur le circuit, comme la réalité quoi...

[Ramboman]

comme la réalité quoi...

J'ai l'impression que l'on mélange tout... en bon informaticien, on commence par définir le projet... dans notre cas, lgperrin démarre avec le "bal"... qui est généralement en pleine voie si je ne me trompe... puis on passe à "rrtc"... ce qui sort totalement de l'épure... en tout cas de ce fil ci... revenons svp sur terre... en réalité... chaque train a (en général) un conducteur

[JPGO]

Je ne veux automatiser que les gares cachées. Les gares visibles seront gérées manuellement afin d'envoyer le train sur la voie voulue justement !

Toujours "vu de ma fenêtre" (avis non forcément partagé) la notion de gare cachée est une notion de décor, c'est à dire que sa seule spécificité c'est qu'on ne la voit pas. Cela n'a pas de rapport avec l'exploitation du réseau: on peut par exemple choisir qu'un omnibus fasse trois fois le tour du réseau avant qu'un TGV ne parte de la dite gare cachée. Il existe une multitude de logique de libération des rames.
Je répète que ce n'est pas une critique, mais une contribution pour faire avancer le schimilibilic.

Il serait peut-être d'ailleurs intéressant de traiter de cette problématique dans un post distinct, pour éviter les amalgames (voir au dessus).

[Arduino]

...
Mais, jusqu'à présent, je ne connais pas de système de BAL qui permette d'inclure des voies de gares afin d'y stocker des trains "en attente". Ni même qui gère les gares cachées automatiquement...
...

Bonjour Michael,

A mon avis, B.A.L et gestion de gare cachée sont deux choses différentes.

Il y a eu un fil concernant la gestion d'une gare cachée où trois solutions ont été apportées à Gachone49 qui en avait fait la demande :
- cc7001 préconisait un système de programmation industriel, solution qui a finalement été adoptée par Gachone49.
- je préconisais un système à base d'Arduino et j'en avais démontré la faisabilité pour deux voies (mais c'est la même chose pour 4)
- 66666 a publié un schéma simple à base de relais bistables parfaitement viable également.
J'ai écrit dernièrement à Gachone49 pour savoir s'il avait réussi à mettre en oeuvre la solution qu'il avait choisie mais je n'ai hélas eu aucune réponse.
Depuis, d'autres choses ont été mises en place pour la gestion de gare cachée, notamment sur le site locoduino.

Pour le B.A.L, sujet de ce fil, comme je l'ai dit, la solution que j'ai développée, bien moins complète que la tienne, fait intervenir des ILS pour détecter les trains, au lieu de détecteurs d'occupation. Sinon, je suis sur la même longueur d'onde que toi : la zone d'arrêt située en bout de canton n'est alimentée que si le canton suivant est non occupé. Je ne gère pas le démarrage et l'arrêt progressif, encore qu'avec la PWM d'Arduino à fréquence élevée, ce n'est pas difficile de la rajouter.

L'avantage de mon système par ILS est sa simplicité pour Arduino (ovale de 4 cantons tient sur un Arduino UNO en nombre de sorties). Son inconvénient est qu'il faut des trains très courts pour rester crédible (ou des cantons très très longs). Je ne sais pas détecter sur deux cantons, et il n'y a qu'un seul sens de circulation.

Cette approche simplifiée devait permettre de faire travailler des débutants en Arduino sur ce concept. Je ne voulais pas les assommer avec un cahier des charges trop compliqué. Hélas, je n'ai pas pu entretenir la dynamique car occupé à d'autres choses et je viens seulement de reprendre le défi pour trouver une solution (primitive).

Ton B.A.L permet-il de circuler dans les deux sens ? Permet-il les trains en pousse ? Enfin, n'aurait-il pas mieux valu mesurer la vitesse en début de canton pour avoir de l'espace pour le faire décélérer si nécessaire et arriver sur la zone d'arrêt à très petite vitesse ? Je pense que le mieux serait que je reprenne ton fil sur FdN pour comprendre tes choix, car ils sont sans doute expliqués au fur et à mesure. Ce que je vais faire, mais cela demande un peu de temps.

Au plaisir de te relire.

Christian

[Nicozea57]

Pour les gares cachées, effectivement, il existe des solutions diverses et variées, il y a déjà des fils la-dessus, mais elle ne rentre pas dans un système BAL de manière incorporée... C'est pour ça que je le spécifie pour mon système, qui sera capable de les gérer à l'intérieur des cantons. Mais je pourrai faire un fil pour ce sujet, c'est vrai.

Pour le BAL, mon système ne permet pas la circulation dans les 2 sens, car, il s'applique à de la pleine voie qui est donc à sens unique (deux voies, une dans chaque sens).
Il marche très bien avec les loco en pousse, également pour la double ou triple traction !
Pour ce qui est des ralentissements et accélération, elles se font sur un canton entier. La vitesse que je mesure ne sert que d'indicateur.
Pour le ralentissement, il est provoqué par le passage devant un feu jaune, et le train va ralentir sur toute la longueur du canton suivant jusqu'à arriver devant le feu rouge. Pour l'accélération, c'est un facteur d'accélération qui est appliqué, et cette dernière peut s'étaler sur plusieurs cantons.

Pour revenir sur le fait d'accélérer ou de ralentir, ce n'est pas si simple que ça, même avec la PWM. C'est sûr que faire varier le signal est simple, mais savoir dans quel état se trouve chaque canton est une autre paire de manches. Car, si un train est en train de ralentir et que le feu repasse au vert, il doit repartir en accélération mais depuis la consigne où il se trouvait... Et c'est là que les choses commencent à se corser un peu ! Car le programme doit savoir en permanence la consigne des trains, l'état de chaque canton et comment il doit mixer les deux pour que les trains n'aient pas d'à-coups !

Bref, pas si simple.

Je pense que le Do it yourself amène vite ses limites quand il faut faire de l’électronique, ou de la programmation. Tout le monde n'a pas l'esprit assez logique pour y arriver, et surtout le temps de s'y plonger.
C'est pour cela que je pense qu'un système comme le mien pourrait amener à certains modélistes les possibilités de "jouer" réellement avec leur réseau, plutôt que d'être limité à gérer 2 ou 3 trains en même temps sans plus...
Ce n'est pas une critique, mais une constatation.
J'ai réaliser un réseau de 40m² avec mon père, et nous avons été confronté au problème de pouvoir faire rouler plusieurs trains sans se "prendre la tête" et perdre très vite les commandes...
C'est du vécu, c'est pour cela que je fais ce système, c'est pour que TOUS les modélistes puissent faire vivre leur réseau comme ils l'entendent, sans être frustré de ne pouvoir faire comme il le voudrait...
Même en digital, gérer plus de 3 trains quand on a pas mis en place d'automatisation est vite complexe...
Mais c'est mon avis !

[Arduino]

Merci pour toutes ces précisions. Comme tu le dis, cela n'est pas simple. Ainsi, si tu veux ne pas avoir d'à coups d'un canton à l'autre, il faut que les PWM soient synchronisées, donc pas simple non plus.

Je pense que le Do it yourself amène vite ses limites quand il faut faire de l’électronique, ou de la programmation. Tout le monde n'a pas l'esprit assez logique pour y arriver, et surtout le temps de s'y plonger.

Le Do It Yourself est un peu une démarche intellectuelle, une sorte de défi qu'on se lance. Pour y consacrer du temps, il faut que cela plaise de se lancer des défis. Mais quelle satisfaction que d'arriver au résultat, même si celui-ci est moins complet que ce qu'on peut trouver dans le commerce. J'y vois un autre avantage : la maintenance qu'on est capable d'assurer quand on a conçu un système soi-même.

Il marche très bien avec les loco en pousse, également pour la double ou triple traction !

Alors, tu es très en avance sur moi et j'aimerais comprendre comment cela fonctionne. Aurais-tu une vidéo qui le montre, toi qui en as fait pas mal ? Est-ce que la tête du train s'arrête bien devant le signal au rouge ? (Mon système ne le permet absolument pas car le premier wagon entrerait dans le canton, ce qui couperait l'alimentation sur la zone d'arrêt du canton précédent, et donc arrêterait la loco dès qu'elle y arriverait, bloquant complètement le système).