Messages

16

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: février 20, 2024, 09:05:11 am »

Re-bonjour,

Je suis inquiet.

J'étais rentré sur ce fil (et je m'y suis investi) pour trouver une solution à mon problème : trouver une interface Processing-CAN pour faire marcher mon gestionnaire et l'améliorer avec des idées nouvelles qui seraient développées dans ce fil.

J'y ai appris l'existence de fichiers JSON qui, à mon avis, permettent d'unifier le passage de la description de réseau au gestionnaire.

Mais si le but est obligatoirement de porter le gestionnaire sur un ESP32, là, je ne trouverai jamais la solution à mon problème.

Denis

17

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: février 20, 2024, 08:21:34 am »

Bonjour,

Je n'arrive pas à faire marcher le programme GestTCO2. Quand j'appuie sur un bouton d'itinéraire, il ne se passe rien.
L'autre programme (GestJ2) plante.
Il faut un mobile ?

Denis

18

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: février 19, 2024, 09:14:09 am »

Bonjour,

A chaque fois que je vois les programmes de Pierre, je mesure tout l'écart qui peut exister entre mon type de programmation, où je me débrouille avec le peu de fonctions de que j'ai comprises, et les siennes, où tout est objet, compact, avec un "vocabulaire" puissant que je ne connais pas. C'est très intimidant.

Bien sûr, je comprends quand même une bonne partie de ce qui est fait, mais heureusement qu'il y a les commentaires...

Ceci étant, j'ai quasiment fini mon éditeur JSON. Je vois qu'il va falloir y a jouter les types de signaux et les itinéraires (mais, là, ça me chagrine).
Il y génèrera les 2 types de JSON (par trajets et par voisins)

Faire un JSON "à la main", c'est tout à fait faisable, c'est même relativement facile (surtout pour un Locoduinodrome).
Mais on peut très facilement se tromper ou corriger dans un coin et ne pas faire la modification correspondante ailleurs.
Je tiens donc à ce que, grâce à un éditeur, on ne puisse pas laisser d'erreurs et que tout soit cohérent.

Denis

19

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: février 03, 2024, 07:31:23 am »

Bonjour à tous,

Je procède actuellement à une refonte complète de mon éditeur pour pouvoir ajouter et supprimer des questions facilement. Le fonctionnement global sera identique.
Laissez moi quelques jours 

@Pierre,
J'ai compris la description du réseau par 1/2 trajets. Mais je ne vois pas de gain, pour l'instant, à mon niveau. Mais pourquoi pas ?

Denis

20

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 02, 2024, 06:39:31 pm »

Bonjour,

C'est un sujet très souvent développé aux USA. En tant que lecteur de Model Railroader, je vois souvent des articles sur le sujet.
Le détecteur très souvent utilisé en DCC est le NCE BD-20 (BD-20 chez NCE). Aux alentours de 15 à 20 € pièce.
Mais je pense qu'on doit pouvoir en construire un équivalent pour beaucoup moins cher.

Il peut être très sensible.

Un article détaille bien le problème et les solutions :
https://www.jlcenterprises.net/pages/chapter-2-part-1

Bon courage !
Denis

21

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 02, 2024, 06:15:04 pm »

@ Christophe,

Oui, bien sûr, mais il faut encore en construire un. A 15 €+port, je pense que c'est cher.
D'où un fil à part.

"Je m'a gourré" ? 

Denis
PS : si tu veux, je recopie et on efface l'autre.

22

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 02, 2024, 06:02:09 pm »

Bonjour Christophe,

Je viens de faire un fil sur un composant qui pourrait te servir : le NCE BD-20.
fil : composants/La détection des trains par détection de courant

Denis

23

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: février 01, 2024, 01:29:14 pm »

@ Pierre,

OK pour tes remarques, sauf la dernière : pour moi, le "signal suivant" dépend de la position des aiguilles et on ne peut pas le faire dans l'éditeur, sauf en pleine voie.

