Projet partagé d'un gestionnaire de réseau

[bobyAndCo]

Bravo Denis, c'est très esthétique.

Quand pense-tu pouvoir mettre à dispo une version de test avec mode d'emploi ? J'ai hâte de tester.

Bonne continuation

Christophe

[DDEFF]

Merci Christophe,

Le programme fourni permet déjà de renter son réseau et d'en faire un JSON et un TCO.
Si quelques uns de mes lecteurs pouvaient essayer de rentrer leur propre réseau, cela ferait plusieurs exemples pour faire des tests.
Et trouver ainsi des cas "à problèmes" pour pouvoir améliorer le programme.

Je pense que je vais rentrer "Luzy", pour voir si ça marche.

Effectivement, si le gestionnaire pouvait suivre, ce serait super.

Denis

[bobyAndCo]

Pas de chance Denis, quand j'ai voulu valider la création de ma première zone, la souris de mon mac s'est transformée en roue colorée programme planté !!!





J'attends les instructions.

Christophe

[DDEFF]

Tu as essayé avec la version 21  envoyée ce midi ?

[bobyAndCo]

Même problème avec la v21 quand je valide "quelle est la zone après A", j'entre Z11, je valise et.... planté

[DDEFF]

J'ai trouvé le bug.
Recharge la V21 (j'ai aussi remis à jour celle que j'avais mis dans mon post de ce midi)

Denis

[bobyAndCo]

J'ai créé ma zone coté A (z11), j'ai aussi créé ma zone côté B (z2) puis validé et ... plus d'écran et ce message

voir fichier joint

[DDEFF]

Normalement, c'est mieux...
Je supprime les Z21 et les Z20 qui souffraient du même défaut

[DDEFF]

Bonsoir,
J'ai beaucoup travaillé avec des fichiers existants et il restait des bugs pour les zones initiales, ainsi qu'en sauvegarde impossible...

Bon, on peut créer les premières zones et les sauver sans bugs.
C'était simple à corriger, mais ça n'était pas viable.

La V23 fonctionne. Je commence à rentrer Luzy.

Le programme étant construit pour générer un fichier JSON, il ne le calcule que quand tout est OK, c'est à dire quand l'analyse ne détecte plus rien.
Or, au début, il manque forcément des éléments et l'analyse trouve des choses à redire, d'où le message d'erreur systématique quand on veut sauver.
Il ne faut pas en tenir compte.
Puis la sauvegarde se fait, mais sans le fichier JSON, ce qu'indique le dernier message.

Donc, la toute première fois, vous partez sans aller chercher un fichier (bouton "Zones").
Puis vous sauvez, ce qui génère un fichier "Zones", entre autres.
Et la fois d'après, vous allez chercher les fichiers (boutons "Fichiers" puis "Charger") pour le compléter.

Denis 

[DDEFF]

Bonjour à tous,

J'ai démarré le réseau de Luzy, histoire de voir comment ça se passe avec un très grand réseau.
On a la chance d'avoir la version RRTC de ce réseau, Renaud Yver étant un spécialiste de ce logiciel.

Alors, le résultat est que le programme, à la V23 fonctionne bien, sans plantage.
Remarque : pour que l'analyse se passe bien alors qu'on n'a pas rentré tous les éléments, il suffit de mettre un butoir aux extrémités (C26 et C31 pour Luzy).
On peut ainsi afficher un TCO correspondant à ce qu'on a déjà rentré.

Mais il va falloir modifier les dessins pour le gestionnaire :
Si on met le nom des aiguilles sur les aiguilles, on cache tout. RRTC ne met pas les noms des aiguilles.
Je ne mets pas les noms des signaux dans le gestionnaire. A discuter.
La largeur des traits est certainement à réduire, en fonction du nombre de pavés du TCO.

A suivre
Denis

[Dominique]

Bravo Denis,

Comment peut-on dimensionner la fenêtre du TCO ?

[DDEFF]

Bonjour Dominique,

La taille de la fenêtre est "en dur" dans le programme. C'est même la toute première instruction dans le setup() et elle est obligatoire.
Donc, il y a 2 possibilités : soit la taille programmée, soit plein écran ("Bouton vert" pour Mac et "Carré" pour Windows)

Denis

[DDEFF]

Bonjour à tous,

Concernant Luzy, j'ai bien fait de me lancer. Il y a quelques nouveautés dans la V24 que je mettrai en ligne bientôt.

Exemple :
J'avais envisagé pour les noms de zone des choses du type XXX ou XXXCCC ou XXXCCC/CCC (X = une lettre, C = un chiffre), mais j'avais oublié XXXCCCX (Voie 3 A)

Maintenant, la largeur du trait sera fonction du nombre de cases du fond, les appareils de voie n'auront plus d'étiquette, les étiquettes auront une largeur variable en fonction du texte et leur emplacement sera aussi désolidarisé de la position du pavé (comme les signaux).

Pour info, un réseau comme Luzy nécessite 4 h de saisie pure. C'est peu pour un réseau de 10 m x 5,25 m.

A suivre
Denis 

[Dominique]

L'IA peut peut-être nous aider

Et pourquoi pas , j'ai essayé à partir de ton code GestJC_2 :
J'ai demandé à Claude.ai "Peux-tu convertir ce programme en C++ Arduino ?"
en lui donnant en pièces joints tous les fichiers de GestJC_2 et il m'a alors répondu "Votre message dépassera la limite de longueur pour cette conversation. Essayez de joindre moins de fichiers"

