Bonjour,

J'ouvre ce nouveau fil de discussion pour vous présenter ce nouveau projet en cours de réalisation : ATC pour Analogic Train Controler dont j'avais brièvement parlé lors de ma présentation.

Le but principal de ce projet est donc de proposer un système de contrôle modulaire analogique (Aiguillages, vitesses et détection par canton...) plutôt prévu pour de petits réseaux (mais pourquoi pas de plus importants ?), simple, évolutif et le moins coûteux possible (mais ça sera toujours plus cher qu'un simple transfo jouef...)

Il sera réalisé sur la base de micro-contrôleurs PIC, pré-programmé avec un bootloader pour pouvoir ensuite les mettre a jour par USB sans programmateur (Bon ok il faudra quand même passer par la case programmateur pour mettre le bootloader....).
J'utiliserais au maximum des logiciels Open Source pour éviter de lourds investissements aux personnes qui souhaiterais se lancer dans l'aventure.
Principalement:
- Lazarus pour la partie PC (un EDI Pascal similaire à feu Delphi en moins usine a gaz...)
- JALv2 pour la partie PIC (un language a mi-chemin entre le pascal et le basic)
- TinyBootLoader pour le bootloader du PIC.
- Diptrace pour la réalisation des schéma & typon (freeware pour des petits circuits)
La partie PC n'est uniquement là que pour mettre a jour les programmes des PIC via USB ainsi que mettre à jour l'EEPROM pour paramétrer le programme selon le réseau de chacun.

Je vais réaliser ultérieurement un simple site pour plus de détails(les schéma, sources typons...).
En attendant je posterais les détails dans ce fil en mettant a jour ce premier post pour ajouter les liens au fur et a mesure dans le menu ci dessous (ou en complétant ce menu)

ATC - Analogic Train Controler


1. Présentation (plus détaillée)
   
2. Le module MicroContrôleur
   
3. Le Contrôleur d'aiguillage (8 aiguillages max)
   
4. Le Contrôleur détection (6 cantons avec direction)
   
5. Le contrôleur de vitesse (2 cantons + détection)

@+

Denis

Editions:
[11/09/2011] MAJ lien Présentation et ajout de Diptrace dans les logiciels.
[12/09/2011] Ajout du lien au post : le module MicroContrôleur.
[13/09/2011] Ajout du lien au post : Le Contrôleur d'aiguillage.
[14/09/2011] Ajout du lien au post : Le Contrôleur détection.

Bienvenu au bricoleur informatico-électronique!

On attend la suite avec impatience.....

ATC - Analogic Train Controler

1. PRESENTATION

Donc ATC est donc un projet qui se veut modulaire:
Partant d'une base de quelques modules spécifique, on peut aisément rajouter des modules selon la configuration de son réseau.
Par exemple le module de contrôle d'aiguillage peut gérer jusqu'à huit aiguillages de type relai simple (ou 4 Minitrix). Si votre réseau comporte plus d'aiguillages, il suffit de rajouter un second module, si votre réseau comporte moins d'aiguillages, il suffit de configurer le module en ce sens.

3 modules seront réalisés dans un premier temps :
- Le module de contrôle d'aiguillage
- Le module de contrôle de détection
- Le module de contrôle de vitesse

Chacun de ces modules sont eux même modularisés pour les adapter au maximum a des réseaux hétéroclites, "industrialiser leur réalisation" (on peut parler de sous module)

Ainsi, le microcontrôleur est lui même un sous-module qui est commun aux 3 modules
exemple du contrôleur d'aiguillage:

Vous voyez le module du microcontroleur au centre et les huit modules d'aiguillage a gauche.
En haut et a droite les connecteurs pour les boutons et les LED.

Les modules sont indépendants et dédiés à leur fonction. Cependant j'ai prévu et anticipé la connection de ces dernier entre eux via un bus I2C pour pouvoir ultérieurement faire évoluer le système (MAJ centralisée ? ou contrôle par ordinateur du réseau ?....)

Cette présentation est très théorique mais les prochains chapitres seront plus clair, en tout cas plus démonstratif en décrivant en détail les sous-module et les modules.

@+

Denis

Bonjour,
Bravo pour cette réalisation. Je suis très intéressé, car mon réseau est en cours de construction, et la circulation sera analogique.
Je vais donc suivre avec beaucoup d'attention ce post.
Phil

Bonjour.

Je suis "digital" mais, je vais suivre avec intérêt ton sujet.

A +

je suis en analogique donc particulierement interesse par ce projet ...bien que mes connaissances en microprocesseurs PIC sont nulles ...

2. LE MODULE MICROCONTROLEUR

A)Introduction

C'est parti pour le premier et le plus important des "sous-modules" car c'est le cerveau du système et il sera utilisé dans chacun des modules principaux. Il constitue donc une entrée en matière sur la philosophie du système et c'est aussi l'un des plus simple. Nous allons donc commencer en douceur (Le plus complexe sera pour le dernier chapitre du projet !).

