Commande de PN: 1er essai

Bonsoir à tous,

Voici le 1er essai de commande de barrière de PN à l'aide d'un servo-moteur de modélisme et d'un microcontrôleur Attiny2313.


Le servo-moteur sera fixé sous le réseau. Il actionne une tringle fixée à la barrière. Pour l'instant, la tringle est dorée, elle sera peinte pour être plus discrète. Sur le réseau, il y aura un servo-moteur pour chaque barrière.


Le signal de commande du servo-moteur est une impulsion de 5V, d'une durée comprise entre 1 ms et 2 ms, répétée toutes les 20 ms.


J'utilise le timer du microcontrôleur Attiny2313 pour générer la commande du servo. Sur la vidéo, on voit le changement de durée de l'impulsion sur l'écran de l'oscilloscope à l'arrière-plan.

La détection des trains sera faite par un pont de diodes produisant une chute de tension suffisante pour commander un opto-coupleur, cela permettra de séparer complètement les alimentations traction du circuit électronique de commande.


Je développe le programme sous Linux (on peut aussi sous Windows !!!). Ce type de développement était mon quotidien professionnel il y a une quinzaine d'années, une façon comme une autre de rajeunir


Suite des travaux:

• Finir le développement du programme pour intégrer la commande des feux clignotants et la durée d'activité après détection du train.
  
• Réalisation du circuit en Veroboard.
  
• Tests.
  
• Installation sur le réseau et décor du PN.
  

À bientôt...

Bonjour,

Un ordinateur juste pour un PN. Et dire qu'il y en a qui ne veulent pas entendre parler d'informatique sur le réseau

Bravo quand même mais il me semble que la commande d'un servo moteur peut se faire plus simplement.

Très bon boulot, quand on a les connaissances et l'équipement, cela devient tout de suite plus aisé.

Murphy a écrit:

Un ordinateur juste pour un PN. Et dire qu'il y en a qui ne veulent pas entendre parler d'informatique sur le réseau

C'est vrai que j'avais fait cette remarque dans l'un de mes messages

L'ordinateur n'est là que pour le développement et le téléchargement du programme dans le microcontrôleur. Une fois cette étape finie, il est déconnecté du circuit. L'ordinateur n'est donc jamais relié à mon réseau.

Même si le microcontrôleur constitue un ordinateur très minimal qui se programme en langage C, il s'agit plus d'électronique que d'informatique. Ce type de composant simplifie énormément la commande du PN qui, sans cela, nécessiterait une multitude de circuits logiques discrets pour en plus gérer le clignotement des signaux, la durée durant laquelle la barrière est baissée et les signaux clignotent.

Murphy a écrit:

Bravo quand même mais il me semble que la commande d'un servo moteur peut se faire plus simplement.

Oui tu as raison, on trouve des montages de commande de servos basés sur le timer 555, mais il faut plus de composants autour pour réaliser la même fonction.

Pour une introduction aux microcontrôleurs dans le domaine du modélisme ferroviaire, il y a l'excellente série d'articles PIC trains sur www.ptitrain.com. C'est une autre famille de microcontrôleurs qui est présentée, les PICS, mais les principes sont les mêmes qu'avec la famille AVR que j'utilise.

Bonne journée.

Félicitation, ça m'épate ce que tu arrives à faire
Amitiés Jappy

Bonjour,

Dans le même ordre d'idée, j'ai découvert très récemment les modules Arduino qui permettent de gérer des E/S analogiques et numériques. Ils se programment à partir d'un PC. Le module "standard" se trouve à 24€.

Pour SavignyExpress,
Excellent montage, je suis impressionné!!!
Je suis plus familier des PIC que des AVR... (IDE Microchip pour PIC, programmmateur maison...) Quel outil utilises-tu pour développer en C, puis compiler pour le Tiny ? Quel programmateur pour le téléchargement du programme compilé ? Un exemple de ton programme serait bienvenu... merci d'avance...

Hello class66,

Voici quelques éléments de réponses à tes questions sur le développement pour AVR.

Windows
L'environnement s'appelle WinAVR, il est gratuit et est téléchargeable depuis plusieurs sites, par exemple:

http://www.qweas.com/downloads/development/c-c-c/overview-winavr.html

Je l'ai utilisé pour mes tous premiers essais, avant de passer sous Linux.

Linux
Il faut installer les paquets suivants, disponibles dans la plupart des distributions (dans mon cas, Fedora):

• gcc-avr: compilateur C, WinAVR utilise le même en version Windows.
  
• binutils-avr: utilitaires divers tels que linker, assembleur.
  
• avr-libc: librairie de symboles et fonctions de base: noms des registres, fonctions de délais, etc.
  
• avrdude: outil pour le téléchargement.
  

L'appel au compilateur et à avrdude sont définis dans le makefile, récupéré de l'environnement WinAVR, puis adapté. Ensuite, l'éditeur de texte gedit de Gnome sous Linux permet d'appeler des fonctions externes, j'ai donc défini les diverses commandes pour compiler le programme en mode PC ou AVR, l'exécuter sur PC ou le télécharger dans l'AVR avec avrdude.

Il existe d'autres alternatives, dont l'IDE KontrollerLab que je n'ai pas essayé d'installer.

J'utilise un programmateur branché sur le port parallèle, compatible STK500, développé par un ami. Il faudra que j'envisage de passer à un programmateur USB, car le port parallèle est en voie de disparition sur les PCs récents.

