Messages

151

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

« le: janvier 04, 2024, 11:18:44 am »

Revenons d’abord aux préoccupations principales :
- la topographie : comment obtenir le graphe complet du réseau, par exemple pour l’afficher sur un TCO ?

Le graphe du réseau (avec beaucoup d'annotations) peut peut être suffire au gestionnaire, mais ne permet pas d'afficher correctement un TCO (ils faut d'autres informations). Ce ne sont pas les mêmes informations qui sont nécessaires dans les deux cas.
Je ne vois que que deux possibilités pour obtenir le graphe, un éditeur graphique ou un codage en mode texte avec un éditeur de texte.
Un éditeur graphique c'est un très gros programme. J'ai fais pas mal d'essais pour un éditeur graphique de TCO, il reste encore pas mal de petits bugs; voir aussi les travaux de Denis.
Un codage en mode texte est peu être plus abordable (json,XML, ...) mais faut pouvoir coder toutes les informations nécessaires.
Il faut remarquer que les classes proposées dans la série d'articles constituent en fait "un" codage du graphe d'un réseau.

- comment assurer la sécurité : le suivi des trains, la mise à jour du graphe, de la signalisation et l’application a la conduite des trains.

La sécurité se fait essentiellement avec les enclenchements (voir l'article 3). La SNCF assure cette sécurité surtout avec des relais (peut être aussi avec des programmes à logique majoritaire), mais il reste encore pas mal d'enclenchements mécaniques. Les relais changent leurs états en fonction des infos d'occupation des zones, des appuis sur des pédales par des essieux et des demandes d'itinéraires.
Clairement cette sécurité sur nos réseaux on la fait avec des programmes qui ont comme données variables des occupations/libérations de zones, des détections de train ponctuelles et demandes de trajets ou itinéraires de trains.

-les itinéraires : on y reviendra plus tard, l’algorithme de choix étant une option.

Je suis tout à fait d'accord avec toi.

Pierre

152

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

« le: janvier 03, 2024, 05:13:17 pm »

Bonjour

Pour le gestionnaire je pense qu'il ne faut pas le limiter au seul bus CAN, mais l'ouvrir à tous les bus possibles : CAN, WIFi, Ethernet, BlueTooth, Série, ... Avec une messagerie qui fonctionne de la même façon sur tous les bus (même API).

On parle toujours de "canton", mais faudrait bien se mettre d'accord sur ce que c'est. Pour moi ce qui est important c'est la zone : une portion de voie avec ou sans appareil de voie sur laquelle il y a une détection de présence de matériel roulant. Un canton c'est une ou plusieurs zones consécutives (pas forcément toujours les mêmes) qui se trouvent entre deux signaux pouvant présenter le sémaphore (sémaphores, carrés, ...). Les cantons servent à l'espacement des trains avec un mécanisme de cantonnement (BAL, BAPR, BMU, ...). Sur un réseau il y a des parties qui ne sont pas cantonnées : dépôts, partie marchandises, petites lignes, ... donc sans cantons mais avec éventuellement des zones.

Les zones sont essentielles dans le gestionnaire, ce sont leur occupations/libérations qui rythment son fonctionnement.

Fondamentalement un gestionnaire peut être centralisé ou repartit (dans les satellites par exemple). Un gestionnaire repartit est beaucoup plus difficile à écrire et à mettre au point qu'un gestionnaire centralisé (j'ai longuement travaillé dans des équipes CNRS de programmation répartie). Le langage à utiliser reste ouvert : Java ou C++ il faudra en discuter.

J'en reste la pour l'instant, dites ce que vous en pensez.

Pierre

153

Vos projets / Re : projet à définir

« le: septembre 21, 2023, 10:42:53 am »

Bonjour

Bonjour,
Le projet locoduinodrome est-il toujours d'actualité ?

Oui tout à fait

Pierre

154

Modélisation, Architectures logicielles et matérielles / Re : Re : TCO + Aiguilles avec Processing 4.2

« le: juin 09, 2023, 11:32:23 am »

J'oubliais une chose : Les GROUP au sens de Processing recouvrent-t'ils en interne (ou se recoupent-ils avec..) la P.O.O. du même Processing ?..  ce serait intéressant..
amitié
@+  jj 

Non, les groupes de Processing c'est juste un tableau de PShapes, rien à voir avec la POO.

Pierre

155

Modélisation, Architectures logicielles et matérielles / Re : TCO + Aiguilles avec Processing 4.2

« le: juin 09, 2023, 10:05:49 am »

Bonjour

Effectivement :

  Groupcanton.setFill(GRIS);

compile bien mais ne fonctionne pas comme on pourrait l'espérer

par contre colorer séparément tous les éléments du groupe fonctionne bien :

       PShape[] tab=Groupcanton.getChildren(); // obtention des fils
       for (PShape p : tab) p.setFill(GRIS); // pour tous les fils colorer en GRIS

Cordialement

Pierre

156

Modélisation, Architectures logicielles et matérielles / Re : TCO + Aiguilles avec Processing 4.2

« le: juin 08, 2023, 12:59:45 pm »

Bonjour

Je veux bien vous aider. Mais il me faudrait plus d'informations, un listing du programme peut-être ?

Pierre

157

Modélisation, Architectures logicielles et matérielles / Re : TCO + Aiguilles avec Processing 4.2

« le: mai 05, 2023, 01:23:25 pm »

Quelle led ?

Pierre

158

Modélisation, Architectures logicielles et matérielles / Re : TCO + Aiguilles avec Processing 4.2

« le: mai 04, 2023, 01:15:02 pm »

l'étape suivante serait de pouvoir relier la position de l'aiguille  avec sa led d'occupation en "Processing".

Je ne comprends pas de quoi il s'agit

Pierre

159

Modélisation, Architectures logicielles et matérielles / Re : TCOlocodrome4C

« le: mai 03, 2023, 10:56:43 am »

Il faut qu'il y ait un Arduino avec le bon logiciel (gestionnaire) branché sur un port usb. Il faut aussi chercher le n° du port où est branché l'Arduino (dans la liste affichée, n° de 0 à n-1) et le mettre dans la variable NO_PORT.

Pierre

160

Modélisation, Architectures logicielles et matérielles / Re : TCOlocodrome4C

« le: mai 03, 2023, 09:29:25 am »

C'est juste un avertissement (warning) sans importance ici, en général les avertissements sont écris en jaune/orange tandis que les erreurs le sont en rouge

Les paramètres c et n des méthodes sont nécessaires pour le polymorphisme (mécanisme essentiel de la programmation objet) mais ils ne sont pas utilisés dans ce cas particulier.

Pierre

161

Modélisation, Architectures logicielles et matérielles / Re : Re : TCO avec Processing 4.2

« le: avril 24, 2023, 06:09:30 pm »

    boolean  cli=false;
        int temps=0;
  void draw() {
       if (millis()-temps>=500) { cli=!cli; temps=millis(); }     

Non cela ne va pas. les 4 ligne ci dessus sont à mettre à la place du draw() dans le premier onglet !!!

et doivent êtres enlevées du  PaveSignal

Pierre

162

Modélisation, Architectures logicielles et matérielles / Re : Re : TCO avec Processing 4.2

« le: avril 24, 2023, 05:40:11 pm »

j'ai enlevé:  "boolean  cli=false; int temps=0; "              dans PaveSignalPn,

Ils devraient être juste devant le  draw() !!!

Pierre

163

Modélisation, Architectures logicielles et matérielles / Re : TCO avec Processing 4.2

« le: avril 24, 2023, 01:54:03 pm »

Bonjour

    boolean  cli=false;
     int temps=0;

cela n'a rien à faire dans  PaveSignalPn, cela empêche de clignoter

Pierre

164

Modélisation, Architectures logicielles et matérielles / Re : TCO avec Processing 4.2

« le: avril 22, 2023, 11:15:07 am »

Faut essayer !

Pierre

165

Modélisation, Architectures logicielles et matérielles / Re : TCO avec Processing 4.2

« le: avril 21, 2023, 03:56:06 pm »

Il faut remplacer le   void draw() {   par le bout de programme fourni

Pierre