Nous nous attarderons dans un premier temps sur le choix du microcontroleur pour enchaîner sur le schéma général du module et finir sur la technique de programmation du microcontroleur.

B)Choix du MicroContrôleur

Ce module supporte donc le microcontroleur utilisé pour piloter chacune des briques du projet. La première et plus longue des tâches a donc été le choix du microcontroleur parmis les centaines de références...

J'ai fait ce choix selon les critères suivants :

• Etre polivalent pour l'ensemble des modules prévus (voir ceux à venir..... ). Surtout pour avoir une seule référence de microcontrôleur pour l'ensemble du projet et ainsi simplifier la programmation et surtout : On reste modulaire !
  
• Etre adapter à un petit réseau: Exit les 40 broches, je me suis focalisé sur les 28 broches.
  
• Avoir un maximum d'E/S disponible pour le projet : Exit ceux avec USB ou sans horloge interne qui ont des broches strictement réservées pour ces fonctions. Sachant que pour un PIC de 28 broches il y en a déjà au moins 3 de "perdues" pour le jus (Une entrée Vdd et deux masses), il doit nous rester 25 lignes.... de quoi jouer un peu!
  
• Avoir une horloge interne pour pouvoir fonctionner sans cristal externe. Cela permet de garder deux broches pour le projet mais c'est moins précis. Cependant le but ici n'est pas de rivaliser avec l'horloge atomique, les 5% de marge me semble largement acceptable pour nos activités (et en plus ça consomme moins de courant).
  
• Avoir de la mémoire: De la mémoire Flash pour 16K au moins pour les tâches les plus complexes. Comme je suis un total amateur en electro... c'est le programme qui va en faire un maximum! Il faut aussi de la RAM pour les variables au moins 500 octets et aussi une EEPROM pour la configuration des modules au moins 128 octets ? (En l'absence de programme finis, difficile de savoir les besoins finaux...)
  
• Etre disponible, c'est a dire : être toujours en production... Et second critère plus flou: avoir un revendeur autre que le fabricant des PIC MICROCHIP et de préférence français? Bon, pour MICROCHIP, si vous avez besoin de petites quantités (2-4) vous pouvez toujours demander des samples (Echantillons) gratuits et sans frais de port c'est toujours ça de gagné (comptez un mois de délai). Sinon les divers revendeurs français qui restent encore (mais leur stocks sont très limités, surtout peu variés ). Ebay, mais c'est pas toujours la bonne affaire. Les revendeurs orienté "pro", là le choix est là mais tous ne livrent pas aux particuliers où alors ils restreignent leur catalogue et ça a moins d'intérêt si on sort des sentiers battus.

Voilà et suite à tout ça LE gagnant est: 18F2520 !

Alors je ne dis pas que, à terme, c'est le meilleur choix, mais il répond largement à l'ensemble des critères mentionnés. Il est même très large en mémoire: 32ko de flash! 1,5K de RAM et 256 d' EEPROM, ce qui est bien pour une phase de conception. Son petit frère le 18F2420 devrais être une alternative acceptable: Il a deux fois moins de mémoire mais ça devrait largement suffire je pense. J'ai réussi a en trouver sur Ebay, il y a un ou deux revendeur français aussi qui en propose, sinon les "pro" ou MICROCHIP...
J'ai identifié une quinzaine de références de PIC potentiellement interchangeables en ce qui nous concerne... A analyser plus en détail dans une seconde étape.

J'arrête là pour le PIC avant l'indigestion et passons au module proprement dit.

C)Présentation du module

En fait fait ça ressemble a un module d'Arduino version nano, et la philosophie est la même, sauf que :
- J'ai supprimé le FT232 pour l'externaliser et diviser par deux le coût de la carte. Mais j'en reparle dans le chapitre suivant.
- Je fait quelque peut usage de composants CMS... (des 1206 , les plus gros et pour la plupart des résistances et condensateurs...). Et j'essaye de proposer des alternatives de composants standard si possible. Par ailleurs je vais au maximum employer des circuits simple face plus facile a réaliser pour un particulier (personnellement j'ai un insolateur maison avec des leds UV, et la gravure dans des bols quand ma femme n'est pas là ). Seule la carte du module de puissance (basée sur un L298) sera double face car je ne suis pas encore arrivé à trouver l'agencement idéal.

Le schéma électronique:

Et une première version de la carte (composants, pistes, straps en vue du dessus)


