Messages récents

Pages: [1] 2 3 ... 10
1
Je n'y ai jamais bien réfléchi, mais les boucles de retournement posent-elles un problème pour le déplacement des trains sur le locodrome ?

Bonjour

Sur la base du Locodrome je n'ai écrit que deux TCOs, le mien et celui de Dominique, ni l'un ni l'autre n'ont de boucles de retournement, donc je n'ai pas trop réfléchi au problème.

Bien que revenant à peine de vacances à la montagne, j'ai écrit un "démonstrateur" pour faire des tests dans le cas le plus simple. Il reste encore pas mal de petits problèmes techniques.

Amicalement

Pierre
 
2
Infos et bonnes affaires / Re : Réseau échelle N de Canfran
« Dernier message par DDEFF le Aujourd'hui à 11:15:19 am »
Bonjour,

Je ne pourrais pas non plus le voir là-bas (j'habite Montpellier...), mais c'est une bonne nouvelle.
Et pour toi, comme Loco Revue à Auray, tu peux y aller "en chaussons"  ;)

Denis
3
Présentez vous ! / Re : Nouvel adhérent
« Dernier message par Dominique le mars 25, 2017, 10:53:09 pm »
Bienvenue Hervé  :D

Nous avons hâte d'en savoir plus sur ton projet et surtout ce que tu souhaiterais trouver dans Locoduino et qui manquerait éventuellement.

As-tu lu les articles sur l'architecture ?

Bon courage et à bientôt (à Lille peut-être, car nous y serons)

Cordialement
Dominique
4
Infos et bonnes affaires / Re : Réseau échelle N de Canfran
« Dernier message par train56 le mars 25, 2017, 08:51:41 pm »
bonsoir,

Ce réseau sera visible à Séné ( banlieue de Vannes 56) lors de notre 8°salon le 8 et 9 avril 2017

Amicalement
Hervé
5
Présentez vous ! / Nouvel adhérent
« Dernier message par train56 le mars 25, 2017, 08:46:55 pm »
Bonjour à tous,

Comme mon identifiant le laisse supposé, je suis dans le morbihan pas loin de Vannes, je fais du modélisme ferroviaire et  les systèmes numériques m'intéresse, car je suis en train (!!) de réaliser circuit qui sera digitalisé. Donc ce sont surtout les applications dans ce domaine qui m'intéresse, je ne fais pas abstraction de la partie apprentissage de programmation qui est indispensable. Je suis membre d'un club de Vannes qui possède deux réseaux numérisés par le logiciel RRTC et une centrale Roco, donc je ne pars pas de zéro.
Cordialement
Hervé
6
Bonjour Pierre,

Je n'y ai jamais bien réfléchi, mais les boucles de retournement posent-elles un problème pour le déplacement des trains sur le locodrome ?

Amicalement
Denis
7
C'est un bon début  :D

Si tu arrives à génèrer (sous forme de texte) les lignes de programme des méthodes des objets, alors tu auras gagné !

Amicalement
Dominique
8
Bonjour Dominique,

J'ai résolu une partie de ton problème (la plus simple) :
Voici le programme locodrome original (l'ovale et 2 aiguilles) pour l'Arduino.
J'ai créé un onglet Specifs.h dans ce programme Arduino et j'y ai mis tout ce qui est spécifique à ce réseau.
C'était d'autant plus simple que Pierre avait tout bien groupé. Merci Pierre  ;)

Au passage, il faut aussi déplacer les #include du .ino dans cet onglet.

Et, pour finir, on met un #include "Specifs.h" dans l'onglet .ino, justement pour pouvoir accéder à tout ce qu'on vient de déplacer.

L'onglet que je viens de créer correspond au réseau locodrome original. C'est pour l'exemple.
Pour ton réseau, on crée un autre onglet "Specif.h"... spécifique à ton réseau.

Le programme Arduino reste le même, quel que soit le réseau : il n'y a que l'onglet "Specifs.h" qui change.  8)

Mais pourquoi est-ce important ?

Parce qu'un onglet "Specifs.h", finalement, c'est un simple fichier texte.
Et, un fichier texte, on sait le générer dans Processing.

C'est ce que j'ai fait avec un "Specifs.h" pour la description de réseau de Jean-Luc (voir le fil correspondant).
Il "suffit" de faire pareil avec la description type locodrome...
Bon, mais, ça, c'est mon problème. Là, effectivement, ça n'est plus simple, mais j'y arriverais.

yapuka  :P

Denis
9
Q : Comment vois-tu la suite du programme ?
R : Il reste quelques bugs à corriger, puis je m'attelle à la description du réseau.

1°) Chaque cube va avoir une étiquette qu'on devra mettre à la main.
-> Pour les branchements (terme officiel SNCF), normalement 1 seul cube (sauf cas particuliers)
-> Pour les cantons, on sélectionne tout les cubes d'un canton et leur donne une étiquette en une fois (heureusement !  ;))
Tout ça marche déjà, mais il faudra que j'y ajoute la plaque tournante.

2°) On a donc pour un canton un ensemble de cubes qu'il va falloir ordonner. Et là, ça se complique puisqu'il faut connaître les coordonnées x y exactes de chaque extrémité de "rail" dans un cube, quelle que soit son orientation et son zoom…
Cette partie là aussi est faite, mais il faut que je voie pour la plaque tournante, assez spécifique.