A part ça, j'ai une notion des itinéraires qui est une version SNCF "élargie", c'est à dire que, quand un train se déplace, il est toujours sur un itinéraire, indépendamment des gares, etc...

Il y a 2 types d'itinéraires :
- les itinéraires "bouclés", c'est à dire qu'ils tournent indéfiniment, jusqu'à ce qu'on les arrête.
- les itinéraires "à la demande" qui vont de la position actuelle du train (connecteur, sens) vers une destination choisie (connecteur, sens). Le train s'arrête quand il a atteint sa destination. On peut (et on doit) alors lui en reprogrammer une autre pour qu'il reparte.

Pour moi, on n'a pas de "bouton" (réel ou virtuel) qui modifie la position d'une aiguille. On n'a donc pas à gérer tout un tas d'enclenchements.

Les itinéraires sont enregistrés, de façon tout à fait indépendante de la position actuelle des aiguilles, des signaux actuels, des occupations actuelles...
On veut aller de là à là, quand ce sera possible, en toute sécurité. Il y a donc des zones "occupées par un itinéraire", mais physiquement vides.
Si le train est arrêté pour des raisons de sécurité, les zones aval ne sont pas (encore) occupées par un itinéraire. Ça se fait au fur et à mesure.

Par ailleurs, un itinéraire est donc une suite orientée de zones, elles aussi orientées une par une.

On peut construire l'itinéraire "par morceaux", c'est à dire qu'on part d'une gare, par exemple, et on demande un itinéraire pour une autre gare, avec une durée d'arrêt choisie dans cette gare intermédiaire. Puis on "ajoute", un autre itinéraire vers une autre gare où, par exemple, on ne s'arrête pas et, enfin, un troisième morceau vers une gare de destination où on s'arrête définitivement. Pour moi, tout ça, c'est UN itinéraire.

Si on entre, pour chaque zone, la longueur de la zone, on peut savoir à quelle distance réelle on est du signal suivant et en tenir compte dans les ralentissements.
En particulier, on peut connaître, pour un itinéraire donné, quel est le prochain feu S ou C et caler le ralentissement non pas sur le A, mais sur le S ou le C, ce que fait un conducteur quand il aperçoit un A.

Denis

24

Vos projets / Re : BASIC_AUTO_LOOP_REVERSER

« le: février 01, 2024, 08:49:01 am »

@ Laurent,

Je suis très content de voir l'équivalent d'un "DCC frog juicer" chez Tam Valley Depot pour la modique somme de 16,49 $, hyper célèbre aux USA.
Remarque : c'est également utile pour les ponts tournants.

L'autre truc célèbre aux USA et quasi inconnu chez nous : les "circuits breakers" : On utilise un booster, mettons à 10 A, puis on divise le réseau en "zones d'alimentations", chacune protégée par un circuit breaker, par exemple 3 A. Ça évite de construire 3 booster 3A et c'est moins cher.

Denis

25

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: février 01, 2024, 08:30:53 am »

@ Pierre

Si je suis les règles que tu as édicté pour les tjs le 30/01, j'obtiens le fichier PierreJson2.xtx joint.
Je me trompe ?

Denis

26

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 31, 2024, 06:29:47 pm »

@ Pierre,

Une forme, c'est le dessin d'un segment de droite, d'un arc de cercle, un arc de parabole (dans mon nouvel éditeur graphique).
Pour dessiner une aiguille, il faut dessiner 2 formes : un segment de droite et arc de cercle.
Toutes les formes sont noires et une seule forme est grise, fonction de la position des lames.

Sur le point 5, je ne demande qu'à voir, ça me parait très intéressant. 

Denis

27

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 31, 2024, 05:26:40 pm »

Quelques éléments de réflexion :

1°) Quelle que soit la méthode employée, on va devoir afficher des formes (que ce soit pour les segments ou les appareils de voie) pour les itinéraires. J'ai bien dit "formes".

2°) Pour les appareils de voie, une seule et unique forme sera affichée dans un itinéraire.

