Messages

1291

Bibliothèques / Re : Sauvegarde de l'état en EEPROM

« le: avril 26, 2015, 09:43:37 am »

Bonjour,

La durée de vie de l'EEPROM reste un vrai problème. Si ele doit mémoriser tous les changements d'état si le réseau est piloté par ordinateur, ça fait vraiment beaucoup d'écritures. Les données constructeur sur la durée de vie sont assez conservatives et ça ne m'étonne pas que l'on puisse arriver à un million. Mais rien ne prouve que ca sera systématiquement le cas.

SavignyExpress m'avait déjà parlé de cette solution et l'idée d'en faire une bibliothèque permettant son exploitation de la manière la plus transparente possible est séduisante. 

1292

Shields et Modules / Re : Carte « Cerveau du réseau »

« le: avril 26, 2015, 09:35:21 am »

Bonjour,

La carte ayant la connectivité nécessaire pour l'analogique et le DCC, elle peut effectivement commander les deux systèmes simultanément. C'est une affaire de logiciel.

Toutefois je ne vois pas comment gérer le passage d'un canton géré en numérique à un canton géré en analogique. Pour moi ce sont deux technologies incompatibles quand on arrive aux rails. Mixer les deux a coûter la vie à Driving Railway 

Concernant l'extensibilité, un Due peut gérer allègrement plusieurs centaines de cantons. Par conséquent quel serait l'intérêt ?

Le Bluetooth est plus léger que le wifi et puis les UART Bluetooth sont plus répandues et plus éprouvées.

Concernant la connectique DCC, dites moi ce qu'il faut exactement

1293

Shields et Modules / Re : Carte « Cerveau du réseau »

« le: avril 23, 2015, 09:02:01 am »

Je me réponds 

En creusant, je me rends compte que le Due ne dispose pas d'EEPROM intégrée. Or ça me semble nécessaire de stocker l'état du réseau à l'extinction pour éviter une très fastidieuse séance de mise marche surtout pour un grand réseau.

Il faut donc rajouter une EEPROM externe en I2C par exemple. Un peu moins de 1€ pour une 32ko

1294

Shields et Modules / Re : Carte « Cerveau du réseau »

« le: avril 23, 2015, 08:17:55 am »

Oui, les deux ligne séries sur les connecteurs resteront libres. Il y en a 3 autres de disponibles sur le Due

1295

Shields et Modules / Carte « Cerveau du réseau »

« le: avril 22, 2015, 05:07:23 pm »

Bonjour à tous,

j'ouvre ce fil pour déterminer les fonctions et composants à intégrer sur une carte destinée à piloter un réseau, que ce soit en analogique ou DCC.

Dans le pilotage, j'inclus le dialogue avec les Arduino en charge de :

• la détection de présence
• la commande des aiguillages
• la commande des ponts tournants
• la commande de la signalisation
• ...

Mais aussi l'anticollision, les itinéraires, la circulation automatique, la connaissance et la gestion des trains, ...

En DCC, cette carte servirait de centrale.
En analogique, elle piloterait également les cartes Traction.
Elle remplacerait le PC pour le pilotage du réseau.

L'Arduino ciblé pour cela est l'Arduino Due pour les raisons suivants :

• 512ko de Flash permettant de mettre de très gros programme et quantité de constantes de configuration du réseau.
• 96ko de RAM permettant de stocker beaucoup de données (12 fois plus que sur un Mega, 48 fois plus que sur un Uno)
• Processeur 32 bits à 84 MHz ce qui permet d'en avoir sous le pied
• 2 interfaces CAN natives

Le prix n'est pas un problème puisque le Due serait en exemplaire unique et on trouve des compatibles Due à 15€.

Le Due serait épaulé par un Nano pour générer des signaux précis temporellement sans être embêtés par les interruptions (comptage de temps, Interruption I2C, interruptions CAN, etc). Il s'agit de générer précisément le signal DCC en DCC et les signaux de synchro pour les cartes traction en analogique. Il effectuerait également la surveillance du booster DCC. La communication entre Due et Nano se ferait par le bus SPI.

Sur cette carte 10x10cm, le Due et le Nano viendrait s'enficher par dessous. Par dessus on aurait un emplacement pour mettre un LCD 20x4. On aurait également :