Pour ceux qui connaisse déjà les PIC, il est presque classique. Je dis presque car tout le monde s'évertue à leur coller un cristal au derrière alors qu'ici il n'y en a pas ce qui me permet de récupérer les lignes RA6 et RA7 pour le projet.
Et nous en avons besoin car certaines lignes sont déjà utilisé pour ce module:
- 2 lignes de l'interface série (UART) pour la programmation du PIC via un module UART/USB (comme présenté dans l'Elektor de septembre).
- 2 lignes de l'interface I2C pour la connection des modules entre eux (non utilisée dans un premier temps mais prévue....). Avec deux "jumpers" pour connecter ou non les résistances "pull-up" nécessaires au bon fonctionnement de l'interface I2C : Un seul module doit les utiliser et pas les autres (enfin c'est sujet a discussion mais hors sujet là tout de suite.... ).

En fait en réalisant cette présentation je constate déjà une "boulette" de ma part :
Il est idiot de perdre les deux lignes de l'interface série, car elle ne sont utilisées que lors du démarrage du PIC pour détecter une éventuelle connection au PC pour MAJ de la mémoire. En dehors de ça, après le "boot", elles sont libres... Pour les modules étudiés je n'en ai pas besoin, mais il y a deux broches éventuellement disponible sur J5 (1&2) a voir pour une seconde version...

Dans la série remarques, pour la partie "Alimentation MCU" il y a une diode schottky (qui se ballade un peut de traviolle sur le module mais je voulais pas non plus augmenter la taille de ce dernier juste pour cette foutue diode). Elle n'est là que pour protection lors de la phase de programmation afin d'isoler l'alimentation de ce module lors de cette phase.
En effet dans ce cas particulier l'alimentation du PIC se fait par la prise USB du PC (500ma max) et non par l'alimentation 5v générale, et en l'absence de cette diode c'est l'ensemble des modules, de l'alimention 5v qui vont se retrouver alimentés par ce port USB : pas vraiment glop (ou alors il faut déconnecter le module à chaque programmation...). J'ai préféré la sécurité, la feignantise un accident est si vite arrivé...
Dans la même optique si on reconnectait les lignes UART vues plus haut ça serait mieux de leur coller des diodes même si dans leur cas les effets sont plus limités, ça serait plus propre.

Pour en finir dans ce bloc il a un switch pour ré-initialiser le PIC (Reset). Il ne servira que pour la phase de test / debug sauf si quelqu'un veut pouvoir ré-initialiser les modules via son pupitre ?

Enfin l'alimentation de service provient du module support (module de contrôle).


D)La programmation

Je vais finir la présentation de ce module par la technique de programmation des microcontroleurs dans le cadre de ce projet (Je ne vais pas parler de programme mais juste de comment on va charger le programme dans le PIC pour qu'il l'execute).

La première méthode c'est le programmateur de base: on connecte le PIC dessus on branche le tout au PC , on charge le code executable via un programme windows, on met le PIC dans sont emplacement final et voilà...
Simple, mais si on veut reprogrammer ou modifier une configuration , il faut le sortir de son emplacement le remettre sur le programmateur... Bref de la manutention avec le risque de briser une patte ce qui mettrait un terme à sa carrière.

Seconde méthode : l'ICSP (In circuit serial programming) qui permet de programmer le PIC directement dans son emplacement final. Finis le transvasement, mais il faut un programmateur spécifique (comme le PICKIT2 ou 3 pour les PIC) et prévoir un connecteur en ligne à 6 broches (HDR6X1) sur la carte, isoler les lignes utilisées lors de la programmation.... pas insurmontable mais un investissement supplémentaire.

Troisième méthode : Le Bootloader.
Le bootloader est un petit programme qui est situé au début ou à la fin de la mémoire flash du PIC et qui permet de transferer le programme et les variables qui transitent via la liaison série RS232 (UART) vers la mémoire interne du microcontroleur PIC sans avoir besoin d'enlever le composant. Bon en fait il faut un programmateur au moins pour mettre le bootloader dans le PIC.... c'est toute l'ironie du système...
Le bootloader est donc exécuté a chaque démarrage du PIC, puis, s'il ne détecte aucune transmission via la liaison série, il bascule sur le programme applicatif. Vous avez plus de détails ici: Programmation des PIC 16F et 18F avec TinyBootLoader, ainsi qu'une présentation d'un module RS232/USB nécessaire pour ce montage.

Autres méthodes : il y aurais d'autres méthodes (USB pour PIC avec interface USB ou tout autres interfaces : I2C...)

Pour ce projet je vais utiliser la troisième méthode. L'intérêt de celle-ci c'est qu'il est possible non seulement de charger le programme mais aussi de changer les données dans l'EEPROM de manière plus sympatique qu'un programme de chargement standard.
Genre avoir ça :

au lieu de ça :

Parce que la bidouille d'octet, ça n'est jamais glop pour personne...

Pour le BootLoader je pensais utiliser TinyBootLoader mais c'est pas sûr encore, je vais peut être me rabattre sur celui de MICROCHIP (AN1310 HighSpeed BootLoader).
A ce stade du projet ça n'est pas important : On peut programmer le PIC a l'ancienne dans un premier temps avant de basculer sur du bootloader, car c'est complètement transparent pour le programme applicatif.
Je vais donc sûrement mettre une interface ICSP dans une seconde version du module, pour simplifier la conception des programmes, en plus cela permet d'utiliser un débogueur matériel