3°) Il faut donc une fonction qui, pour un appareil de voie donné, affiche une seule forme, fonction de la position des lames.
Z3 :
A2 droit + A3 droit -> forme 0
A2 gauche + A3 gauche -> forme 1
A2 droit + A3 gauche -> forme 2

4°) Je ne veux pas rentrer quelque part la suite de zones des 180 itinéraires de ma gare.
Donc, il faut une fonction qui trouve cette suite toute seule, une fois l'origine et la fin de l'itinéraire donnés.

5°) Pour connaitre la zone suivante, dans les 2 sens, j'utilise la méthode suivante :

Au fur et à mesure de la lecture du fichier JSON, je crée une ArrayList des connecteurs.
Un connecteur c'est un point à la limite de 2 formes et, donc, de 2 zones :

ID, Zx, forme Nx, cote_x de la forme (0 ou 1) , Zy, forme Ny, cote_y de la forme (0 ou 1)

Par ailleurs, au fur et à mesure de la lecture du fichier JSON, je mets à jour, dans Zones,
 une variable ligne_connecteur[a1][b1].
a1 = n° de la forme et b1 = coté de la forme (0 ou 1)

Pour dessiner un itinéraire, on part d'un connecteur, du coté de l'avant du train (la loco ou le dernier wagon). Ça nous donne la zone d'origine et le coté origine.
En balayant l'ArrayList des connecteurs, côté Zx ou Zy, je trouve le connecteur origine.

Si c'est Zx, la zone suivante, c'est Zy, et réciproquement.
Supposons qu'on ait Zx. On va chercher dans la même ligne du connecteur Zy, avec le cote_y de la forme y
On va dans Zone y et on cherche ligne_connecteur[forme y][1-cote_y]
On va dans les connecteurs, directement à la ligne indiquée, et y cherche Zy (à gauche ou à droite).
Et on recommence.

Il n'y a qu'un seul balayage, au début, puis on suit par adressage direct. Et ça marche pour la signalisation et les itinéraires et dans les 2 sens.

Denis

28

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 31, 2024, 09:10:48 am »

@ Pierre et autres

L'éditeur JSON qui rentre les segments et les appareils de voie peut permettre de rentrer n'importe quelle zone.



Si on découpe la zone complexe en morceaux ("pavés"), en utilisant un caractère spécial "/", on a Z1/1, Z1/2, Z1/3, Z1/4, Z1/5.
Chaque zone est décrite comme une autres (les voisins de Z1/3 sont Z1/1 et Z1/4)
Et, à la fin, on regroupe automatiquement tous les morceaux en une seule zone avec les (AC, AD, AE, AF, AG, BC, BD, BE, BF, BG) comme trajets de la zone.

Par ailleurs, dans un trajet, on met ["origine", "extrémité", ["aiguille","position"], ..., ["aiguille","position"] ], avec de zéro (pour les segments et les croisements) à "n" ["aiguille","position"] suivant la complexité de la zone.

Denis

29

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 30, 2024, 08:16:37 pm »

@ Pierre,

Voici une autre proposition, en exemple, pour Z3 et Z4:

Code: [Sélectionner]

"Zone": [
           [
               "nom" : "Z3",
               "sens" : "banalise",
               "trajets" : [["Z5","Z1",["A1","droite","A3","droite"]
                               ["Z5","Z0",["A1","droite","A3","gauche"]
                               ["Z4","Z0",["A1","gauche","A3","gauche"]]
           ]
           [   "nom" : "Z4",
               "sens" : "pair",
               "trajets" : [["Z3","Z6",["A2","gauche"]
                               ["Z2","Z6",["A2","droite"]]
           ]
       ]
Denis

30

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: janvier 30, 2024, 07:09:16 pm »

@ tous,

Sans faire les modifs du JSON (pour l'instant), j'ai corrigé quelques bugs signalés par Dominique.

Voici la nouvelle version, normalement plus ergonomique. Il reste les bugs avec les fenêtres qui ne sont pas toujours au 1er plan (mais je n'ai pas la solution...)

Denis