TCO : Technologie utilisée pour les commandes d'itinéraires.

Bonjour,

En lisant les écrits des uns et des autres sur le forum, je vois qu'il y a essentiellement 2 écoles pour la commande des itinéraires dans une gare : ou bien la matrice à diodes, ou bien l'utilisation d'un logiciel et d'un PC.

Je suis étonné que personne (ou peu de monde) n'ait mis en oeuvre une technologie intermédiaire, utilisant par exemple des mémoires RAM (sauvegardées par une pile) qui contiendraient les positions des aiguilles et autres informations, chaque adresse correspondant à un itinéraire.

Dans un autre domaine que le modélisme, j'ai eu l'occasion de concevoir et construire des appareils (générateurs d'effets pour guitare électrique, console de commande pour éclairages scéniques) dont le fonctionnement reposait sur ces principes. C'est relativement "light" à construire, c'est évolutif (on peut à volonté modifier les données si le plan de voie change), et ça ne requière pas forcement de connaissance en programmation.

Quelqu'un a-t-il déjà abordé le sujet sous cet angle ?

Bonjour DMARRION,

Tout comme toi, j'ai parcouru les forums et sites de club (notamment celui de Nice AMFN) car je cherche une solution "simple" de gestion d'itinéraire, sans passer par un PC et un logiciel. Il y a une solution en DCC (j'ai étudié celle de l'auteur du TCO "ultime"), sans la retenir...

J'ai étudié une solution avec matrice de diodes, mais n'arrive pas à adapter la méthode employé le club de Nice pour une gestion de gare terminus de six voies... (pas trop compris les vérouillages d'itinéraire...)

Ta "technologie" intermédiaire" m'intéresse (j'ai des connaissances en electronique, en microprocesseur - "trés basiques") donc si tu pouvais développer... je suis preneur. Merci d'avance.

Cordialement,

class66 a écrit:

Ta "technologie" intermédiaire" m'intéresse (j'ai des connaissances en electronique, en microprocesseur - "trés basiques") donc si tu pouvais développer... je suis preneur. Merci d'avance.

J'ai bien peur de ne rien avoir à proposer dans un avenir proche.

En fait, je n'ai pas de réseau actuellement, même si je n'ai jamais cessé depuis les années 1980 de m'intéresser au N et d'acheter du matériel roulant de temps en temps. Depuis quelque temps, je suis passé un cran au dessus car j'habite maintenant une maison avec un grenier qui laisse augurer des perpectives trés alléchantes pour faire un grand réseau. Seul problème : Il faut d'abord refaire la toiture, isoler et arranger un peu les murs et le sol, je me suis donné 2 ans pour faire ça.

En attendant le gros oeuvre, je me replonge dans les automatismes qui vont avec l'exploitation d'un grand réseau, à savoir un block système efficace, des signaux lumineux, un système de commande des aiguillages.

- Concernant le block, j'ai commencé et bien avancé (voir le fil correspondant sur ce même forum https://le-forum-du-n.1fr1.net/t11928-un-block-automatique-simple-pour-reseau-analogique).
- J'ai également commencé la production de signaux lumineux https://le-forum-du-n.1fr1.net/t12571p15-signaux

Il me reste à réflechir à la commande des aiguillages, c'est pourquoi avant de me lancer sur une idée je cherche si quelqu'un n'a pas déjà développé quelque chose de sympa, sachant que je compte rester en analogique tant pour les locos que les aiguilles, et que je ne vois pas de plaisir (ça n'engage que moi) à tout commander avec un PC.

Si personne ne propose quelque chose qui me convienne, je passerai au stade recherche, prototype, mise au point etc, mais ça prendra du temps...

salut à vous il y a le switch contrôl chez Tams qui gère un tco jusque 16 aiguilles ensuite on peux le compléter

J'y avais penser de le faire avec un uC (un PIC) et la mémoire qui vas bien ...

Pour l'instant je fait un block avec freinage et ralentissement.
Le tout sur base de Pic, le schéma est fait et les fonctions valider,il me reste la programmation du PIC en cours.
Je ferais un topic, quand je l'aurais finis ou presque.

Concernant la gestion par uC avec mémoire, cela peut être simple, mais pas pour un novice qui n'a jamais fait de programmation.
Il lui faudra un peu de temps pour modifier ou créer ses trajets.

Un micro contrôleur a largement assez de mémoire pour gérer ce genre de chose.

D'un coté, un clavier de commande
De l'autre des sorties de commande de bobines d'aiguillages avec des fonctions "intelligentes":


-Temps d'action réglables
-Activation des aiguillages en cascade pour ne pas trop tirer sur l'alim quand il y en a plusieurs à commuter
Gestion des LEDs correspondantes sur un TCO
etc...

+ une interface de puissance suffisante pour les aiguilles utilisées (transistors, MOS etc...)

En fait pour répondre plus précisément à la question, il me semble que la technique des mémoires pour commander des itinéraires est dépassée, bien que fonctionnement parfaitement.

Yoko a écrit:

Concernant la gestion par uC avec mémoire, cela peut être simple, mais pas pour un novice qui n'a jamais fait de programmation.
Il lui faudra un peu de temps pour modifier ou créer ses trajets.

En fait, il est trés facile d'utiliser une mémoire sans lui adjoindre le moindre micropross. C'est ce que j'ai fait dans ma console lumière. Pour entrer la configuration dedans, j'utilise les commandes manuelles : Je régle les éclairages avec les potars manuels, et quand le résultat me plait, j'enregistre dans la mémoire à l'adresse X. Ensuite, chaque fois que je compose l'adresse X les lumières se réglent comme elles étaient quand j'ai enregistré.

On devrait pouvoir faire pareil avec les aiguillages : supposons des inverseurs permettant de commander directement "en manuel" les aiguilles (ça suppose les interfaces qui vont bien pour transformer cette information fixe en commande impulsionnelle, mais ça c'est pas dûr à faire), on forme de cette manière un itinéraire, et on mémorise à l'adresse souhaitée la position des inverseurs. Ensuite, on repasse en mode mémoire, et là, à chaque adresse les commandes d'aiguilles partiront pour reformer l'itinéraire correspondant.

Avec une 1024 x 8 bits, il y aurait largement de quoi faire en terme de nombre d'aiguilles et d'itinéraires.

C'est juste une idée comme ça. A voir si ça peut avoir un intérêt...

Je partage tout à fait le point de vue de CleoN quant aux avantages d'une solution à microcontrôleur par rapport à une logique basée sur un circuit mémoire.

Pour conserver les itinéraires d'une fois à l'autre, il faut une EEPROM et je vois difficilement comment la reprogrammer sans programmateur relié à un PC. D'après les explications de DMARRION, je suppose qu'il doit utiliser une RAM, mais cela signifie qu'il doit reconfigurer ses itinéraires à chaque mise sous tension.

Avec un microcontrôleur, on doit pouvoir envisager la reprogrammation d'itinéraires et leur sauvegarde dans l'EEPROM du microcontrôleur.

Pour la petite histoire, lorsque j'ai commencé à réfléchir à mon TCO qui gère l'allocation des alimentations tractions en gare et la commande des aiguillages (de "mini" itinéraires en quelque sorte), j'ai commencé par envisager d'implater la machine d'états avec une EEPROM et de la logique autour. Un ami avec qui j'en ai discuté m'a vite convaincu de passer au microcontrôleur. Mon TCO à microcontrôleur commande les aiguillages en 2 temps pour éviter de tirer trop de courant de l'alimentation.

Bonne fin de semaine à tous.

SavignyExpress a écrit:

Pour conserver les itinéraires d'une fois à l'autre, il faut une EEPROM et je vois difficilement comment la reprogrammer sans programmateur relié à un PC. D'après les explications de DMARRION, je suppose qu'il doit utiliser une RAM, mais cela signifie qu'il doit reconfigurer ses itinéraires à chaque mise sous tension.

Bonjour SavignyExpress
C'est effectivement une RAM dont il est question, mais pas de souci pour la conservation des données quand on coupe le courant : une simple pile de 4,5V suffit pour garder les données plus de 10 ans.

Se qu'il faut savoir, sait la place que peut prendre un telle programme.
Car, bien que les uC est de bonne mémoire maintenant, cela peut aussi très vite monter.

Aprés que la mémoire soit externe ou interne cela ne change pas le principe.
Il faut un uC pour gérer les E/S et de la mémoire pour stocker les itinéraires.

cheftrainminiature a écrit:

salut à vous il y a le switch contrôl chez Tams qui gère un tco jusque 16 aiguilles ensuite on peux le compléter

Bonjour,

J'ai cherché "Switch control TAMS" sur le NET, j'ai trouvé un coffret rackable avec 12 sorties sur prises SUB D 9 points et un port USB pour la gestion via un PC

S'agit-il bien de ce produit ?

Yoko a écrit:

Ce qu'il faut savoir, c'est la place que prendre un tel programme.

Pour donner une idée, le programme de contrôle de mon PN occupe 1 K de la flash de l'Attiny2313, mais ce programme n'a pas de table.

Je pense que les capacités des microcontrôleurs actuels devraient suffire pour implanter la gestion d'une vingtaines d'itinéraires avec autant d'aiguillages. Des techniques de multiplexage des entrées / sorties du microcontrôleur doivent certainement être employées.

Je vais réfléchir à cela durant ce week-end et compléter mon propos.

Ah bas oui, effectivement ce n'est pas énorme.
Tu serais sur qu'elle type de uC ?

Imaginons un microcontroleur avec 8K octet de mémoire. (c'est très courant, atmega8 par ex.)

On garde 6Ko pour le programme (c'est royal compte tenu de la fonction à réaliser)

Il reste 2Ko pour stocker la table des itinéraires.

Imaginons encore que tu ais 32 aiguillages, ce qui nécessite 4 octets pour mémoriser une combinaison.

Tu peux donc stocker 512 combinaisons... ça devrait suffire, non ?

Comme le dit Savigny, il faut multiplexer les entrées et les sorties pour augmenter le nombre de port d’entrée/sortie, ce qui n'est pas difficile.

Bonjour,

plusieurs solutions existent mais pour mon réseau je vais partir sur une solution avec PIC car en plus de la gestion des itinéraires, j'ai à gérer la gestion de l'alimentation des électro d'aiguillage PECO. Si on considère 2 ou 3 aiguilles à bouger au même instant le courant d'appel va faire plusieurs ampères, je préfère donc commander mes aiguilles en décalé.

pour le remplacement des matrices à diode, il y a peut être des mémoires EEPROM mais celà complique l'écriture dedans, mais la solution d'une RAM avec pile est plus simple. Reste à voir le montage global avec toutes les sorties nécessaires (matriçage ou fil à fil suivant le type de commande des aiguilles)

Ici, la commande des aiguilles est terminée ; un relais, un condensateur par aiguillage. Commande possible par un ULN2803 ou un transistor clasique.

[img][/img]

Bonnes réalisations à tous

Bonjour à tous,

J'avais promis de vous faire part de mes réflexions après le week-end (pas le dernier, celui d'avant), les voici avec une semaine de retard.

Principes généraux

• Utilisation d'un microcontrôleur AVR (ou PIC).
  
• Commandes d'aiguillages à électro-aimants. À voir quelles adaptations apporter pour des aiguillages à moteur lent, Conrad ou servo.
  
• Retour au TCO par des leds et résistances tirant parti des contacts de fin de course.
  
• Choix des itinéraires par un bouton poussoir ou 2 (source / destination).
  
• Activation des aiguillages d'un itinéraire l'un après l'autre pour éviter de tirer trop de courant de l'alimentation. Une led signale que l'itinéraire est en cours d'établissement.
  
• Commande optionnelle d'alimentations des voies en fonction de l'itinéraire.
  

Multiplexer les entrées / sorties
Le nombre d'entrées / sorties à disposition sur un micro-contrôleur est souvent inférieur aux besoins de l'application envisagée. Dans le cas d'une commande d'itinéraires, il serait nécessaire d'avoir:

• Une entrée par itinéraire ou une entrée par bouton source / destination.
  
• Deux sorties par aiguillage de manière à commander chaque direction séparément par des impulsions. C'est à mon avis plus sûr de ne pas se reposer sur les contacts de fin de course si ces derniers fonctionnaient mal.
  

La technique de multiplexage qui me semble adaptée à ce besoin est le Charlieplexing. Cette technique a été mise au point pour contrôler un grand nombre de leds. Avec N sorties, on peut contrôler N * (N - 1) leds. Avec un port de microcontrôleur à 8 bits, cela fait 56 leds.

En remplaçant chaque led par un optocoupleur (qui contient une led !!!) suivi d'un transistor de puissance on peut commander 56 électro-aimants d'aiguillage, soit 28 aiguillages avec un port 8 bits.

Le Charlieplexing ne permet pas d'allumer toutes les leds à la fois. Pour une application d'affichage à leds, on contourne cette restriction en rafraîchissant rapidement l'affichage, la persistence rétinienne faisant le reste. Pour la commande d'aiguillages, cette restriction n'est absolument pas gênante car nous souhaitons justement commander chaque aiguillage l'un après l'autre.

Le Charlieplexing peut aussi être utilisé pour lire l'état de plusieurs boutons poussoir. Il faut prévoir une diode par poussoir et on peut ainsi lire N * (N - 1) poussoirs à l'aide de N bits.

Donc, avec 2 ports 8 bits, on peut:

• Lire jusqu'à 56 poussoirs.
  
• Commander jusqu'à 28 aiguillages.
  

Si on veut commander des alimentations de voies supplémentaires via des relais, il faut évidemment prévoir des ports de sortie en plus, qui ne pourront pas être multiplexés en Charlieplexing.

Programmation
Avant d'aborder la programmation proprement dite, il faut:

• Identifier tous les itinéraires possibles.
  
• Identifier quels itinéraires sont compatibles entre eux.
  

Ensuite, un programme gérant l'état de chaque itinéraire possible, implanté sous forme de table, peut être réalisé.


Je vais dessiner quelques schémas que je posterai pour compléter ces explications.

Un lien décrivant le Charlieplexing: http://www.gdiy.com/projects/charlieplexing-leds-theory/index.php?lang=fr. Attention, c'est une traduction automatique, la plupart des articles décrivant le Charlieplexing sont en Anglais.

Bon début de semaine.

Tu as bougrement bien avancé ! Voilà qui établit les bases de l'architecture à utiliser pour développer un poste à commande électronique.

Un point cependant : Si on veut introduire les enchements d'approche et de transit (c'est dans mon cahier des charges), il faut pouvoir :

1°) Empécher la modification d'un itinéraire formé dés que le carré d'entrée est ouvert et qu'un train se trouve dans la zone qui précède l'avertissement correspondant

2°) Empêcher tout mouvement d'un aiguillage entrant dans un itinéraire formé et ouvert, tant que le dernier essieu du train qui devait l'emprunter n'est pas passé sur l'aiguillage.
Par extension de ce principe, il faut pour un réseau analogique verrouiller de la même manière les commandes de "sens" (par exemple relais inverseur de polarité) des zones d'un itinéraire formé et ouvert.