Pour faciliter la mise au point du programme, je le compile avec gcc et l'exécute sur le PC avec une multitude d'instructions d'affichage à l'écran. Des directives de compilation conditionnelle permettent de séparer le code spécifique à l'AVR du code spécifique au PC. Cela permet de tester la logique du programme sans se préoccuper des aspects spécifiques à l'AVR.

Ma technique de programmation favorite consiste à implanter des machines à états finis. Il est ainsi relativement aisé de gérer plusieurs tâches en parallèle. Je posterai le programme qui gère mon TCO durant le week-end. Le prorgramme qui gère le PN est encore en développement.

https://le-forum-du-n.1fr1.net/t8788-tco-du-reseau-savignyexpress

Bonsoir

Je travaille avec, à peu de chose près, le même environnement sous linux, avec en plus Anjuta pour la gestion de projet.
Je suis passé à la programmation des micro-contrôleurs via USB avec un petit circuit appelé USBASP; ci dessous le site ou j'ai pris le schéma et le code.
Il est connu par le logiciel de programmation avrdude.

http://www.fischl.de/usbasp/

Bonsoir à tous les deux,
Merci pour vos explications, c'est super sympa... et ça répond à mes interrogations... Excellente soirée à tous.

Hello class 66,

Je t'ai envoyé l'exemple de code par MP.

Merci à CleoN pour son info. Je n'ai pas testé Anjuta, l'éditeur gedit suffisant à mes besoins, mais pourquoi pas !

Bon début de semaine.

je sois avouer que tout cela me dépasse....
Par contre le langui de voir le résultat sur ton réseau
ptitrainrouge

tout ceci est du chinois pour moi, je ne dois pas être le seul !

mais bravo pour ce genre de travail !!

chadok38 a écrit:

bravo pour ce genre de travail !!

+1 et bravo pour le rendu.

chadok38 a écrit:

tout ceci est du chinois pour moi, je ne dois pas être le seul !!!

+250

Jmarc69
N'iste qui a décroché

Je reprends ici les commentaires sur la motorisation de PN tirés du fil sur le réseau de Ptitrainrouge.

DMARRION a écrit:

Si j'ai bien compris, le problème est la durée de fermeture du PN, qui est réglée par une tempo ce qui peut engendrer une réouverture prématurée (train long et lent) ou tardive (train court et rapide).

SavignyExpress, tu places un détecteur en amont et un en aval, avec un petit soft pour gérer. C'est effectivement l'idéal si tu utilises des ILS ou barrières IR pour détecter les trains (informations ponctuelles qu'il faut bien enregistrer et effacer), mais si tu utilises des détections par consommation, pourquoi prendre 2 points alors qu'il te suffit d'une seule zone isolée qui commence en amont du PN et se termine juste après ? (on peut sans problème aller jusqu'à plusieurs métres de long)

Si les essieux de tes voitures et wagons sont graphités, alors le fonctionnement du PN devient trés simple : Dés que le premier essieu entre sur la zone ; il se ferme, dés que le dernier essieu quitte la zone ; il se rouvre. Le seul automatisme qui reste à faire consiste à retarder la fermeture des barrières quelques secondes, de façon à n'avoir que les feux clignotants au début de l'annonce.

Ce système t'assure une réouverture au bon moment, quelque soit la longueur et la vitesse du train (et ça marche aussi pour les rames réversibles avec machine en queue).
Sympa, non ?

J'ai dû placer 2 zones de détection par consommation de courant de part et d'autre de mon PN pour la raison suivante.

L'une des zones (dans le tunnel) est très proche de la gare. J'ai quelques voitures voyageur éclairées et, le train peut attendre à l'entrée de la gare avec la dernière voiture encore sur la zone de détection. Cela réouvrait le PN qui venait de se refermer !

Avec 2 zones et des diodes, il est facile de faire en sorte que les zones de détection ne "voient" que les trains qui vont en direction du PN et ignorent ceux qui en sortent. Du coup, seule la temporisation en fonction du train le plus long est applicable dans ce cas.

Une alternative aurait été que le microcontrôleur sache que le train est en attente, mais le soft aurait été plus compliqué. Ou alors un réseau plus grand

Bonjour,

Vieux sujet, mais aurais-tu un schéma de la commande sur la barrière reliée au servo

Merci

Bonjour Moulardjl,

Voici déjà le lien vers le tuto de la partie électronique du PN: https://le-forum-du-n.1fr1.net/t12790-pn-actionne-par-servo-moteurs-electronique. Je recherche les schémas et les posterai dès que possible.

Belle réalisation et bonne fin de semaine.

Bonsoir à tous c'est un sujet d'actualité,
Je suis aussi intéressé nous en avons parlé mercredi soir.
Merci à toi SavignyExpress

Bonjour à tous,

J'ai remis la main sur les schémas. Sur mon réseau, ce système gère le PN proche de la ville qui comporte des barrières et des clignotants ainsi que le PN qui va vers la zone marchandises qui ne comporte que les clignotants (pas suffisamment de place pour avoir le temps de baisser les barrières).

Dans le 1er schéma, les 2 optos du haut correspondent à la détection de part et d'autre du PN proche de la ville. Il faut aussi ne considérer que les clignotants marqués "signaux ville".



Dans le 2ème schéma, Il ne faut considérer que la partie marquée "Ville". On notera que la détection est unidirectionnelle pour ne détecter que les trains en approche du PN. C'était nécessaire car la zone de détection gauche peut avoir un train avec des voitures éclairées sortant du PN, en attente d'entrée en gare et cela redéclenchait la fermeture du PN.



Bon début de semaine.