Messages

1

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

« le: avril 12, 2024, 10:38:21 am »

@ Denis

Trouver tous les itinéraires possibles entre n'importe quel point A et n'importe quel point B, n'a pas grande utilité, je pense qu'il faut plutôt définir des points d'origine d'itinéraires avec un sens et des points de destination d'itinéraires, ces points pouvant de façon plus générale être des zones.

Normalement les points d'origine sont devant un signal (ou sont des zones avec un signal) et il n'y a qu'un signal par itinéraire (sauf Cv bas).

Dans les grandes gares il peut y avoir plusieurs itinéraires possibles, mais en pratique en respectant les contraintes précédents je n'ai pas de souvenir d'avoir rencontré de problème avec des sens des voies (pair/impair). Par contre quand il y a plusieurs itinéraires possibles il faut absolument choisir, on a déja évoqué ce problème jadis et j'avais proposé de choisir l'itinéraire avec le moins de zones, tu n'étais pas d'accord alors, as tu un meilleur critère à proposer (faut que cela reste réaliste).

Le gestionnaire peut très bien rechercher les itinéraires à partir d'un point d'origine et d'un point de destination. Dans le gestionnaire JSON publié, il y a depuis le début dans l'onglet "Zones" deux fonctions "voiss1(String z)" et "voiss2(String z)" qui donnent tous les voisins (1 et 2) d'une zone, ces fonctions étant prévues pour la recherche automatique des itinéraires. Dans la dernière version publiée il y a dans l'onglet "Itineraires" une fonction expérimentale "itineraire(String zo,int c,String zd)" qui recherche un itinéraire d'origine "zo" en partant du coté "c" avec pour destination "zd" (le résultat est une liste de zones). Cette fonction est bridée pour s'arrêter au premier itinéraire trouvé, mais elle peut tous les trouver (reste à trouver un moyen de choisir).

Concernant les appellations des cotés (1/2, 0/1, pair/impair, … ), le problème est plus vaste que cela et je compte lancer une discussion sur le sujet (les "sens" en général).

Pierre

2

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

« le: avril 07, 2024, 11:08:07 am »

@ Dominique

Concernant les modes d'emploi il y a deux références à des posts précédents, une pour le fonctionnement général et une pour les boutons d'itinéraires qui sont expliqués sur le simulateur du PRS de Méru.

Comme je l'ai déja signalé le gestionnaire n'est pas écrit en programmation objet, mais sous forme de fonctions. Pour chaque message reçu par le gestionnaire il y a une fonction spécifique (voire deux pour les zones) qui traite le message avec l'aide de plein de fonctions annexes. Les variables du gestionnaire (zones, aiguilles signaux, …) sont dans le JSON. Cela devrait permettre de comprendre plus facilement le fonctionnement, plutôt que les objets et l'héritage, mais aussi de faciliter le passage au C/C++. Ce qui est écrit dans le gestionnaire c'est certes du Java, mais c'est quasiment du C/C++, la syntaxe du Java a repris en grande partie celle du C/C++ (il y a un article sur ce sujet : "Processing pour nos trains").

Pierre

3

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

« le: avril 06, 2024, 11:01:04 am »

Voici une nouvelle version expérimentale d'un gestionnaire paramètré par un fichier JSON. Par rapport à la version précédente plusieurs choses ont changé :

