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 ... 86 87 [88] 89
1306
Bibliothèques / Re : Bibliothèque CommandInterpreter
« le: juillet 25, 2015, 12:05:06 pm »
Je viens de tester cette bibliothèque dans mon programme de tests de performances du CAN pour réaliser diverses fonctions comme un affichage complet ou non des messages échangés, l'affichage des compteurs émis/reçus/perdus ou la variation du delay entre émissions (donc la fréquence des envois de messages)

J'atteste que ça marche nickel !!!
Bravo Jean-Luc  ;D

1307
Shields et Modules / Re : Carte « Cerveau du réseau »
« le: juillet 25, 2015, 09:57:07 am »
Citer
Concernant la connectique DCC, dites moi ce qu'il faut exactement :)

Je réagit à retardement : il est super ce fil !

Pour le DCC, si on utilise un booster simple externe comme le module LMD18200 que j'ai décrit dans la centrale va et vient, il suffit de 2 fils PWM et DIR, + les entrées mesure de courant et alarme température, ainsi que le 5V et le Gnd, soit 6 fils.

Dans mon architecture le cerveau qui est un DUE avec CAN peut très bien se retrouver partie de ce projet, combiné par exemple avec le générateur DCC.

J'ai fait quelques tests de performance du CAN entre un UNO et un MEGA2560 : on peut allègrement dépasser les 50 messages par seconde et à 100/s il y a quelques pertes mais avec un accusé de réception ou d'exécution, ça peut s'arranger.
Coté DUE les performances doivent être meilleures.

Pour moi, le "cerveau" doit avoir aussi quelques interactions avec les animations dans le décor (gestion du temps accéléré, de l'éclairage ambiant, …) en relation avec un autre Arduino pour les exécutions. Le bus CAN est là : pas besoin d'interfaces supplémentaires.

Effectivement une EEPROM est nécessaire !


1308
Shields et Modules / Re : Alimentation traction de canton (analogique)
« le: juillet 25, 2015, 09:33:58 am »
Cette carte est de toute beauté et je connais la qualité du travail d'Electrodragon !

Comme mon réseau comporte une ligne va-et-vient entre 2 gares terminus, que cette ligne est isolée du reste avec coupure des 2 rails et un relai, j'ai le choix de faire l'automatisme soit en digital, soit en analogique.

Je décide donc de faire les 2 :
- améliorer le va et vient digital pour faire suite aux articles du site
- faire une version analogique car j'ai des machines difficilement digitalisables

As-tu un schéma et une liste de composants ?
Le pied serait de voir faire les 2 avec la même carte !!!

Merci d'avance
Dominique

1309
Vos projets / Re : Nouveau projet : un petit locodrome
« le: juillet 22, 2015, 07:05:01 pm »
Je te propose le tracé ci-dessous, comme tu l'as décrit.

Il y a donc 2 zones d'aiguilles qui encadrent 2 cantons qui peuvent être des quais de gare où les trains peuvent/doivent s'arrêter.
De chaque coté, la boucle ovale se referme, par exemple avec 2 cantons, ce qui permet de stopper un train à l'arrière à l'endroit du détecteur.

Un diviseur scénique peut couper la vue au milieu et cacher la voie située derrière.

Au total il y a donc 7 coupures et 4 cantons. Si tu choisis des détecteurs de consommation, seulement 4 détecteurs suffisent.

Cela permet de faire circuler 2 ou 3 trains sans difficulté :
- 2 trains peuvent faire un tour et s'arrêter sur l'un des 2 quais, chacun à leur tour.
- ils peuvent même tourner en sens inverse
- avec 3 trains, l'un des trains s'arrête derrière le diviseur scénique et attend la libération d'un quai pour finir son tour

Dans le cas où il n'y aurait que 2 trains, 3 capteurs pourraient suffire. Mais pour gérer 3 trains, les 4 capteurs sont nécessaires.

Si la gestion des trains est analogique, avec 2 trains, une seule alimentation serait suffisante : dans ce cas il faut couper l'alimentation du quai où se trouve le train qui doit attendre en gare le retour de l'autre.

Un automatisme Arduino doit être amusant à réaliser !

1310
Présentez vous ! / Re : Bonjour de Savignyexpress
« le: juillet 12, 2015, 11:01:52 pm »
Bonjour Marc-Henri,

Je n'avais pas pris l'habitude de participer à cette rubrique  :-[

Mais la présence de Savignyexpress parmi nous me fait grand plaisir : j'ai souvent regardé et me suis inspiré de tes réalisations et j'apprécie tes contributions sur le Forum du N, et maintenant sur Locoduino.

Bienvenue !

Dominique


1311
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.

1312
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 ?

1313
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

1314
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

1315
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

1316
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

1317
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).


1318
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é.

1319
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 ?

1320
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é.

Pages: 1 ... 86 87 [88] 89