Alors je n'ai gardé que GestJC.cpp et Descriptionreseau.json.
il propose alors un code Arduino et ce commentaire :

Code: [Sélectionner]

Le code a été adapté à la structure standard de programme Arduino avec setup() et loop().
La communication série remplace les tubes (FILE*) utilisés dans la version originale.
Plusieurs fonctions sont laissées comme des squelettes à implémenter selon votre configuration spécifique :

envoiMessage() : Gestion de l'envoi de messages
receptionMessage() : Traitement des messages reçus
lectureJson() : Chargement de la configuration
Autres fonctions liées à la gestion des zones, aiguillages, etc.


La gestion des itinéraires et de la mémoire devra être adaptée pour l'environnement Arduino.
Vous devrez définir les constantes manquantes comme BUS_TCO, CODE_INIT, OCCUPE, DROITE, GAUCHE, etc.Le résultat étant forcément incomplet, je lui ai demandé d'ajouter d'autres fichiers en plusieurs étapes;
D'abord train-management-module.py avec cette réponse :

Code: [Sélectionner]

Voici les principales modifications et adaptations pour l'environnement Arduino :

Simplification des structures de données pour réduire l'utilisation de la mémoire
Utilisation de tableaux statiques avec des tailles maximales
Chargement du fichier JSON depuis une carte SD
Utilisation de ArduinoJson pour le parsing
Méthodes simplifiées pour le chargement et la gestion du réseau
Adaptation du modèle de simulation pour les contraintes d'Arduino

Quelques points importants à noter :

Ce code nécessite une carte SD pour charger le fichier de configuration
La simulation est très basique et devra être affinée
Les fonctionnalités complexes du modèle original ont été simplifiées
Les limites de mémoire d'Arduino imposent des compromis

Recommandations pour l'utilisation :

Préparez un fichier reseau.json sur la carte SD
Assurez-vous que la bibliothèque ArduinoJson et SD sont installées
Ajustez les constantes (MAX_SEGMENTS, MAX_TRAINS, etc.) si nécessaire
Testez et ajustez la logique de simulation selon vos besoins spécifiques
Ensuite il a refusé d'ajouter les définitions des zones, trains, signaux et messages, pour la raison de la limite.
Normal car je suis en mode gratuit très limité.

Néanmoins le code suivant a été généré (en PJ) dans lequel il a ajouté des structures manquantes et une gestion du json et des automatismes de trains.
Mais le compilateur Arduino n'a pas accepté ce code, notamment dans la déclaration :

Code: [Sélectionner]

StaticJsonDocument<2048> doc;J'ai essayé avec différents types de processeurs, mais sans succès.

Mais ce point de départ est peut-être utile pour Pierre, pour intégrer le restant.

Amicalement
Dominique

[DDEFF]

Bonjour à tous,

Pourquoi j'ai choisi "Luzy" ?

"Luzy" est, à ma connaissance, le plus grand réseau français installé chez un particulier (à part, peut-être "Soumagnac" ?). En tout cas, le plus célèbre, animé par quelqu'un de fort sympathique (Renaud Yver) qui diffuse son savoir avec entrain ( ). Le fil consacré au réseau fait … 1048 pages !!
En particulier, il utilise RRTC (Trains Controller), version gold et on a le plan.
En entrant les infos de "Luzy" dans mon programme, je m'attendais à trouver des problèmes nouveaux et c'est effectivement le cas.
J'ai donc passé 10 h en tout pour le rentrer (8 h de saisie pure et 2 h à déplacer à la souris les pavés pour que ce soit joli).
A la fin, j'ai 138 zones (le réseau fait 50 m²).

Il n'y a plus de problèmes "plantatoires", mais il reste des problèmes "dessinatoires", comme vous allez le voir sur le TCO.

Explication :

J'ai deux (!) TCO car le premier se calcule en dessinant les zones, puis les "connecteurs", c’est-à-dire toutes les lignes qui vont d'une zone à une autre. Là, ça marche.
Mais le calcul est long car il y a trop de calculs à faire. Ce n'est pas un problème dans un éditeur, mais c'est rédhibitoire dans un gestionnaire.
En effet, je vais prendre comme exemple la Z37 dans le réseau de Dominique.

Elle est constituée de 5 droites :
Droite 0 : c'est la droite de la section "Z37".
Droite 1 et droite 2 : le programme calcule les coordonnées du coude de trace les deux droites avec les points qu'il a déjà : la point à gauche de Z37 et le point à droite de Z45 (ce sont des points de zone).
Droite 3 et droite 4 : le programme calcule les coordonnées du coude de trace les deux droites avec les points qu'il a déjà : la point à droite de Z37 et le point à droite de Z46/0 (ce sont des points de zone).
Donc des calculs de points à faire et 5 droites à tracer.
Hors de question de faire pareil dans le gestionnaire !

Je garde donc les coordonnées de tous les points du réseau dans une table imprimable (TOUS_PTS, 25 colonnes, qui ne sert à rien, sauf en développement).
Puis je raisonne en disant qu'avec les coordonnées de 4 points, je pourrais dessiner la même chose avec seulement 3 droites, sans calculs. C'est la table TCO qui recense les points réellement utiles pour chaque zone. Il n'y a plus que 9 colonnes !
C'est là qu'il subsiste quelques erreurs, visibles en comparant les 2 images.

Mais, en même temps, il y a le calcul du JSON (2 681 lignes !), avec juste quelques erreurs dans quelques signaux. Je vais voir.

A suivre

Denis