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 - Pierre59

Pages: [1] 2 3 ... 19
1
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

2
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

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
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

11
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

12
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.
Citer
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.
Citer
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++.
Citer
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

13
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 18, 2024, 11:59:52 am »
Bonjour

J'ai fait quelques essais de gestionnaire paramètré complètement par un fichier json, dans une version sans programmation objet.

Pour tester un gestionnaire il faut soit un réseau, genre Locoduinodrome, que je n'ai pas, soit un simulateur de réseau. Pour gagner du temps j'ai réutilisé le programme du TCO de l'ancien Locoduinodrome, ce programme fait le dessin du TCO du réseau avec les mises à jour dues aux circulations de trains virtuels, il comporte aussi deux manettes, avec cabsignal, pour commander les trains.

Le gestionnaire communique avec le TCO avec le protocole réseau TCP/IP. Il faut lancer le TCO avant le gestionnaire. Les deux programmes sur la même machine sinon il faut jouer sur l'adresse IP du gestionnaire.

Comme le TCO est prévu pour l'ancien Locoduinodrome, j'ai du écrire le fichier json le décrivant complètement. Le fichier json ne doit pas être vu comme un modèle, il y des redondances (noms), des infos pour des tests ...

Le fichier json est lu entièrement au début du gestionnaire et les variables nécessaires au fonctionnement du gestionnaire (états des zones, positions d'aiguilles, feu de signaux, ...) sont rajoutées automatiquement dans le json au début du programme. Ce qui veut dire que l'état du réseau est quasiment entièrement codé par le json.

Le gestionnaire est essentiellement composé de fonctions qui traitent les différents cas pouvant arriver sur les différents éléments du réseau (zones, aiguillages, signaux, itinéraires, trains, balises, ...)

Ces fonctions doivent traiter tous les cas possibles, elles sont donc moins performantes que des fonctions spécialisées (écriture à la main et/ou programmation objet).

Le gestionnaire comporte deux fichiers json (onglets Z1 et Z2), celui de l'ancien locoduinodrome et celui du nouveau (incomplet). Les deux onglets me servent d'éditeur pour les fichiers json, pour l'instant.

Le gestionnaire a été écrit à l'arrache, c'est juste pour voir si c'est possible. Quand j'aurais un peu de temps j'essairai d'améliorer le gestionnaire et de corriger des bugs, et quand j'aurais beaucoup de temps je retoucherais le TCO pour utiliser le nouveau locoduinodrome et faire des test plus poussés.

Il y a d'autres façons de faire un gestionnaire paramètré par un fichier json, ne pas hésiter à proposer d'autres solutions. Il faudra aussi porter le gestionnaire en C (C++) sur un gros micro-contrôleur (genre ESP32).

Pierre

PS 

quelques commandes possibles : 

- changement de sens d'un train : clic sur la flèche (si le gestionnaire le veut bien)

- arrêt d'urgence d'un train : clic sur le bouton STOP

- changement de vitesse d'un train : drag dans la bande (si le gestionnaire le veut bien)

- établissement d'itinéraire : clic sur bouton correspondant (le bouton clignote si mise en attente)

- destruction d'itinéraire : re-clic sur bouton correspondant

- passer la souris au pied d'un signal permet de voir le signal avec les bons feux


Ne pas avoir peur de faire rouler les trains en pousse, le sens n'a pas d'importance avec ce type de gestionnaire.

L'enclenchement d'approche n'est pas actif pour le moment

14
Vos projets / Re : Re : TCO bp + ordi
« le: février 12, 2024, 04:22:29 pm »
Mais tu parles maintenant de te lancer avec Processing qui est beaucoup plus difficile à appréhender encore que la programmation Arduino où tout a été fait pour que ce soit très simple à utiliser. Libre à toi mais tu ne trouveras pas grand monde alors pour t'aider.
Processing c'est comme Arduino, tout a été fait pour que ce soit simple à utiliser, mais pour un autre domaine, celui du dessin et de l'animation 2D et 3D.

Pierre

15
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 01, 2024, 10:18:07 am »
@ Denis

La notation   [[NULL,"A3","droite","A1","gauche"],   c'était juste un idée comme cela, pas forcement réaliste.

Dans le cadre du gestionnaire je suis en train de regarder les algos utilisants les voisins.

Pour le suivi des trains on a besoin des deux voisins (en fonction de la position des aiguilles), c'est un cas qui arrive très souvent quand une zone devient occupée.

Pour les itinéraires (prédéfinis ou automatiques) on a besoin des tous les voisins et en plus du "sens" des zones. C'est un cas qui arrive souvent.

Pour trouver automatiquement les précédents et les suivants des signaux, les besoins sont à peu près les mêmes que pour les itinéraires. Ce cas ne se fait qu'une fois (dans le gestionnaire ou dans l'éditeur).

Autres cas ?

Pierre
 

Pages: [1] 2 3 ... 19