Enfin, il faudra donc utiliser a terme une petite carte d'interface série/USB comme présenté dans le lien sur TinyBootLoader vu plus haut (coût entre 7 et 15€ pour une version toute prête).

D)Ensuite ?
En fait j'ai dans l'idée plus lointaine et hypothétique de concevoir un module de contrôle "Maître" basé sur un PIC 18F2550 avec USB (a oui je transgresse une de mes règles...). Celui-ci sera connecté à l'ensemble des modules de contrôle via l'interface I2C, soit pour les piloter via le PC, soit pour les programmer par I2C en "live" sans avoir besoin d'un quelconque module supplémentaire et ni d'accéder manuellement aux modules pour les connecter.

Mais il faut y aller par étapes sans se montrer trop ambitieux a court terme:
On finalise déjà une version exploitable ensuite on pourra s'attaquer aux améliorations du système.

Conclusions
Voilà la présentation du premier module terminée. N'hésitez pas à me faire part de vos critiques et suggestions !

Prochaîne étape : Le contrôleur d'aiguillage

Hello Denice,

Ton projet est très intéressant.

J'ai un peu d'expérience avec les micro-contrôleurs AVR (Atmel) et je suivrai avec intérêt ton projet. Je n'utilise que des logiciels Open Source, travaillant sous Linux avec avr-gcc, avrdude, etc.

Quel est l'état de ton projet ? Conception, réalisation, tests ?

Bonne suite.

2. LE CONTRÔLEUR D'AIGUILLAGE

A)Introduction
Nous allons voir ici le premier des modules de contrôle du projet : Le contrôleur d'aiguillage.
C'est un module vraiment intéressant : Il me semblait être le plus simple du lot et il s'est avéré finallement plus complexe à concevoir et le programme aussi va être sympa. Ce dernier n'est pas encore réalisé mais j'ai déjà une version fonctionnelle sous MikroPascal pour un PIC16F690 avec 4 relais et un Minitrix testé sur une carte EasyPIC6 (Les sorties relais connectés a des LEDs) . Il me servira de base de travail et je le mettrais à disposition incessamment sous peu pour ceux que ça intéresse.

Je vais vous présenter dans un premier temps le module et les problèmes rencontrés, ensuite on enchaîne sur la partie électronique et on finira sur le programme du PIC (Enfin les grandes lignes).

B)Présentation du module
Ce module permet donc de contrôler des aiguillages via un pupitre de commande/TCO. Ce dernier est donc notre interface entre l'utilisateur et le PIC.

Pour ma part je suis parti dans l'option minimaliste suivante :
Un Bouton poussoir et deux leds. Le bouton pour ordonner au PIC le changement d'état de l'aiguillage et les deux leds pour indiquer la position de l'aiguillage commandé :

Donc, en terme d'entrées/sorties (E/S) nous avons besoin pour chaque aiguillage :
(E) De connaitre l'état du bouton (fermé / ouvert) : 1 ligne
(S) D'allumer les deux LED en fonction de la position de l'aiguille : 2 Lignes
(S) De piloter l'aiguillage pour faire bouger l'aiguille : 2 Lignes

Au final nous avons 5 lignes par aiguillage et donc 4 aiguillages max par contrôleur (21 lignes de disponibles)
Enfer et damnation une bête de course pour 4 aiguilles, j'en vois qui râle : Pourquoi ne pas avoir pris un 40 pins ? Réponse : Ben si on est pas capable de gérer correctement nos lignes autant prendre un dsPIC dédié au traitement numérique avec 100 E/S....

Autre point concernant les LEDs : Il faut délivrer (en général) 3v à 20ma. C'est bien, les PIC peuvent sortir 25ma sur une ligne : c'est le premier exemple de montage que l'on nous propose à tout va. Cependant n'espérez pas lui faire sortir 20ma sur l'ensemble des lignes en même temps sous peine de le cramer ! Il ne peut encaisser que 200ma max soit 5/6 leds en prenant de la marge. Si j'arrive a doubler le nombre d'aiguillages on va donc avoir des problèmes (c'est ballot non ?)

Si je résume la situation : On manque d'E/S et on consomme trop sur les LED.
C'est bien de râler mais maintenant va falloir trouver des solutions !

1) Manque d'E/S
Bien on ne peut pas en créer (Ok si avec ce que l'on appelle un « extendeur de port » mais c'est trop facile et je veux pas commencer a utiliser le BUS I2C pour ça sinon on a pas finis).

La règle N° 1 : Si on se pose une question, quelqu'un a sûrement déjà eu le même problème et trouvé une solution : Autant aller la chercher !

