Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Dominique

Pages: 1 ... 168 169 [170] 171
2536
Vos projets / Re : Nouveau projet : un petit locodrome
« le: juillet 12, 2015, 09:06:36 am »
Effectivement, il vaudrait mieux parler de "zone" aussi plutôt que de "canton" seulement.
Les aiguilles ne sont généralement pas comptées dans les cantons (zone comprise entre 2 sémaphores).

Mais les aiguilles ici doivent être alimentées comme les autres zones.

De même, chaque canton ici pourrait être découpé en plusieurs zones: une zone de ralentissement et une zone d'arrêt. Dans les virages et au passage des aiguilles en position déviée il faut aussi prévoir une limitation de vitesse.

Après les coupures, il faut donc identifier les capteurs, d'autant plus nécessaires si ça doit être automatique.

2537
Vos projets / Re : Nouveau projet : un petit locodrome
« le: juillet 11, 2015, 11:34:10 pm »
Voilà une possibilité de coupures pour :
- un canton contenant la droite haut et la 1/2 courbe gauche/haut
- un canton contenant la droite bas et la 1/2 courbe gauche/bas
- un canton contenant la courbe droite (que tu peux couper en 2 éventuellement)
- 2 cantons pour les voies de garage

Il faut veiller à ce que les trains entrent en entier dans chaque canton.

Quel scénario de circulation automatique vois-tu dans ce réseau ?

2538
Vos projets / Re : Nouveau projet : un petit locodrome
« le: juillet 10, 2015, 10:35:50 am »
Bonjour Guillaume,

Peux-tu décrire ce que tu appelles "automatiser" ?
Par exemple démarrer, rouler, s'arrêter automatiquement, gère 2 trains, l'un attend que la voie soit libre, etc...

Je te conseille de prévoir des coupures de rails aux raccords (avec des éclisses isolantes et souder des fils sous les rails. C'est à faire au moment de la pose des rails, apres c'est trop tard !
De toute façon ça permet de garantir la meilleure alimentation possible des rails.

Bon courage
Dominique

2539
Voilà une serie de contributions fort intéressantes et concrètes  :)

Je retiens d'abord le fait que la description du réseaux ne se fait pas dans une table, mais dans chaque objet directement : chaque zone (ou canton, mais une zone peut inclure une aiguille, pas un canton normalement) décrit les connexions aux zones adjacentes.

Cela demande certainement un petit travail de préparation : est-il possible de montrer un exemple simple ?
-> ce serait le coté statique !