Pour ce faire, le découpage des tronçons de voie en zones isolées avec détection d'occupation par consommation de courant (motrices et essieux graphités des voitures et wagons) est incontournable. Ensuite, il faut voir comment on peut gerer celà : soit en intégrant ces dispositions dans la programmation du PIC, soit en jouant sur les interfaces d'entrée (pour l'enclenchement d'approche), ou de sortie (commande de puissance des moteurs d'aiguilles et relais de sens pour l'enclenchement de Transit).

Pour ce qui me concerne, j'ai décidé de laisser ce sujet de coté pour l'instant, car mon "compte temps modélisme" est entièrement consacré à la fabrication de signaux lumineux et de cartes électroniques de mon block automatique (dont j'espère bientôt pouvoir mettre en post la version 2).

SavignyExpress a écrit:

Le Charlieplexing ne permet pas d'allumer toutes les leds à la fois. Pour une application d'affichage à leds, on contourne cette restriction en rafraîchissant rapidement l'affichage, la persistence rétinienne faisant le reste. Pour la commande d'aiguillages, cette restriction n'est absolument pas gênante car nous souhaitons justement commander chaque aiguillage l'un après l'autre.

Si on veut commander des alimentations de voies supplémentaires via des relais, il faut évidemment prévoir des ports de sortie en plus, qui ne pourront pas être multiplexés en Charlieplexing.

On peut garder une information stable entre 2 pas de rafraîchissement avec des bascules D.

bonjour,

je suis avec intérêt votre avancement et en particulier la création des itinéraires. Belles réalisations en cours.

J'ai regardé le Charlieplexing de Maxim, je suis dubitatif sur le fonctionnement envisagé (mais souhaite que celà marche) pour deux raisons, Maxim préconise cette solution pour des afficheurs ou des bargraph (les caractéristiques Vf/If des Leds sont semblables sur un même substrat) et les composants conseillés sont des générateurs de courant (I constant avec seulement Vf qui suit les caractéristiques, celà doit aider pour bloquer les deux Leds série qui pourraient être en parallèle)

en attendant, continuez à nous informer. Je commence le coffret de mon TCO.

Boones réalisations.

Décau45 a écrit:

J'ai regardé le Charlieplexing de Maxim, je suis dubitatif sur le fonctionnement envisagé (mais souhaite que celà marche) pour deux raisons, Maxim préconise cette solution pour des afficheurs ou des bargraph (les caractéristiques Vf/If des Leds sont semblables sur un même substrat) et les composants conseillés sont des générateurs de courant (I constant avec seulement Vf qui suit les caractéristiques, celà doit aider pour bloquer les deux Leds série qui pourraient être en parallèle)
.

Bonjour Décau45
Lorsque j'ai construit ma table de commande lumière (voir début de ce fil), j'ai dû multiplexer les données. En effet, j'avais 96 bits de données à faire entrer dans une RAM de 2048 x 8 bits. J'ai donc divisé par 16 le nombre d'adresses possibles, j'en ai gardé 128 pour mes mémoires "utilisateur", et j'ai utilisé le reste pour différentier les paquets de 8 que je rentre l'un après l'autre en incrémentant l'adresse. C'est l'horloge utilisée pour le codage analogique/Numérique des potentiomètres qui orchestre ce multiplexage. Pour la restitution, j'ai utilisé des bascules D pour garder une info stable entre 2 balayages de l'horloge (j'espère que mes explications sont claires, étant "dedans", j'ai du mal à me rendre compte).
Par contre, je ne suis pas assez familiarisé avec l'utilisation des microcontroleurs pour savoir si cette méthode est transposable telle quelle pour le montage envisagé par SavignyExpress.

Bonjour Décau45 et DMARRION,

Le Charlieplexing ne peut fonctionner qu'avec des leds ou des diodes. La plupart des articles sur le sujet mentionnent qu'il faut que toutes les leds / diodes aient la même tension de seuil Vf.

Entre 2 pins du microcontrôleur, il y a plusieurs chemins passant par 1, 2 ou plus de leds. Seul le chemin passant par une led sera actif, les leds des autres chemins n'ayant pas une tension suffisante à leurs bornes.

À un instant donné, seuls 2 pins sont en sortie, l'une à 1 l'autre à 0. Tous les autres pins du microcontrôleur sont en entrée (résistance de tirage désactivée) de manière à ne pas perturber les autres chemins de leds.

Les articles sur le Charlieplexing expliquent cela mieux que moi !!!

Bonne journée.

Alors peut-être que le Charlieplexing n'est pas la bonne réponse au problème. Pourquoi ne pas mettre en oeuvre un multiplexage classique ?
Comme le port fait 8 bits, ça fait 4 moteurs (ou même 8 si on fabrique une petite interface qui transforme un état 1 en commande impulsionnelle à droite et un état 0 en commande impulsionnelle à gauche).
J'imagine qu'il doit y avoir moyen de configurer le PIC pour qu'il affiche successivement 2, 4 ou 8 x 8 bits (suivant le nombre d'aiguillage à commander). Ensuite, les bascules D feraient le reste, il faut juste un signal d'horloge pour controler le démultiplexage en déclenchant les bascules D au bon moment...