a) Les aiguillages : Au lieu d'utiliser des « moteurs» à deux bobines (ou deux fils mémoire), pourquoi ne pas suivre l'idée de F.GODEFERT dans « des moteurs d'aiguillage à 1,99€:Le schéma » et utiliser des relais automobile pour contrôler nos aiguillages avec une position de repos en l'absence de courant et une position de travail. Et hop ! On double le nombre de sorties, sans les mains !
Ok tout le monde ne souhaite pas avoir des relais ou un aiguillage avec une position de repos...

b) Les LEDs : On a doublé les aiguillages mais on a plus de lignes pour les LEDs maintenant ! Et on va manquer de jus car on va tirer jusqu'a 160ma sur le PIC avec 8 aiguilles.
Pour le nombre de LED la solution est toute trouvée grâce à P'tit train et Fribotte où l'on apprend que l'on peut piloter 2 LEDS avec une seule ligne !
Le schéma retenu :

Le principe :
- Lorsque l'on configure la ligne E/S du PIC en sortie avec une valeur à 0, elle est connecté à la masse et la LED 2 est allumée.
- Lorsque l'on configure la ligne E/S du PIC en sortie avec une valeur à 1, elle est connecté a Vdd = 5v et la LED 1 est allumée.
- Lorsque l'on configure la ligne E/S du PIC en entrée aucune LED n'est allumée (mais un courant est gaspillé entre les résistance R1 & R2).
Et si on bascule très rapidement entre les deux premiers états, c'est comme si les deux LEDs étaient allumées en même temps (mais elles brillent moins que si elles étaient seules).
Dans notre cas seul les deux premiers états nous sont utiles : on aura toujours une seule LED allumée par aiguille.

2) La consommation des LEDS : On va aller chez sonelec-musique : Alimentation d'une LED plus particulièrement à la fin de la page avec le chapitre « Les LED dans les montages alimentés par pile » (vous lirez la suite après ok ?). Ce que j'ai retiré de celui-ci: On peut envisager d'alimenter des LEDs avec un courant de 1ma au lieu des 20ma nécessaire et obtenir un éclairage acceptable... 1 ma ça résoud très largement nos problèmes : 8ma pour 8 LEDs.... C'est bizance !
Alors je n'ai pas pu attendre, je me suis procuré entre autre des LED soit disant à « 30 000 MCD » sous 3,1V 30ma (clairement ça « crache » Donc attention danger ! !). Je suis monté jusqu'a R=18ko avec 5v en entrée soit un courant calculé de : 100uA (l'ampèremètre déclarait forfait....) et je trouvais que c'était encore un poil trop fort..... Impressionnant.

Dernier effort, les boutons poussoir :
J'ai trouvé mon bonheur sur la page suivante : 7 switches with 1 A/D pin et quel bonheur.... Jusqu'a 15 boutons sur une seule ligne de PIC !
La solution se base sur une répartition savante de valeurs de résistance et la lecture du voltage résultant sur une ligne Analogique du PIC. Du plaisir en perspective pour le décodage dans le programme...

Au final, je suis revenu a :
- 2 lignes pour un Relai
- 3 lignes pour un « Minitrix »
+ 1 ligne commune pour tout les boutons
Soit 9 aiguillages « relai » ou 5 aiguillages « Minitrix » (ou un melting pot des deux).
En récupérant les 2 lignes série je pourrais même pousser jusqu'a 6 aiguillages « minitrix » ...

C'est la fête au village ! Et ça en valait le coup non de lui faire sortir les tripes à ce PIC !
Dans la version proposée ici je me suis contenté de 8 sorties (ça faisait un compte rond).
=>Mais a mettre a niveau dans une prochaîne version.

Ah.. Dernier point : Afin de limiter la consommation (hum..) et ne pas trop soliciter les bobines, l'alimentation des aiguillages est temporisée et paramétrable :
- Pour les « Minitrix » chaque état est maintenu pendant 1s par défaut.
- Pour les Relai en position « de travail », celle-ci sera maintenue pendant 15s par défaut.
Mais chaque appui sur un bouton bascule l'état de l'aiguillage quelque soit le timer (si le Relai était en travail il est immédiatement coupé et les LEDs correspondantes mises à jour)

C)L'électronique

Le schéma électronique :

Vue de dessus du typon et des composants :

Le principe : On a la carte principale sur laquelle vient se greffer les modules :
- MicroContrôleur
- Aiguillage

Le premier a été vu au chapitre précédent, le second c'est maintenant.
C'est un schéma relativement simple basé sur un MOSFET N Logique piloté par une sortie d'aiguillage du PIC (Ok j'ai sorti l'artillerie lourde mais attendez..)

Le typon a deux particularités :