3°) Une fois les cubes ordonnés, on a donc une origine et une extrémité x y de canton et, donc, on peut "abouter" automatiquement les cantons et les cantons aux branchements.
Donc, vérifier que tout ça est toujours OK, surtout après le changement de niveaux !

4°) A ce stade, je sais quel est le canton/branchement (= l'élément) qui précède ou suit un canton/branchement.

Précède ou suit … physiquement.
Exemple : un branchement a physiquement une origine et deux extrémités physiques, dans tous les cas.

Le rôle du gestionnaire de réseau sera de donner un élément suivant ou précédent à un élément donné, mais cette fois de façon logique.

Exemple : suivant la position de l'aiguille, un branchement a, cette fois,  une seule origine et une seule extrémité logique.
Par extension, une fois l'itinéraire choisi, un canton d'entrée de gare a un seul canton d'extrémité logique : la voie d'arrivée de la gare.

5°) Prochaine étape : justement, définir les itinéraires.
Je n'utiliserai pas la méthode du locodrome qui suppose de les décrire tous à la main et de leur affecter un bouton. On a déjà 8 boutons pour deux aiguilles.
Le locodrome est un formidable outil pédagogique, mais cette partie n'est pas à étendre pour un grand réseau.

Ce sera une méthode nouvelle, compatible locodrome, qui utilisera ce qui était bien dans la méthode SGDD, dans celle de Jean-Luc et celle de Pierre. Voir à ce sujet : http://forum.locoduino.org/index.php?topic=167.60

Mais il faut la développer parce que toutes ces méthodes n'étaient que des ébauches.

Évidemment, les principes resteront :

-> Ne jamais avoir à décrire les itinéraires
-> Automatisation de la description du réseau nécessaire pour que les programmes tournent
-> La façon de demander un itinéraire doit être la plus simple possible (un clic sur l'entrée, un clic sur la destination)
-> On doit pouvoir effacer un itinéraire (pas si évident que ça en a l'air suivant l'état d'avancement de l'itinéraire)
-> La circulation dans la gare doit être la plus fluide possible.

Q : Tout ça dans le programme "TCO" ?
R : Non, il y a des choses qui n'ont rien à y faire.

Le programme "TCO" sert à préparer des fichiers pour le programme "Commandes"
Aujourd'hui, 4 fichiers :

-> C_panel_(date).tsv qui décrit tous les cubes
-> Block_(date).tsv qui décrit tous les cantons
-> Turnout_(date).tsv qui décrit tous les branchements
Ces 3 fichiers sont à destination du programme commandes.pde (Processing)
-> Specifs.h à destination de l'Arduino gestionnaire du réseau.

Donc, par exemple, le programme TCO n'a pas à faire bouger les aiguilles, faire tourner la plaque tournante (je supprimerai) ou faire avancer les trains.

Parenthèse sur le mouvement des trains sur le TCO : "TCO" est actuellement entièrement en courbes Bezier cubiques, donc en "vrais" cercles.

Concernant les itinéraires, seule l'automatisation de la description du réseau sera dans "TCO".

Q : Tu dis que ton programme est basé sur le locodrome. Ils n'ont pas l'air de se ressembler : l'un fait à peu près 1 000 lignes et le tien plus de 5 000 lignes …?
R : En fait, c'est parce que les deux programmes n'ont rien en commun !!

Si on observe bien les choses, on pourrait dire que "TCO" est un pré-locodrome.
"Commandes", lui, ressemblera beaucoup plus au locodrome.

Mais, en allant dans le détail, l'onglet "Formes" est "le même" que mon onglet "Form" et l'onglet "Paves" est "le même" que l'onglet "Cube"+"Cube45". Et ce sont des parties fondamentales.

Après, les différences entre ces onglets portent sur des "détails" : je peux donner la taille que je veux aux cubes alors que les pavés font 9 de côté, je n'utilise plus quadraticVertex(), j'ai plus de modèles, etc…
Mais la logique est vraiment la même.

Après, plus rien à voir.
Par exemple, j'ai une palette pour dessiner le réseau alors qu'il est décrit "en dur" dans locodrome.
Les buts ne sont pas du tout identiques.
Mais comme la base est la même, la façon de raisonner est la même et on convergera.
10
Merci Dominique  ;D

C'est sûr que si on juge des possibilités d'un programme à sa seule palette, on loupe pas mal de choses...
C'est un peu comme les icones sur un mobile : de nombreuses fonctions n'ont pas de bouton (ex zoom avec 2 doigts)

Il va quand même falloir un bon mode d'emploi  ;)
J'ai fait ce que j'ai pu pour simplifier les actions, mais tout n'est pas aussi "évident" que ça.

Pour votre culture, je vous mets le lien pour voir comment fonctionne la palette de RailMaster de Hornby :



Regardez à peu près à 1mn du début pour voir leur façon de travailler.
La palette est fixe, on doit dès le début savoir comment la pièce est orientée pour choisir la bonne pièce, traitement en deux temps...
Et "un peu" carré comme dessin.

A propos des vidéos sur YouTube: je les trouvais moches et toutes floues, contrairement au film l'original.
J'ai compris pourquoi :
Il faut forcer l'affichage à HD 1080. Apparemment, en automatique, ça ne marche pas.

Denis
Pages: [1] 2 3 ... 10