- des itinéraires permanents ont étés ajoutés, deux conséquences, sur le TCO les boutons d'itinéraires ont étés changés pour ressembler à des vrais boutons d'itinéraires de PRS (voir le PRS de Méru pour les explications de fonctionnement post #160 du 10 janvier 10 2024 sur ce fil), dans le gestionnaire certains carrés peuvent servir de sémaphores pour assurer la continuité du cantonnement. Ces itinéraires permanents permettent de faire rouler un ou deux trains sur la boucle.

- en vue du passage au C/C++, impliquant un changement de bibliothèque JSON, tous les accès au JSON ont étés regroupés dans un seul onglet ("Json"), il reste dans les autres onglets un type (JSONArray) qu'il est difficile d'éliminer Java n'ayant pas de "typedef".

- pour accélérer le programme un certain nombre de valeurs de type chaine de caractères ("String") sont substituées par des valeurs numériques ("int") juste après la lecture du fichier JSON. Ces valeurs sont : "gauche", "droite", "pair", "impair", "pairOUimpair", "pairETimpair".

J'ai fait aussi des essais d'itinéraires spécifiés par une origine et une destination, genre PRG et successeurs.

Pour le fonctionnement du gestionnaire avec le TCO voir la précédente version post #339 du 18 février 2024 sur ce fil.

Il reste encore des bugs dans le gestionnaire, notamment pour les itinéraires. Il faut aussi implémenter une circulation automatique des trains et prendre en compte le nouveau Locoduinodrome (donc modification du TCO, déja bien avancée). Puis envisager des manoeuvres.

Pierre

4

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

« le: mars 28, 2024, 10:31:19 am »

Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.

Dans le programme du gestionnaire il y a des objets informatique zones, entre les zones (jonction de 2 zones) il n'y a rien, aucun objet informatique pour attacher un signal. Il faut bien attacher le signal à quelque chose.

Pierre

5

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

« le: mars 27, 2024, 11:46:37 am »

Voici où j'en suis concernant les itinéraires dans le gestionnaire, il va peut être falloir harmoniser les choses :

Le gestionnaire a besoin pour un itinéraire d'une liste de zones, à partir de cette liste il peut positionner les aiguilles et gérer les signaux. Il peut aussi être nécessaire d'avoir une autorisation pour partager des voies entre postes d'aiguillage.

La liste de zones commence à la zone de départ, celle qui contient le signal de départ, puis toutes les zones d'aiguilles, pour finir sur la zone d'arrivée. Un signal doit être rattaché à une zone, dans la réalité le signal est implanté juste avant le changement de zone, avant la coupure physique des rails (si elle existe).

Au niveau du fichier JSON pour chaque itinéraire il faudra une liste de zones et éventuellement une autorisation. Pour les gares comportant beaucoup d'itinéraires cela peut devenir fastidieux à saisir. Dans ce cas on peut envisager de fonctionner avec un point de départ et un point d'arrivée. Il faudra alors, peut être, dans le fichier JSON coder ces points de départ et d'arrivée avec des sens, vraisemblablement dans les zones.

Avec une zone de départ et une zone d'arrivée (et des sens) le gestionnaire peut calculer tout seul la liste des zones. On utilise pour cela un algorithme récursif assez simple. Mais cet algorithme a quelques défauts, il peut boucler indéfiniment, on peut palier ce problème par marquage des zones ou en limitant la taille de la liste de zones, il peut aussi produire plusieurs listes de zones, il faut alors choisir la "bonne" liste, pas si évident que cela. Il y a aussi le problème des autorisations.

Quelque soit la version des itinéraires, il va falloir spécifier les itinéraires de manoeuvre. Les itinéraires de manoeuvre ouvrent les signaux avec un feu blanc (carrées ou carrés violet), et il permettent d'envoyer une locomotive sur une zone d'arrivée occupée, ce qui implique un traitement spécifique dans le gestionnaire.

Plus généralement il va falloir dans le fichier JSON une partie "paramètres", par exemple : pour dire quelle version des itinéraires on utilise, pour dire si on alimente en analogique ou en numérique, … .

Pierre

6

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

« le: mars 25, 2024, 06:39:31 pm »

@ Etienne

OK après vérification dans les doc SNCF, il y a bien une différence (petite) entre les carrés violets hauts et bas.

Pierre

7

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

« le: mars 25, 2024, 10:46:02 am »

Pour commencer la discussion sur les manoeuvres, quelques précisions :


Concernant les manoeuvres certaines gares, généralement moyennes ou grandes, ont de voies spécialisées appelées "tiroir", ce sont souvent des voies courtes destinées à accueillir une locomotive pour des mises en tête de train ou des retraits. Une signalisation particulière est utilisée avec des carrés violets, mais aussi des feux blanc (M) sur des carrés normaux.

Dans certaines gares les manoeuvres se font sur voie principale, une pancarte LM (Limite de Manoeuvre)
indique jusqu'où la locomotive peut aller en manoeuvre, il y a généralement la place pour manoeuvrer un train complet. La signalisation est la même que pour les tiroirs (carrés violets). Dans les gares sur des  doubles voies les manoeuvres se font toujours sur la voie "sortante", cela implique que le conducteur d'un train en ligne (pas en manoeuvre) ne rencontre pas de carrés violets (sauf IPCS). Bien souvent il n'y a pas de place pour implanter un carré violet "haut" dans l'entrevoie, un carré violet bas est alors implanté. Il n'y a pas de différences entre les carrés violets haut et bas. Par contre dans les gares sur voie unique les trains en ligne peuvent rencontrer des carrés violets, ceux-ci présentent alors un feu blanc (M).

Dans les grandes gares il y a souvent un mélange de manoeuvres avec des tiroirs et des manoeuvres sur voie principales.

Pierre

8

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

« le: mars 25, 2024, 10:39:31 am »

Après quelques semaines consacrées à la Savoie, je me remets au train. J'ai lu tous les post en retard. Je vais commencer par refaire une petite mise au point, dans ce fil on s'intéresse aux gestionnaires basés sur les ZONES, les cantons sont marginaux dans ce type de gestionnaire, ils ne servent qu'a l'espacement des trains. Pour les amateurs de cantons il y a d'autres fils sur ce forum.

Mon séjour en Savoie a du priver mon cerveau d'oxygène, car en lisant les post je suis tombé sur des mots et des idées que je ne comprends pas : segments, blocs, cantons virtuels et j'en passe.

Le but n'est pas de mettre dans le fichier JSON tout et n'importe quoi pour se faire plaisir, mais de mettre ce qui est nécessaire au gestionnaire pour faire son job efficacement, c'est à dire la sécurité, puis les améliorations : itinéraires, cantonnement, manoeuvres, conduite automatique, … . Tout ceci en essayant de rester le plus général possible : support de l'analogique et du digital, support de différents modes de rétro-signalisation, support de différents modes de commande des aiguilles et de signaux, … .

Il va falloir discuter séparément sur plusieurs sujets : les manoeuvres, les itinéraires, les sens des zones et voies, analogique/numérique, … .
Je vais aussi publier une nouvelle proposition de gestionnaire, cette version corrige quelques bugs, introduit des itinéraires permanents, mais surtout facilite la transition vers le C/C++ et l'Arduino qui impliqueront un changement inéluctable de la bibliothèque JSON.

Pierre

9

Aide / Re : Un gestionnaire en C++ pour votre réseau (1)

« le: février 26, 2024, 02:17:49 pm »

@ Frédéric
Bonjour

Après un WE chargé et pas mal de sollicitations je découvre ton schéma de réseau.
J'ai quelques questions, est ce que tu compte utiliser un gestionnaire de réseau ou pas, accessoirement est ce tu comptes installer de la rétro-signalisation (détection de présence de trains par consommation de courant). Comment tu compte manoeuvrer les signaux.
Pour les alims traction tu les faits en PWM. Les détecteurs infrarouges c'est pour quel usage.
Globalement on aimerait savoir ce que tu veux faire plus précisément.

Pierre

10

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

« le: février 26, 2024, 01:55:12 pm »

@ Denis

Je pars comme base qu'un itinéraire est une liste de zones, cette liste pouvant être établie manuellement ou automatiquement. Dans les deux cas il faut proscrire les cas inexistants des TJS et les cas impossibles avec les croisements.

Une TJS est alors vue comme une TJD. Le croisement est un petit peu plus délicat, il faut le considérer comme une sorte d'aiguille (sans moteur), par exemple soit A0 son nom cela donne pour les voisins de la zone le contenant quelque chose du genre :
   "vois1":[["ZA","A0","droite"],["ZC","A0","gauche"]]
   "vois2":[["ZB","A0","droite"],["ZD","A0","gauche"]]
si la pseudo aiguille A0 est à droite cela fait ZA<->ZB, sinon ZC<->ZD. De plus le fait de considérer le croisement comme une aiguille facilite grandement les tracés continus sur un TCO.

Pour les itinéraires automatiques, il faut juste une zone de départ et une zone d'arrivée (éventuellement un sens), un algorithme récursif peut produire facilement TOUS les chemins possibles pour aller de la zone de départ à la zone d'arrivée, il conviendra d'éliminer les chemins impossibles à cause des TJD ou des croisements et de faire un choix parmi les cas possibles (le gestionnaire peut fournir tous les voisins d'une zone).