1) Au lieu d'un MOSFET on peut très bien utiliser un transistor Darlington NPN genre TIP121 (On réajuste la résistance R1 et on laisse R2 ouvert)
2) Pour la diode de roue libre (qui sert a protéger le MOSFET / TIP des retours de courant de la bobine), j'ai prévu une double implémentation CMS ou traditionnelle comme ça tout le monde est content. Et les derniers râleurs pour les résistances : 1 trou dans chaque PAD CMS et hop ! en position verticale...

Sinon double alimentation : 12V (ou 15v) pour les aiguillages, 5V pour les LEDS et le microcontrôleur.

Au niveau des sorties LEDs & Boutons il faudra faire un peu de soudure sous le TCO
=> Pour les boutons il faudra relier une des pattes de chacun des boutons à la masse et l'autre à une des 8 « sorties boutons » .
=> Pour les LEDs, Il faudra bien faire attention a les relier entre elles tête bêche ensuite peut importe (enfin a 100uA je pense qu'elles ne devraient pas trop souffrir d'une erreur)

Ensuite il faudra que je fasse un tableau de répartition des différentes E/S: LEDS,boutons,aiguillages et relier correctement tout ça pour que lorsque l'on appui sur un bouton, ce ne soit pas un autre aiguillage qui soit actioné et la LED d'un troisième allumée... Et bien préciser les LEDs allumée en position de repos pour les aiguillages « Relais » .

D)Le programme

Comme dit en introduction, je ne l'ai pas encore réalisé pour ce montage. En revanche j'ai déjà finalisé un programme équivalent pour un PIC 16F690 sous MikroPascal de Mikroe, donc je sais où je vais et comment je vais m'y prendre.

Si je résume les grandes lignes du programme :

A) Initialisations

1. Initialisation du PIC (Configuration des entrées/sorties, des timers)
   
2. Initialisation des aiguillages Késako ? Ben les relais : y'a pas de problèmes : ils sont en position de repos si on ne les alimente pas mais pour les « Minitrix » on ne peut pas savoir dans quel état ils sont au démarrage, donc on les force a un état par défaut pour être sur de leur position.
   
3. Initialisation des variables du programme.
   
4. Initialisation des LEDs On affiche toutes les leds en mêmes temps (qq secondes) pour montrer qu'on est les maîtres du Dieu Ampère et surtout pour vérifier visuellement que toutes les LEDS sont fonctionelles

B) Boucle principale

1. Lectures des états des boutons (enfin décryptage...)
   
2. Mise a jour des états des relais en fonction des boutons lus.
   
3. Contrôle si expiration du temps de mise en tension pour chaque relais et arrêt des sorties d'aiguillage le cas échéant.
   
4. Mise a jour des sorties LEDs en fonction de l'état de chaque aiguillage

on boucle....

Voilà rien de bien sorcier, mais il faut tenir compte du type d'aiguillage qui influe sur le comportement du système :
- Pour les aiguillages « Minitrix », lorsque le temps de mise en tension est écoulé (1s par défaut) on « éteint » la sortie d'aiguillage (on la met a zéro). Les LEDs correspondantes reste dans leur état.
- Pour les Relais, lorsque le temps est écoulé (ou que l'on appui une seconde fois sur le bouton avant la fin du compteur de 15s), on « éteint » la sortie d'aiguillage mais l'état des LEDs dois être inversé car le relai repasse alors dans sa position de repos et l'aiguillage est donc modifié.

Finallement il y a beaucoup de cas à prendre en compte, et adptabilité oblige je vais gérer tout ça avec un maximum de paramétrage via l'EEPROM des PIC. Cela permettra de configurer finnement les particularités de son réseau sans avoir a mettre les mains dans le camboui grâce au futur Bootloader et ça donnera quelque chose comme ça :


Conclusions
Voilà la présentation du premier contrôleur terminée. N'hésitez pas à me faire part de vos critiques et suggestions !

Prochaîne étape : Le contrôleur de détection (Détection d'un convoi sur un canton ou portion de canton)

@+

Denice

.

Voila qui semble bien parti !

Je trouve très intéressant que chaque bricoleur invente sa solution et quelle ne ressemble à aucune autre, aussi bien en terme d'architecture générale que dans les détails.
Et cela vaut aussi aussi pour le logiciel (langage et environnement de développement)

Je vais suivre la suite avec beaucoup d'intérêt et d'attention.

Comme SavignyExpress, je suis plutôt AVR et mon chouchou est l'atmega8 et ses cousins, développement également sous Linux,............ ce qui n'enlève rien à la famille PIC!

Question subsidiaire : Est ce que tu as un réseau ou un projet de réseau?

3. LE CONTRÔLEUR DE DETECTION

A)Introduction

Second module de contrôle du projet : Le contrôleur de détection. Je n'aime pas trop le nom, mais contrôleur de CANTON ça empiète un peut sur le dernier module qui gère la vitesse. Mais les deux sont intimement liés (j'y reviendrais).
Ce module est chargé de détecter la présence d'un convoi sur un canton (ou une portion de canton si on isole deux portions de voies alimentés par un même contrôleur de vitesse).
Pour ce module, la difficulté que j'ai dû surmonter était de trouver les différentes techniques de détection de convoi et déteminer laquelle est la mieux adapté à mon projet et si possible en avoir une totale maîtrise : Ne pas repomper bêtement le schéma d'un autre sans en comprendre le fonctionnement technique..

