BALA2BAL (Bal à 2 balles)

J'en ai rêvé . . . mais pas (encore) fait  . . .

http://yves.monmagnon.pagesperso-orange.fr/TRAIN/Bala2Bal/Présentation.pdf

Merci d'avance pour vos critiques et suggestions.

Bonjour
Je viens de lire. Bon travail d'analyse l'idée de la détection de la FEM parait interessante.

Par contre je n'ai pas compris comment sont gérés les feux jaunes de ralentissement dans ton algo.
Derf

Bonjour Yves07

Ton projet est particulièrement intéressant et je vais le suivre de près ...
Tu envisages à ce stade d'utiliser l'ensemble des broches de l'Attiny85. Si au cours de ton étude tu avais besoin de plus d'E/S, tu peux alors envisager son grand frère : l'Attiny84 (12 E/S). Présentation ici

Bonne continuation à toi

Très intéressant tout cela. Merci beaucoup.

Derf a écrit:

Bonjour . . .
Par contre je n'ai pas compris comment sont gérés les feux jaunes de ralentissement dans ton algo.

Bien vu . . . j'ai oublié
Pourtant j'avais trouvé comment raccorder les trois leds sur deux fils sans rien ajouter d'autre !
Un "fake" en mettant un temps jaune entre rouge et vert ?

Fantasio a écrit:

. . .
Ton projet est particulièrement intéressant et je vais le suivre de près ...
Tu envisages à ce stade d'utiliser l'ensemble des broches de l'Attiny85. Si au cours de ton étude tu avais besoin de plus d'E/S, tu peux alors envisager son grand frère : l'Attiny84 (12 E/S). Présentation ici

Merci, mais ça fait 6 soudures en plus
Je suis plus inquiet pour la taille du code, j'ai déjà programmé des PIC en assembleur qui ont, me semble t'il, le même jeu d'instructions. Pourtant l'outil Processing est plus facile à utiliser si il ne fait pas trop gonfler le programme.
Et puis ça fait partie du jeu

Je viens de voir ton sujet et de lire l'article en suivant le lien.
Tout d'abord je te remercie de m'avoir cité comme "source d'inspiration" pour le BAL. Ensuite, je te félicite de te lancer dans ce défi : un BAL avec contrôle des signaux et de la vitesse à bas prix de revient.
Je pense qu'il faudra mettre au bout du compte un peu plus de 2€ par canton, tu as sans doute bien dégrossi le problème mais lorsqu'arrivera le temps des prototypes et des essais, il est fort probable que tu rencontreras des petites difficultés auxquelles tu n'as pas encore pensé. Certains de ces problèmes trouveront une solution logicielle (donc sans augmentation du cout), mais je ne serais pas surpris qu'il y en ait qui demandent quelques composants supplémentaires.
Clairement, si tu remplis toutes les fonctionnalités pour moins de 10€ le canton, ce sera une belle victoire.

Je profite de ce post pour revenir sur la notion de canton, je pense qu'elle est mal comprise par la plupart des modélistes qui confondent souvent cantons et zones isolées, et quand tu dis qu'il te faut 12 cantons pour un réseau qui tient sur 2m², ça me conforte dans cette idée.

- Un canton est lié à l'espacement des trains, et doit être assez long pour être réaliste, il faut qu'un train puisse y décélérer tranquillement, stabiliser sa vitesse d'approche et venir s'arrêter devant le signal. Même avec des convois courts en N, 1m est un minimum minimaliste à mon avis.

- Une zone isolée est créée dès lors qu'une indépendance électrique est nécessaire pour exploiter. Par exemple, une voie à quai n'est pas un canton à elle seule, même si elle a une indépendance électrique pour qu'un train puisse y stationner tandis qu'un autre train passe sur la voie voisine.

Un canton peut contenir plusieurs zones isolées, lesquelles zones sont affectées à ce canton en permanence ou temporairement suivant la configuration du plan de voies. Dans une gare, une zone isolée peut faire partie un moment donné d'un canton A, à un autre moment d'un canton B, et à un troisième moment de rien du tout, tout cela dépend des itinéraires tracés.

Pour résumer, il n'est nul besoin d'avoir une signalisation et une commande de vitesse par zone isolée, mais par canton. Les zones qui composent un même canton reçoivent toutes la même alimentation traction : celle du canton. En gare, les zones isolées se connectent ou se déconnectent aux générateurs des cantons qu'elles sont susceptibles d'intégrer suivant la positions des aiguillages et des carrés.
Ainsi, il faut qu'un canton génére la tension PWM, et il faut que les zones isolées s'y connectent ou s'y déconnectent, par exemple avec un petit relais.

Bonjour Dominique,

DMARRION a écrit:

