Messages

16

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

17

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

18

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

19

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

20

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

21

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

22

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

23

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
 

24

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

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

@ Denis

Pour les points 1 2 3, je ne comprend pas, je ne vois pas ce que c'est une "forme".

Pour le point 4, pour éviter de coder 180 itinéraires, on sait faire des algos récursifs qui fournissent tous les itinéraires possibles, après faut faire un choix, on a déjà parlé de ces problèmes il y a un bon bout de temps. L'algo a juste besoin de tous les voisins des zones (avec les positions d'aiguilles associées).

Pour le point 5, dans le gestionnaire le fichier json est lu d'un coup pour produire un objet json, il faut donc aller dans cet objet json pour avoir les voisins d'une zone, c'est assez facile.

Pierre

25

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

« le: janvier 31, 2024, 02:00:26 pm »

Bonjour

Depuis quelques temps j'essaie de voir les avantages et les inconvénients des "trajets" et des "demi-trajets". Pour cela je vous joins des extraits json du Locoduinodrome dans les deux cas, c'est une partie caractéristique des zones (la version "trajet" est issue de Denis). Je joins aussi le dessin du Locoduinodrome.

Il faut aussi s'intéresser à la facilité des opérations courantes du gestionnaire :

- obtention de la zone voisine d'une zone donnée (d'un coté ou de l'autre) en fonction de la position réelle des aiguilles

- positionnement des aiguilles pour un itinéraire donné par une liste de zones (traité dans un sens ou dans l'autre), un itinéraire est proposé

- recherche automatique des précédents et suivants des signaux

- obtention de toutes les zones voisines d'une zone donnée (d'un coté ou de l'autre)

- autres ?

Pierre

26

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

« le: janvier 30, 2024, 06:06:56 pm »

J'ai beaucoup de mal à comprendre les demi-trajets pour les appareils de voie à base de croisements.
Il faut imaginer un point fictif, partir de ce point et ne parler que d'une aiguille alors qu'il en a deux...

Le point fictif c'est le centre du croisement, et l'aiguille fictive sert à sélectionner  les bons demi-trajets

Les trajets complets sont peut-être un peu plus lourds, mais nettement plus simples à imaginer.

Les trajets sont à mettre dans le json des zones, on ne peut rien faire de clés genre "AB" sauf comme commentaires, il va falloir aussi structurer pour faciliter le traitement par le gestionnaire

Par ailleurs, cette nouvelle notation est beaucoup plus compacte (plus d'accolades), mais j'imagine qu'il faut en mettre, comme avant ?

Non c'est exactement le json qui est utilisé pour le gestionnaire

Pierre

27

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

« le: janvier 30, 2024, 05:01:43 pm »

Voila ma proposition pour des demi-trajets (à mettre dans le json des zones), A0 est l'aiguille simple, A0 et A1 sont les aiguilles doubles :

"vois1":"ZA",
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]] // droite pointe

"vois1":[["ZA","A0","droite"],["ZC","A0","gauche"]], // droite talon
"vois2":"ZB"

"vois1":"ZA",
"vois2":[["ZB","A0","gauche","A1","droite"],["ZD","A0","droite"],["ZE","A0","gauche","A1","gauche"]] //  triple modele Peco

"vois1":[["ZA","A1","gauche"],["ZC","A1","droite"]] // tjd
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]]

"vois1":[[NULL,"A0","droite","A1","gauche"],["ZA","A1","droite"],["ZC","A1","gauche"]] // tjs
"vois2":[[NULL,"A0","droite","A1","gauche"],["ZB","A0","droite"],["ZD","A0","gauche"]]

"vois1":[["ZA","A0","gauche"],["ZC","A0","droite"]], // croisement (vu comme une aiguille sans moteur)
"vois2":[["ZB","A0","gauche"],["ZD","A0","droite"]]

La tjs est un peu délicate, il faut éliminer un cas.
Pour les tracés continu des itinéraires il est utile de considérer le croisement comme une aiguille (sans moteur)
Il peut rester des erreurs !

Pierre

28

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

« le: janvier 30, 2024, 03:44:43 pm »

Voila une base pour vos propositions, les zones voisines sont toutes nommées.

Pierre

29

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

« le: janvier 30, 2024, 02:49:35 pm »

@ Denis et autres

Plutôt que le terme "forme" je préfèrerais le terme "trajet" (ou autre : parcours, ... idées ).

Je suis assez d'accord avec toi, j'ai déjà envisagé très sérieusement des demi-trajets (demi-formes), à partir du "centre" de la zone, dans l'exemple complexe du dessin c'est le centre de la tjd. Les demi-trajets simplifient un peu le nombre de cas, les trajets donnent 10 cas, tandis que les demi-trajets donnent 2+5=7 cas (2 pour la partie gauche et 5 pour la partie droite), 2*5 donne bien les dix cas réels. Bon dans les cas les plus courants de zones on n'a pas une telle complexité.


Ce qu'il faut regarder, pour choisir, c'est les appareils de voie à problèmes : tjd, tjs et croisement.

Ce qu'il faut regarder, aussi et surtout, c'est l'usage que l'on fera avec ces trajets : suivi des trains, recherche automatique des suivants et précédents des signaux et j'en oublie certainement.

Il faut aussi trouver un codage json qui soit facilement utilisable par le gestionnaire.

Il faut en discuter, pour choisir le meilleur cas.

Pierre

30

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

« le: janvier 29, 2024, 10:11:13 am »

@ Denis

Une tjd ou une tjs c'est équivalent à deux aiguilles en pointe, voila pour la tjs A1-A3 :

    {
      "nom" : "A1",
      "type" : "tjs"
    },
    {
      "nom" : "A2",
      "type" : "droite"
    },
    {
      "nom" : "A3",
      "type" : "tjs"
    },

Les "type" sont des commentaires.

Pierre