Ensuite chaque objet peut être personnalisé (à partir de l'héritage) ce qui laisse entrevoir la grande souplesse du modèle et la facilité d'évolution (on ne peut pas penser à tout dès le début !).

Ensuite ce modèle vit au rythme des événements (les traitements des signaux remontés par les capteurs aux passage des trains appellent-ils les méthodes des objets directement ? ).
-> c'est le coté dynamique !

Merci pour ces "devoirs de vacances" : il va me falloir un peu de temps pour imaginer mon réseau de cette façon.

Et bravo encore à Denis et Pierre de rendre cette rubrique si concrète..

Dominique

2540
Merci beaucoup Pierre,

L'intérêt de la programmation Objet s'avère particulièrement utile dans ce domaine (je ne veux pas dire qu'il ne l'est pas dans d'autres).

Tes contributions m'ont convaincu : je vais essayer de concevoir la modélisation de mon réseau de cette façon, ce qui nous permettra d'en discuter avec du concrêt.

Amicalement
Dominique

2541
C'est le schéma d'architecture le plus clair et le plus complet que j'ai jamais vu ailleurs sur le web !

Je comprend l'intérêt des deux bus, surtout si le DUE tourne avec un OS multitâche.

Un grand Merci Jean-Luc

2542
Merci beaucoup à Jean-Luc et Denis pour ces descriptions détaillées : je commence à y voir clair dans la description du réseau (table des cantons et des itinéraires chez Denis), puis dans le suivi des trains (table des trains) ainsi que la gestion des feux qui découle des tables précédentes.

Une question simple : comment s'interface la retrosignalisation ?

J'ai l'impression que les besoins en retrosignalisation sont imposés par les descriptions dans les tables. Il faut bien des capteurs pour agir sur toutes ces données y compris des capteurs par défaut que sont les Time-out.

Je suis parti sur des capteurs de consommation pour suivre l'occupation des segments linéaires et des zones d'aiguille (j'ai bien compris qu'elles sont traitées comme des cantons), et j'ajouterai des capteurs RFID pour identifier les trains (pour connaître leur adresse DCC), puis des capteurs à effet Hall à des points précis (zone d'arrêt devant un feu, position d'arrêt en gare).


2543
Ce fil se veut complémentaire du fil "Modélisation logicielle d'un réseau" dont le but est d'échanger sur nos visions et expériences sur la manière de concevoir le logiciel qui anime l'ensemble des ingrédients de notre réseau.

Nous nous plaçons dans le cas où l'Arduino a pris le pouvoir sur le réseau, qu'il a donc gagné la bataille contre le logiciel de pilotage sur PC/Mac/Linux/iOS/Android.

Comme notre réseau est colonisé par nos (pas) chers Arduino, ils sont plusieurs à se partager la tâche.
Et là, selon les choix que nous avons fait, il existe de nombreuses possibilités de combinaisons matérielles.

Par exemple, dans l'intervalle entre mon premier et mon second circuit, je voyais l'assemblage de tous les composants comme sur l'image jointe. J'y reviendrai.


Je vous invite à partager, ici, vos choix d'architecture matérielle qui, évidemment éclaireront les discussions sur le logiciel, dans le fil d'à côté.

2544
Lorsqu'on conçoit un réseau, en plus des rails, des locos et des wagons, du choix DCC ou analogique (PWM), on fait le choix d'une centrale pour commander les convois et les aiguilles. Ensuite on arrive très vite à définir des cantons et choisir des détecteurs de rétrosignalisation pour organiser la circulation des trains avec des règles de sécurité (éviter les rencontres indésirables), installer des feux de signalisation et d'avertissement, gérer des itinéraires avec des gares de départ et d'arrivée, des horaires, des annonces sonores, etc…, tout en se réservant des possibilités de commande manuelle de convois pour des manoeuvres par exemple et pour le plaisir avant tout.

Pour mettre en oeuvre tout ce joli monde, la voie la plus facile, mais la plus onéreuse, consiste à acheter des produits du commerce (centrale, détecteurs, décodeurs) ainsi qu'un logiciel sur PC qui s'occupera de tout (TCO, pilotage, automatismes, cantons, signalisation, ..). L'ennui c'est que les limites du projet sont celles du logiciel.. et du porte-monnaie.

Pour réaliser quelques économies substantielles, on peut réaliser bon nombre des modules nécessaires par soi-même (DIY). Locoduino est là pour cela.

Pour les automatismes de circulation (bloc système, signalisation, itinéraires, ..), la solution du logiciel sur PC (TrainController, iTrain, …) reste tentante mais elle implique la remontée des signaux de rétrosignalisation vers le PC une l'interface entre le PC et la centrale.

Alors pourquoi ne pas tenter de se passer complètement du PC ?

On peut construire un vrai TCO plus agréable à regarder et plus facile à utiliser qu'un écran de PC, avec ses boutons, curseurs, et Leds bien réels. D'accord, il y a beaucoup de fils à souder, mais le résultat en vaut la peine !

Reste enfin le logiciel qui va gérer l'ensemble de la circulation, la rétrosignalisation, la sécurité, la signalisation : Est-ce possible avec un Arduino ?

L'expérience de mes 2 premiers minuscules réseaux m'a conduit à des solutions très spécifiques, pas généralisables vers des réseaux plus grands. Je cherche donc une modélisation logicielle plus sérieuse.

La lecture de quelques documentations des solutions du commerce me conduisent au principe suivant : La rétrosignalisation est caractérisée par un ensemble de procédures et de composants qui permettent à l’unité de commande du TCO de connaître ce qui se passe sur le réseau et, en conséquence, d’exécuter des actions paramètrées associées à ces évènements.

La modélisation ne serait donc qu'un simple (mais énorme) automate qui associe une ou plusieurs actions à chaque événement. Ce qui sous-entend un satané programme de configuration !

Pas si simple : il faut en outre une définition du réseau (cantons, aiguilles, signaux, distances, vitesses limites, priorités) sur laquelle se superpose les positions et les mouvements des trains (donc aussi une définition des trains). Les interactions sont très nombreuses !

Alors connaissez-vous de la littérature pour atteindre ce but, des documents même théoriques ou des bibliothèques logicielles qui pourraient m'aider ?

2545
Infos et bonnes affaires / Re : Du WiFi à 6,95$ chez Sparkfun
« le: avril 08, 2015, 06:13:08 pm »
Je pense que le module Sparkfun devrait être plus fiable et mieux documenté.

2547
Composants / Re : Un nouveau composant prometteur : le VL6180
« le: février 16, 2015, 10:31:14 am »
Oui tu as raison, il faut monter les capas, le régulateur et l' i2c. Ce serait un breadboards adapté au train miniature.

2548
Composants / Re : Un nouveau composant prometteur : le VL6180
« le: février 16, 2015, 09:31:27 am »
L'idéal serait de le trouver soudé au bout d'une petite nappe comme les caméras pour le RPi ou certains décodeurs DCC.

Je connais un gars qui soude des fils sur des leds CMS microscopiques (au microscope d'ailleurs)
J'essaierai un de ces jours.

2549
Composants / Un nouveau composant prometteur : le VL6180
« le: février 15, 2015, 09:08:37 pm »
https://cdn.sparkfun.com/datasheets/Sensors/Proximity/VL6180_ApplicationNote.pdf
On le trouve en breakout à 14$50 chez Sparkfun, mais le mieux serait de le placer seul dans le décor car il mesure 4.8 x 2.8 x 1.0 mm
Il remplace les détecteurs Sharp infrarouge au moins 10 fois plus gros

il mesure des distances de 1 à 50 cm (plutôt moins de 20 cm)

Je vois plein usages dans les trains échelle N :

Detection de train devant un heurtoir
Arret précis des trains
Déclenchement d'animations


2550
Bus CAN / Re : BreakoutBoard CAN
« le: janvier 24, 2015, 04:29:17 pm »
C'est vrai que ce n'est pas plus compliqué que l'I2C.
Je n'ai pas eu le temps d'étudier les principes. Si je comprend bien l'exemple fait un envoi avec l'id 0x00 et tous les récepteurs reçoivent la même chose.
Comment spécifier un récepteur spécifique ? La réponse doit être "avec les filtres" je suppose.

Pages: 1 ... 168 169 [170] 171