• Deux transceivers CAN 2551 pour les deux CAN du due
• Des prises RJ11/RJ45 pour le CAN/CAN avec synchro analogique
• Un emplacement pour mettre une UART Bluetooth
• Un connecteur pour branche le booster (LMD18200)
• Un connecteur I2C pour déporter un LCD
• Des boutons et switches pour interagir sans PC.
• Un régulateur 9v (7809) avec radiateur pour pouvoir accepter des tensions d'alimentation plus élevées que 12v

N'hésitez pas à mettre votre grain de sel !

1296

Présentez vous ! / Re : Bonjour de Savignyexpress

« le: avril 22, 2015, 12:39:59 pm »

Et n'hésite pas à participer ;-)

1297

Présentez vous ! / Re : Bonjour de Savignyexpress

« le: avril 21, 2015, 10:11:46 pm »

Bienvenue à toi SavignyExpress. C'est un grand plaisir de te voir sur ce forum.

L'AT Tiny 2313 est supporté par l'IDE Arduino, ce qui permet de disposer de nombreuses bibliothèques : http://playground.arduino.cc/Main/ArduinoOnOtherAtmelChips

1298

Présentez vous ! / Re : Retardataire

« le: avril 20, 2015, 08:38:52 am »

Bienvenue à toi.

Je ne suis pas responsable des gros progrès. Tout le mérite revient à Pierre 

1299

Shields et Modules / Re : Re : Alimentation traction de canton (analogique)

« le: avril 19, 2015, 03:34:46 pm »

1°) CommandInterpreter ?

Voir http://forum.locoduino.org/index.php?topic=71.0

2°)

Dans la foulée j'ai créé un repository sur le gitlab de framasoft : https://git.framasoft.org/Koryphon/AlimentationTraction/tree/master

Je ne comprends pas les mots et je ne trouvais pas le lien hier.
Mais, à l'instant où j'écris, le lien remarche....
Je vais voir ce qu'il dit.

Pour le lien, c'était de ma faute, le dépôt n'était pas public  C'est corrigé

repository : dépôt pour mettre des fichiers et conserver l'historique des modifications
gitlab de framasoft : système en ligne pour gérer une dépôt git. Framasoft est un des soutiens importants du logiciel libre en France
git : système de dépôt : http://fr.wikipedia.org/wiki/Git

En substance, l'ensemble permet de mettre en ligne un logiciel en cours d'évolution.

1300

Shields et Modules / Re : Alimentation traction de canton (analogique)

« le: avril 18, 2015, 11:05:35 pm »

C'est à dire ?

1301

Shields et Modules / Re : Alimentation traction de canton (analogique)

« le: avril 18, 2015, 06:37:25 pm »

Bonjour,

J'ai bien avancé cet après-midi. Je me suis occupé de l'asservissement de vitesse. Tout fonctionne comme prévu. J'ai passé un peu de temps à mettre en place plusieurs commandes (en utilisant CommandInterpreter) permettant de jouer avec l'asservissement. De cette manière, je commande la loco et je change les paramètres au clavier 

Je suis tombé sur un os avec une CC65000 Startrain. La loco doit être munie d'un condensateur car elle démarre avec une PWM = 2 (sur 255). Il faudrait retirer ce condensateur qui empêche la mesure de vitesse. 

Pas de soucis avec les Fleischmann BR64, BR92 et BR71 (RSF), ça marche nickel. 

Dans la foulé j'ai créé un repository sur le gitlab de framasoft : https://git.framasoft.org/Koryphon/AlimentationTraction/tree/master

1302

Shields et Modules / Re : Alimentation traction de canton (analogique)

« le: avril 17, 2015, 05:49:59 pm »

Merci les gars 

Mais c'est pas tant que ça de boulot. Peut-être trois jours en tout pour dessiner cette carte.

Effectivement le MOSFET ne chauffe pas du tout mais c'est aussi dû à la commande qui charge et décharge la grille très vite.

TERM est effectivement le strap pour terminer le bus CAN. 120Ω à chaque extrémité.

J'ai testé l'inversion de marche, la PWM et la mesure de vitesse. Ce week-end, je mets en œuvre la loi de commande pour l'asservissement.

1303