Je viens de voir ton sujet et de lire l'article en suivant le lien.
Tout d'abord je te remercie de m'avoir cité comme "source d'inspiration" pour le BAL.

Et puis ça définit clairement le contexte . . . sans effort pour moi !

Citation :

. . . Je profite de ce post pour revenir sur la notion de canton, je pense qu'elle est mal comprise par la plupart des modélistes qui confondent souvent cantons et zones isolées, et quand tu dis qu'il te faut 12 cantons pour un réseau qui tient sur 2m², ça me conforte dans cette idée.

- Un canton est lié à l'espacement des trains, et doit être assez long pour être réaliste, il faut qu'un train puisse y décélérer tranquillement, stabiliser sa vitesse d'approche et venir s'arrêter devant le signal. Même avec des convois courts en N, 1m est un minimum minimaliste à mon avis.

- Une zone isolée est créée dès lors qu'une indépendance électrique est nécessaire pour exploiter. Par exemple, une voie à quai n'est pas un canton à elle seule, même si elle a une indépendance électrique pour qu'un train puisse y stationner tandis qu'un autre train passe sur la voie voisine.

Un canton peut contenir plusieurs zones isolées, lesquelles zones sont affectées à ce canton en permanence ou temporairement suivant la configuration du plan de voies. Dans une gare, une zone isolée peut faire partie un moment donné d'un canton A, à un autre moment d'un canton B, et à un troisième moment de rien du tout, tout cela dépend des itinéraires tracés.

Pour résumer, il n'est nul besoin d'avoir une signalisation et une commande de vitesse par zone isolée, mais par canton. Les zones qui composent un même canton reçoivent toutes la même alimentation traction : celle du canton. En gare, les zones isolées se connectent ou se déconnectent aux générateurs des cantons qu'elles sont susceptibles d'intégrer suivant la positions des aiguillages et des carrés.
Ainsi, il faut qu'un canton génére la tension PWM, et il faut que les zones isolées s'y connectent ou s'y déconnectent, par exemple avec un petit relais.

NON ! Pas de relais ! ! !

Sinon, j'agrée sur tout avec, derrière la tête, l'idée que, pour 2€ (ou même 10€) par zone isolée autant multiplier le nombre de modules chacun avec son logiciel adapté au besoin même s'il ne s'agit que de dupliquer le signal de traction ça reste économiquement correct . . . et silencieux

Je comprends le point de vue, mais attention aux idées reçues concernant les relais : ils peuvent avoir une pertinence fonctionnelle et économique dans certains cas, par exemple pour inverser le courant de traction d'une zone à double sens de circulation. Il existe des relais pour circuit imprimé petits, très bon marché et fiables.

Voila un challenge intéressant : le BAL minimaliste.

Comme le suggère DMARRION, il y aura sans doute quelques complications à prévoir (au sens de la technique horlogère !...)

Pour info, les jeux d'instructions des PICs et des Atmegas n'ont rien à voir, c'est comme si tu comparais la famille 68000 de Motorola et la famille 8086 de Intel.

Comment vas tu régler la consigne de vitesse et donc la valeur du PWM de chaque canton ?

Comment gères tu la détection de court-circuit ?

C'est sûr ! Les voies uniques ou à double sens sans relais, c'est un autre challenge.
Le tracé actuel de mon réseau ne le nécessite pas, et ce n'est pas par hasard !

Pourtant, j'imagine d'y rajouter plus tard une gare terminus et un petit dépôt.
Et ce ne sera alors pas le seul problème à régler !