Dans un autre post, CleoN avait déjà mentionné le registre à décalage TPIC6B596 pour multiplexer les sorties. La connexion au microcontrôleur est alors plus simple qu'avec le Charlieplexing que l'on peut conserver pour multiplexer les entrées.

bonjour SavignyExpress et Dmarrion,

ce doit être une belle réalisation la table de lumière en logique câblée ! le PIC peut simplifier la partie logique mais pas celle des entrées/sorties.
un PIC comporte un nombre limité de broches et donc d'E/S.
J'ai vu que dans le modélisme train il y avait eu le développement d'un bus S88. Sur cette base, on peut raccorder au PIC des circuits logiques du genre 4014 ou 4094 afin d'augmenter le nombre d'E/S. Celà nécessitera de la part du PIC qu'un nombre limité de broches (data IN & OUT, clock, enable) pour pouvoir lire ou charger plusieurs circuits montés en cascade.
un PIC dispose aussi de CAN 10 bits qui peuvent lire des tensions (ex potentiomètres)

pour SavignyExpress, continue à nous présenter tes belles réalisations. Je m'en inspire beaucoup.

Cordialement. Michel.

PS : je termine le coffre de mon TCO, et j'essaye de comprendre la logique du programme en C.

Décau45 a écrit:

ce doit être une belle réalisation la table de lumière en logique câblée !

Tu serais surpris, c'est moins compliqué que tu ne l'imagines.
A l'occasion, je t'enverrai des photos de l'intérieur en MP (car c'est quand même hors sujet du forum !)

En logique câblée, la carte (ou les cartes)électroniques sont un peu plus "garnies", mais les tracés sont en général assez simples et récurents, le fonctionnement n'est pas concentré dans un bloc "intelligent" mais réparti dans des sous-ensembles faciles à mettre au point et à maîtriser. Moi, j'aime bien (on l'aura sans doute deviné...).

Bon courage pour ton TCO, et vivement les photos !

Dom