Concernant les signaux leur génération automatique pose pas mal de problèmes :
- il faut trouver où les implanter
- il faut trouver le bon type de signal (un S ou un SR, ...)
- il faut savoir s'il faut des ralentissements RR30 ou RR60 et sur quelles aiguilles ils sont basés (attention aux aiguilles courbes ou symétriques)
- il faut faire la distinction entre les carrés et les carrés violets
- il faut savoir si les carrés supportent le BALs (feu S) ou pas
- il faut savoir si les carrés supportent les manoeuvres (feu M) ou pas
- ...

Concernant les itinéraires je pense qu'il faut mieux les décrire manuellement, s'il y en a beaucoup on peut faire une sélection d'itinéraires par bouton départ, bouton arrivée. Et on peut toujours faire une recherche automatique.

Pierre

11

Aide / Re : Re : Un gestionnaire en C++ pour votre réseau (1)

« le: février 23, 2024, 06:14:12 pm »

si j' adapte  le programme. à mon ovale je pourrai le gérer ?
et gérer les alimentations de voie exemple L298N et des servo sg90s pour les aiguillages?

Si ton réseau n'est pas trop compliqué (un schéma serait le bienvenu) c'est possible, mais il faudra interfacer les alims et les servos avec l'Arduino.

Pierre