Je vais vous présenter dans un premier temps le module, pour continuer sur la partie électronique et finir encore une fois sur le programme du PIC (Enfin toujours les grandes lignes qui sont très simple ici).


B)Présentation du module

Ce module permet donc de contrôler, enfin surtout centraliser la détection des convois au sein du réseau pour ensuite gérer des LEDs sur un pupitre de commande/TCO.

Notre précédente expérience avec les LEDs fait que nous n'avons plus à nous soucier de leur nombre, reste la détection des convois,

J'ai dû passer deux longues journées complète à surfer sur le net à la recherche des différentes méthodes déjà utilisées. Je n'avais vraiment aucune idée bien établie sur le sujet (ormis les méthodes « physique » de l'ILS, barrière infrarouge & co..).
Et j'ai ensuite encore passé 3 longues journées à chercher et comprendre comment la solution retenue, pourtant simplissime au deumeurant, pouvait fonctionner.... (J'aurais dû ouvrir un post plus tôt ici )

Mais commençons par les pré-requis :

• Choisir une méthode discrète car facilement intégrable partout (exit les diverses « barrières » ).
  
• Etre fiable (Exit l'ILS et autre barrières, qui ne détecte plus le convoi une fois passé).
  
• Gérable par un PIC.
  
• Si possible être capable d'identifier le sens de marche du convoi (ben oui : pourquoi se contenter que du beurre ? )
  
• Compréhensible et d'un fonctionnement complètement maîtrisé.

Rapidement j'ai donc laissé de coté les méthodes electro-techniques (qui n'ont rien a démériter mais ne me convennait pas). Et je me suis intéressé à du pur électronique. J'ai d'abord surtout trouvé beaucoup « d'anciens » schémas (mais toujours d'actualité) complexes d'un point de vu électronique pour une quiche comme moi. Ou alors d'autres schémas adaptés à du digital DCC mais pas à de l'analogique.

Finallement la solution est arrivée par petit bouts, des références, des blogs, des images de solutions commerciales passées à la loupe en l'absence de schéma.
Un Blog m'a mis sur la voie: The block occupancy detector faisant référence à un schéma sans citer la source néerlandaise et sans que l'auteur sache comment il fonctionne... Donc j'ai continué à chercher un vrai connaisseur pour finir par trouver le meilleur site décrivant celle-ci (et sous de très diverses formes) l'excellent mais anglophone : R.PAISLEY : Optoisolator Type Block Occupancy Detectors
La méthode :La détection de courant
Sur ce site je me suis intéressé particulièrement aux chapitres : « Basic Detector » & « Direction Indicating Detector ».
Bon vive la rédaction en live! J'ai finallement mis le doigt sur la source néerlandaise à cet instant en cherchant le nom de l'image dans google image: sur ce site en fin de page. Il fait référence à un schéma de Hans Deloof... Recherche.. Bingo un amateur de N et sa page : Hans Deloof Choississez la langue et allez dans « Current detection », avec schéma et pdf pour un détecteur 4 cantons.... plus un autre schéma pour DCC souvent rencontré et d'autres encore si vous parcourez son site très intéressant. Les joies du direct... façon web ! !

Bon je vais donc utiliser ici le schéma de Hans Deloof, plus simple et proche de notre approche PIC, mais le schéma de R. PAISLEY est a garder car ma solution a été d'utiliser une version mélangée des deux :
- La solution de R. PAISLEY est plutôt faite à l'origine pour de l'électronique « analogique » (sans uC).
- La solution de Hans Deloof ne détecte pas le sens du convois.

Simplissime non ? J'en aurais jamais rêvé... Je veux bien vous payer un bière si vous me dites comment ça marche (Aucun des deux ne s'étend dessus, c'est peut être du niveau de base de l'électronicien, mais moi j'ai mis trois jours avant de trouver la réponse grâce à ce site anglophone : AllAboutCircuits : Clipper Circuits en milieu de page sur le symetrical clipper, car ce sont les diodes et leur rôle qui m'ont tout de suite interpelé sans que je comprenne pourquoi elles étaient par deux, tête bêche et quel en était l'impact sur le circuit.
Je savais que les diodes bloquent une partie de la tension (0,7v - 1v) appelée tension de seuil. Mais ça n'est qu'avec ce petit shéma que j'ai vraiment fait le lien avec notre détecteur :