Effectivement pour les voies en double sens sans relais (puisque c'est ton choix) il faut passer au pont en H.
Et donc plus de pattes de commandes et plus de..........

CleoN a écrit:

Voila un challenge intéressant : le BAL minimaliste.

Comme le suggère DMARRION, il y aura sans doute quelques complications à prévoir (au sens de la technique horlogère !...)

Je m'y attends un peu !

Citation :

Pour info, les jeux d'instructions des PICs et des Atmegas n'ont rien à voir, c'est comme si tu comparais la famille 68000 de Motorola et la famille 8086 de Intel.

Tant qu'il n'y a pas de CodeSegment, DataSegment ou autre StackSegment je devrais m'en tirer  

Citation :

Comment vas tu régler la consigne de vitesse et donc la valeur du PWM de chaque canton ?

Tu veux dire avoir des cantons rapides et des cantons lents ?
Rien n'est encore figé. Peut être:
- Une valeur en dûr dans le code différente pour chaque canton.
- Plusieurs "générateurs de synchro" avec des rapports cycliques différents et/ou variables.
- . . .

Citation :

Comment gères tu la détection de court-circuit ?

Le Mosfet me semble capable de faire cramer l'alim sans broncher, donc un disjoncteur général devrait suffire. J'ai quelques blocs secteur pour girlandes de Leds qui sont autoprotégés et à réarmement automatique.

J'ai sûrement oublié pleins d'autres détails ou pas toujours choisi la meilleure solution, c'est pourquoi j'ai ouvert ce fil: AIDEZ MOI !

Pour la détection du court-circuit un polyswitch pourrait convenir...

Ou une ampoule halogène (par exemple 24V / 50W) en série dans l'alim. En service normal, la résistance de la lampe est faible et ne provoque qu'une chute de tension négligeable. En cas de court circuit, elle chauffe et le filament étant à coefficient de température positif, sa résistance augmente fortement absorbant ainsi l'énergie et limitant le courant de court-circuit.

Une lampe de 50 W / 24V a une résistance à chaud de 11,5 Ohms (R = U²/P, donc 24 x 24 / 50). Avec une alimentation de 12V, le filament sera moins chaud (puisque la puissance sera de 12,5W environ), sa résistance sera donc plus faible (il faudrait mesurer), je pense autour de 6 ou 8 Ohms. En cas de court-jus à la voie, le courant fourni par l'alim 12V serait donc limité à 2A maxi.

Avantages : rien à réarmer, et signalement automatique des court-jus par l'allumage de la lampe !

Yves07 a écrit:

....
Tant qu'il n'y a pas de CodeSegment, DataSegment ou autre StackSegment je devrais m'en tirer  
...

Désolé, il y a bien sûr des segments, text, data, bss etc...
Mais pas de soucis le compilateur GCC gère tout ça très bien, que ce soit à travers l'IDE Arduino ou avec un autre IDE. Personnellement j'utilise l'IDE Arduino pour les petits programmes et Codeblock pour les plus gros.
Il est bien rare que le compilateur C ne soit pas assez malin et qu'on soit obligé de dégainer l'assembleur.

Citation :

Citation :

Comment vas tu régler la consigne de vitesse et donc la valeur du PWM de chaque canton ?

Tu veux dire avoir des cantons rapides et des cantons lents ?
Rien n'est encore figé. Peut être:
- Une valeur en dûr dans le code différente pour chaque canton.
- Plusieurs "générateurs de synchro" avec des rapports cycliques différents et/ou variables.

Pour une adaptation à chaque canton, peut être un réglage personnalisé par l'intermédiaire d'une résistance ajustable montée en pont diviseur de tension:
- lecture de la tension sur une entrée Analog
- conversion tension en valeur utilisable pour le rapport cyclique de la PWM
Evidemment, ça fait une pin de plus en moins....

Merci à tous pour ces retours.

Je vais commencer par aller lire du code dans les innombrables exemples que l'on trouve sur LOCODUINO.
Voir et comprendre comment et pourquoi les autres ont fait est une bonne façon d'apprendre.
Et puis je reviendrais poser des questions !

CleoN a écrit:

. . Il est bien rare que le compilateur C ne soit pas assez malin et qu'on soit obligé de dégainer l'assembleur.

Parfait, donc on fait tout ça en C, ça me va bien !

Au plus simple (méthode BISE, voir ma signature):
- Toutes les variables en global et sur 8 bits
- Un évènement à 256 fois la fréquence du signal de synchronisation à partir de la clock interne
- Sur chaque évènement: etc, etc...

Yapuka !

Bon courage Yves!

Euh . . . Moquerie ou encouragement ?
Dans les deux cas, ça me motive !
Tu as la lourde responsabilité de m'avoir montré cette puce

De ma part ce n'est aucunement une moquerie!!
Bien au contraire et je souhaite sincèrement que tu réussisses ton projet

Compte tenu de l'état actuel de mon bureau/atelier/foutoir/espace de jeu, prévoir une petite semaine de délai avant de pouvoir passer aux choses sérieuses  

Bonjour Yves,

Ayant réalisé plusieurs projets pour le modélisme ferroviaire basés sur des microcontrôleurs: 4 avec des Attiny/Atmega, 2 avec des Arduino, je vais suivre ce projet de BAL avec grand intérêt.

Pour la conception du logiciel, je propose l'approche par machines d'états. C'est à ma connaissance le meilleur moyen de structurer les programmes devant réagir à des événements externes, y-compris des timeouts.

Tu peux soit tracer un diagramme d'états-transitions, soit remplir un tableau à 2 dimensions avec les états en colonnes, les événements en lignes et décrire le traitement à faire ainsi que le prochain état dans chaque case. La transcription en C en découle "presque" naturellement.

Bonne suite de réalisation.

Bonsoir et merci la Suisse,
Le nombre d'états, de transitions et de variables sont finalement très peu nombreux !
Je suis très optimiste

J'ai été visiter ton blog, ça va m'aider