12

Aide / Re : Un gestionnaire en C++ pour votre réseau (1)

« le: février 23, 2024, 05:30:48 pm »

Dans cette version il faut déclarer les zones manuellement. C'est fait dans l'onglet "composants", ligne 107. Il faut fournir un numéro de zone et une liste de pavés. Pour avoir des tracés colorés jolis, les zones avec aiguilles sont "bricolées" par le biais de classes spéciales.

Pierre

13

Aide / Re : Un gestionnaire en C++ pour votre réseau (1)

« le: février 23, 2024, 03:39:29 pm »

Bonjour

J'ai beaucoup de mal à comprendre ce que vous voulez faire, a priori vous êtes dans un programme de TCO, dites moi de quel article précis il vient, dans certains cas les zones se "fabriquent" automatiquement.

Cordialement

Pierre

14

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

« le: février 20, 2024, 11:08:04 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

Les deux programmes ne peuvent pas marcher l'un sans l'autre. Il faut lancer le TCO en premier, puis le gestionnaire, celui ci se connecte sur le TCO en TCP/IP et les deux programmes fonctionnent alors ensemble.

Pierre

15

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

« le: février 19, 2024, 04:40:51 pm »

Mes impressions sont le suivantes principalement par rapport à ce que je m'attendais à voir venir.

1) C'est du Processing donc ça ne peut pas tourner dans un Arduino (Due, ArmXX) avec une connexion Can qui permet de récevoir tous les messages des capteurs (occupation, ponctuels, RFID/Railcom) et d'émettre tous les messages vers les actionneurs (aiguilles, signaux et surtout la centrale DCC en l'occurence LaBox).

Oui c'est du Processing, car pour moi c'est beaucoup plus rapide à écrire et à tester, une version du gestionnaire pourra rester comme cela. Mais une version C/C++ pourra aussi être portée sur Arduino.

Bien entendu la connexion existe entre le gestionnaire et le TCO. Mais je n'ai pas pu faire rouler de train virtuel, ce qui n'est pas nécessaire sauf pour tester à fond les paramètres .

Tu dois pouvoir faire rouler les trains virtuels, il suffit de faire avec la souris un drag vers le haut (déplacement de la souris avec le bouton enfoncé) dans une des bandes verticales à droite de l'écran. Les trais s'arrêtent automatiquement aux signaux fermés.

2) J'ai eu du mal à retrouver les objets, propriétés et méthodes habituelles du gestionnaire en C++ et comprendre l'intégration des paramètres Json dans ces méthodes (ou fonctions ici, puisque ce n'est pas encore de l'objet)

Il n'est pas vraiment prévu d'objets. Tout le gestionnaire est écrit avec des fonctions, dans le but de faciliter la réécriture en C/C++.

Je serais donc très intéressé de savoir un peu à l'avance quel sera le chemin d'évolution et la cible visée du gestionnaire parametrable et je me rend compte du travail important que cela représente.

Petit à petit je vais améliorer le gestionnaire en Processing, et passer au nouveau Locoduinodrome (gros travail avec le tco).
J'ai commencé à regarder le portage en C/C++ sur un ESP32 bi-coeur, mais j'ai plein de problèmes avec IDE Arduino au niveau des cartes et des bibliothèques (json).

Pierre