Shields et Modules / Alimentation traction de canton (analogique)

« le: avril 17, 2015, 02:44:55 pm »

Bonjour,

Il y a une dizaine de jours, j'ai reçu le PCB de la carte traction à base d'Arduino Nano. Le voici :



Après quelques heures, les composants sont montés sauf le CAN :



Je vous tiens au courant des avancées ;-)

1304

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau

« le: avril 16, 2015, 04:27:28 pm »

En deux mots, le langage permet de décrire la topologie du réseau et d'associer des attributs aux différents éléments.

On décrit des section de voie de la manière suivante :

Code: [Sélectionner]

section voie_entree_2 {
  in entree
  out sortie
  length 68.4
}

la section de voie est orientée avec une entrée, in et une sortie, out. entree et sortie sont les nom des deux extrémités de la section. length donne la longueur en mm.

La fait d'avoir :

Code: [Sélectionner]

section aiguille_entree_de_gare {
  in talon
  out directe
  out deviee
  length 159.5
}

et donc d'avoir 1 entrée et 2 sorties, définit un aiguillage.

les sections sont ensuite connectées :

Code: [Sélectionner]

connect voie_entree_2.sortie
     to aiguille_entree_de_gare.talon

Puis regroupées en cantons :

Code: [Sélectionner]

#------------------------------------------------------------------------------
# Canton d'entree de gare
#------------------------------------------------------------------------------
block grill_entree_gare {
  reverse stop {
    voie_entree_1
  }
  main {
    voie_entree_2, aiguille_entree_de_gare
  }
  normal stop {
    voie_vers_gauche | aiguille_vers_zone_marchandises
  }
  power 0:0
  color yellow
}

reserve stop, normal stop et main définissent respectivement les sections d'arrêt en marche arrière et en marche avant et la pleine voie.
power permet d'associer une alimentation (en analogique). color associe une couleur pour la sortie graphique

Pour l'instant le compilateur de fait pas grand chose à part vérifier que tout est cohérent et construire le graph au format graphviz. Ce qui donne le graphe en pièce jointe pour ma gare. Je joints également la description complète de ma gare. Ça ne correspond pas tout à fait aux cantons que j'ai placés dans mon message précédent : les tiroirs n'ont pas leur propre canton mais sont mis sous tension à la demande. J'ai changé d'idée car je souhaite pourvoir éclairer les feux dans les tiroirs. D'où une alimentation propre et un canton propre. Il faut que je mette ma description à jour.

Ça donne une représentation sur laquelle travailler pour générer les données du logiciel qui gérera le réseau.

1305

Modélisation, Architectures logicielles et matérielles / Re : Re : Modélisation logicielle d'un réseau

« le: avril 16, 2015, 01:36:22 pm »

C'est la deuxième fois que tu dis "plus ou moins d'aiguillages par canton". J'aimerais que tu précises : tu "prolonges" les rails avec les contacts d'un relais ?
Parce que sinon, il faut bien détecter la présence des trains sur les aiguilles en carte B ?

Non, ce que je veux dire : mes cantons comprennent de 0 à N aiguilles. Comme je veux des cartes génériques pour pouvoir les faire fabriquer en série, elles sont indépendantes de la topologie d'un canton. C'est le logiciel qui fait le lien entre cantons et aiguillages et les manœuvre comme il faut. Par exemple voici ma gare terminus en pièce jointe. Chaque canton est d'une couleur différente :

A mon avis, en DCC, il y a quand même autre chose à gérer au niveau du canton : le sens de déplacement sur le canton.

La loco reçoit de la centrale DCC son sens de déplacement via les rails, indépendamment de la carte canton.
En gros, l'info n'existe plus dans les cartes.

Normalement si

A minima : tout est géré en carte D, en mémorisant les dernières demandes. Pourquoi pas ?

Tout à fait.

Il y a une limite du nombre de cartes par bus CAN ?

La limite est fixée par le transceiver. Le 2551 limite le nombre de nœuds à 112. Le Due a 2 CAN, autant les utiliser.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

Alors, là, c'est grandiose !!
C'est vrai qu'il "suffisait" de créer un nouveau langage avec un compilateur !!!!!!!
Ben voyons !!
Oui, je veux bien des détails.   

Ça vient