Ce qui nous intéresse, c'est la tension au point 2 (en bleu) qui, rapporté à notre détecteur de courant, correspond à la tension en entrée de l'optocoupleur (En ignorant la résistance R2...). Cette tension n'est rien d'autre que la tension de seuil des diode lorsqu'il y a un courant, ce qui déclenche l'optocoupleur... Ahh oui dis comme ça effectivement c'est bêtement efficace...
Dans les détecteurs, il y a deux résistances avec l'optocoupleur: une en série(R2) pour limiter la tension en entrée de l'opto, et une parallèle(R1) pour limiter le courant, ainsi on a une complète maîtrise de l'entrée de l'optocoupleur. Hans Deloof a par ailleurs ajouté deux condensateurs de part et d'autre de celui-ci pour limiter les micro-coupures, inévitables avec un train roulant.
En utilisant deux diodes en série on double la tension de seuil (1,4v - 2v) et selon la doc de Hans Deloof, il conseille d'utiliser 3 diodes pour le N à cause des faibles courants. En étudiant les diodes utilisées par ce dernier (des BYV28) enfin surtout leur fiche technique on constate que la tension de seuil varie en fonction du courant (de 0, 5v à 1v jusqu'à 3A). Effectivement avec nos petits moteurs, on est « charrette » pour respecter les spec de l'optocoupleur ILQ620 (min. 1v).
Quand on comprend le schéma on est plus spectateur mais acteur !

Pour notre module j'ai plutôt retenu les diodes 1N54xx (peut importe la tension max des diverses versions prendre les moins chères !). Elle étaient utilisées dans un schéma équivalent vu sur le net mais elles ont en gros les mêmes tensions de seuils que les BYV28. Et pour l'optocoupleur, le passe partout 4N35 qui ne fonctionne que dans un seul sens contrairement a l'ILQ620. Mais rappelez-vous, quitte à avoir le beurre (c'est fait) autant avoir aussi le sens du convois avec deux 4N35 tête bêche....

Les deux dernières remarques avec cette technique :
- Il faut toujours laisser un courant minimal sur le canton pour pouvoir détecter un train même a l'arrêt (A voir avec le prochain chapitre)
- Il faut graphiter les essieux des wagons pour que ceux-ci participe à cette détection (ou pour que l'on puisse détecter des wagons seuls sur un canton).



C)L'électronique

Le schéma électronique :
Pas grand chose à dire.... ça n'est que de la connectique (C'est presque du gachis de faire un typon pour ça... A voir si on ne peut pas utiliser une plaque d'essai plus rentable ?)


Vue de dessus du typon et des composants :


Le principe : On a la carte principale sur laquelle vient se greffer les modules :
- MicroContrôleur encore et toujours.
- Detecteur

Pour le premier .... Ok je reviens pas dessus.
Pour le second, le schéma est donc un mix de R.Paisley et Hans Deloof (mais plus proche du second). Les tests me permettront de mieux affiner le résultat.

et le pcb:

Simple, pour une fois le placement automatique a été plus efficace que moi.
Mais je vais faire une version prototype sans cms pour les allergiques (Pour les tests je vais peut être me borner à une boîte de connection dans un premier temps pour étudier les meilleures valeurs).
Les connecteurs comportent beaucoup de pattes reliées à la masse, car je voulais en avoir un minimum afin que le branchement soit stable.

Les deux sorties sont a relier à un rail d'une part et a la sortie du module de vitesse du canton normalement relié à ce rail (Le détecteur s'insère donc entre le rail et une des deux sorties du module de vitesse). Mais ce point sera revu avec ce module.

Pour les sorties LEDs, c'est la même technique que celle vue au précédent chapitre : 2 Leds pour une seule sortie PIC. Pour ceux qui se moque du sens, on pourra configurer le programme afin qu'il ne travaille qu'avec une LED.


D)Le programme

Bon... Là le programme va être très réduit, il n'y a pas vraiment d'interraction ni de calculs complexes ici.
Le 18F2520 est très surdimenssioné pour cette tâche, il lui faudrait trouver un alter-ego plus rentable sauf si vous en avez trouvé une brouette a bas prix (je suis preneur).

A) Initialisations

• Initialisation du PIC (Configuration des entrées/sorties, des timers)
  
• Initialisation des variables du programme.
  
• Initialisation des LEDs On affiche toutes les leds en mêmes temps (qq secondes) pour montrer qu'on est les maîtres du Dieu Ampère et surtout pour vérifier visuellement que toutes les LEDS sont fonctionelles (ôo le copié-collé)

B) Boucle principale

• Lectures de l'état des 6 détecteurs
  
• Mise a jour des sorties LEDs en fonction de l'état de chaque détecteurs

On boucle...

ça va être violent !

Conclusions

Voilà la présentation du second contrôleur terminée. N'hésitez pas à me faire part de vos critiques et suggestions !

Prochaîne étape : Le contrôleur de vitesse/canton(Vitesse et sens des trains)