des éléments répartis par cantons comme le suggère Christophe pourraient-ils être réunis dans un gestionnaire centralisé ?
Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !
Revenons d’abord aux préoccupations principales :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.
- la topographie : comment obtenir le graphe complet du réseau, par exemple pour l’afficher sur un TCO ?
- 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.
-les itinéraires : on y reviendra plus tard, l’algorithme de choix étant une option.Je suis tout à fait d'accord avec toi.
Le seul point pour lequel j'interviens est qu'on a parlé de PC et Mac, mais il ne faut pas oublier qu'il y a PC-Windows et PC-Linux (qui est mon cas).
Je pense que s'il y a une interface sur ordinateur, elle doit être "universelle", comme un navigateur web.
Ce que vient de dire Christophe m'inquiète aussi quant à la capacité de calcul des ESP32.
Pour moi, ce que fait sa "carte de canton" est très simple : enregistrer qui est le canton suivant dans chaque sens en fonction de la position des aiguilles en utilisant le bus CAN.
J'ai peine à croire que ça suffise à saturer les 2 cœurs d'un ESP32.
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.
Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !
C’est étonnant car j’utilise un Due avec un seul cœur ARM Cortex M3 a 84mhz, il affiche le réseau à jour sur un écran 5 pouces en même temps et il ne semble pas perdre de messages !
Tu me disais sur ton DUE perdre, non pas des messages mais des trains !!! N'est-ce pas là le problème ?
Ces périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.
De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.
CiterCes périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.
De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.
Si le gestionnaire assure la sécurité, est-ce qu'il ne doit pas filtrer toute commande manuelle, par exemple interdire d'accélérer sur un canton au ralenti, ou interdire d'actionner une aiguille occupée par un train ?
Selon moi, Pierre soulève judicieusement la distinction qu’il faut faire entre gestionnaire et TCO (d’une manière générale) ou tout ce qui permet d’agir sur l’état du réseau ou de visualiser l'état du réseau.@ Christophe
Même si souvent ces deux fonctions sont rassemblées en un seul appareil (logiciel), ce sont pourtant deux choses à bien distinguer au risque de tout mélanger et de n’arriver à rien.
Au risque de se répéter, le gestionnaire doit en priorité assurer la sécurité et afficher la bonne signalisation. Qu’on lui demande de faire de la gestion d’itinéraires n’est finalement qu’une extension des précédentes fonctions.
De fait, le gestionnaire au sens strict n’a pas d’interface graphique, il n’en a pas besoin. Il fonctionne essentiellement en boucle et agit en fonction des informations qu'il reçoit.
Par contre pour les aiguilles, comme d'autres l'on déjà dit, seul le gestionnaire peut manoeuvrer les aiguilles. Sinon risque de manoeuvrer une aiguille avec un train dessus
On voit que Denis a décortiqué des tas de chosesEntre autres, j'ai lu la "Bible" de la signalisation : "La signalisation ferroviaire" de Roger Rétiveau (639 pages !!)
l faut souder une résistance CMS (10 kOhm) entre la roue isolée et l'essieu.
Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls car on ne peut pas les relier à un canton.
Un CANTON, c'est un ensemble de zones avec des signaux à chaque extrémité.
Je reviens également sur la capacité de calcul pour un gestionnaire centralisé qui serait basé sur un microcontrôleur et qui aurait, disons 20 satellites à superviser.
Est-on d’accord que la fréquence moyenne d’envoi par chaque satellite de ses informations d’états est d’environ 100 ms ?
Partant de là, on est d’accord je pense pour considérer que le gestionnaire centralisé devra recevoir et traiter un message toutes les 5ms et donc avoir fait ce qu’il a à faire pour ce satellite donné dans ce laps de temps : Mise à jour des données variables, capteurs ponctuels, arrêt ou ralentissement de la locomotive au besoin, modification de la signalisation.
Sachant que par ailleurs il doit ponctuellement modifier les aiguilles, assurer le suivi des convois !
Je pose vraiment cette question sans arrière-pensée.
Christophe
Comment faites-vous pour associer une locomotive à un canton-zone à la mise sous tension du réseau ou en posant la locomotive sur les rails ?On aborde ici une question dont on ne parle pas souvent qui est l'initialisation du gestionnaire.
Les gestionnaires graphiques le font avec la souris à l’endroit où est la loco, mais si pas d’interface graphique ?
Quand l'une des zones d'un canton est occupée, TOUT le canton est occupé
Et pour le suivi des trains d'un canton à l'autre, j’ai bien ma petite idée de l’algorithme de suivi lors du passage d’un canton-zone à un autre, mais j’aimerais savoir comment d’autres voient la chose.C'est un problème épineux et je suis preneur de solutions originales. Quand une zone passe de l'état libre à occupé on a besoin de savoir quel train rentre dessus. Pour cela on examine les deux zones avoisinantes en fonction de la position des aiguilles, il ni en a au maximum que deux car un train ne peut venir sur une zone que si les aiguilles sont bien positionnées. Si une seule de ces zone est occupée on connait le train (il faut vérifier que c'est possible avec son sens, et sa vitesse), sinon il y a ambiguïté on a deux trains candidats et il faut jouer sur le sens des trains, leur vitesse (arrêt) , le sens des zones, l'état des itinéraires ou des autorisations, ...
Autre question dans le même registre, comment déterminez-vous qu’un convoi à totalement quitté un canton-zone ?Bonjour
Cela me conduit à demander à Pierre "quand le gestionnaire sait il qu’il n’y a pas de train qui chevauche ?"
Mais j’aime bien des choses faisables : par exemple pour connaître la longueur d’un train, il suffit de le faire traverser une zone de longueur connue et de connaître sa vitesse.
C’est ce que je fais sur une zone de parade. La distance est connue et le temps de traversée du train entre les 2 détecteurs de présence donne la vitesse. Ensuite le temps de présence dans la zone donne la longueur du train !
Ça me sert aussi à étalonner les vitesses des trains.
Mais j’aime bien des choses faisables : par exemple pour connaître la longueur d’un train, il suffit de le faire traverser une zone de longueur connue et de connaître sa vitesse.
C’est ce que je fais sur une zone de parade. La distance est connue et le temps de traversée du train entre les 2 détecteurs de présence donne la vitesse. Ensuite le temps de présence dans la zone donne la longueur du train !
Ça me sert aussi à étalonner les vitesses des trains.
Super méthode en effet mais je pense que tu ne peux pas prendre en compte dans ce cas un train qui est plus long que ta section de mesure. Donc cette zone est au plus court la longueur max d un convoi.
On est OK la dessus?
Ltr
@ DominiqueJe suis aussi d’accord avec toi Denis. J
Ta méthode marche, bien sûr, mais il faut repasser par la zone de test pour identifier un problème.
Avec ma méthode (plus complexe à gérer, bien sûr) on le sait très rapidement après qu'on a perdu un wagon.
Prenons un exemple :
Soit 3 cantons de 10 unités de long C1, C2 et C3 et un train de 8 unités de long
Dès que le train a parcouru 8 unités du canton 2, on ne devrait plus rien avoir sur le canton 1. S'il reste une présence sur C1, c'est un wagon perdu.
Une autre méthode, moins précise :
Si le train est présent sur C1 et C2 et C3, c'est qu'on a perdu quelque chose.
Denis
@BobynCo
Christophe, je crois me souvenir que dans ton projet de satellites autonomes l'identification est portée par RAILCOM qui une fois établie ( l Identification) va générer les instructions de freinage pour l'engin moteur concerné.
L indentification au démarrage du système en conception peut s'appuyer sur un mécanisme analogue (AUTO ENROLLING) ( mais il manquera des info sur par exemple le type de convoi, sa longueur…) qui influent sur le bloc, à défaut on fixera a la longueur maxi permise comme taille de convoi sur le réseau.( par ex 3m20)
Je crois qu'il y a une restriction "forte" pour le cas des UM.
En effet en mode "CONSIST MODE" (UM) en principe l'émission RAILCOM du channel1 est désactivée et on se reporte alors à l émission de l adresse active du "couplage" sur le channel2 si la configuration est faite pour cela.
Dans le cas contraire on va avoir deux émissions de la même info ( une par chaque engin moteur) ( avec un risque de parasitage mutuel)( il est peu probable que chacun soit synchro avec son voisin!) soit il faut filtrer pour que par exemple seul l'engin de tête émette et sur le canal 2 dans ce cas. ( je pense mon interprétation conforme)
Chose inédite je n'ai jamais vu de système ayant plusieurs véhicules émetteur en RAILCOM sur une même section. ( plus par restriction que par non réalisation?) Mais peut être y a t il une magie qui le permettrait...
Laurent
// reception d'un message CAN
data = frame.data.bytes[0]; // bit 6 occupation + no de zone
occupation = bitRead(data, 6); // masque occupation 0x40 = bit 6 : True=occupé, False=libre
nzc = data & 0x3F; // No de ZONE detectée
zone* zc; // = zone ou a lieu la detection
zc = tableZones[nzc];
zone* zp; // = zone precedente à trouver
train* tt;
switch (frame.id) { // type de message
case 0x10: // OCCUPATION ou LIBERATION de zone zc venant des détecteurs
if (occupation) {
zc->occuper();
zp = zc->provenance(); // zone précédente
if (zp != NULL) {
tt = zp->train;
zc->train = tt; // marquage du train dans la zone zc de détection
// ensuite il faut mettre à jour les signaux, celui de zp si c'est une limite de canton
}
} else { // liberation de la zone zc
zc->liberer();
zc->train = NULL;
// et mise a jour ds signaux
}
break;void GA3::tracer(int c) {
if (etat) {//droit
myGLCD.setColor(K_ferme);
geo.drawArc(196, 336, 38, 315, 360, 5); //a3
myGLCD.setColor(c);
drawbarreH(196, 298, -27); // z28
}
else { // devié
myGLCD.setColor(K_ferme);
drawbarreH(196, 298, -27); // z28
myGLCD.setColor(c);
geo.drawArc(196, 336, 38, 315, 360, 5); //a3
}
}
GAiguille* Ga3 = new GA3( 3,44 ); // a3 est dans la zone z44Une ZONE correspond à une détection de présence. Ce peut être un rail avec des coupures, une aiguille seule, plusieurs aiguilles.
Comment fait-on pour détecter une présence sur une aiguille ?Oui,
Faut-il isoler l'aiguille complètement ?
Faut-il un ou deux capteurs ?
...?
Un tracé dans ce genre là (en mieux) ?
Bonjour,
J'ai lu vos échanges sur les cantons, zones, N+1, N-2, etc... et vous essayez d'inventer le bogie avant d'avoir inventé la roue.
Il y a deux choses distinctes dans la sécurité des trains : le cantonnement et l'interconnexion (interlocking en anglais)
Et il y a un grand principe : un conducteur ne doit jamais se voir présenter un feu rouge avant d'avoir passé un avertissement.
Pour les signaux de cantonnement pas de souci : on regarde l'occupation de n+1 et le feu n+1 et ça peut se faire localement sans
passer par la centrale.
Mais pour les carrés c'est totalement différent et ça ne peut se faire que par une gestion d'itinéraire.
Un carré ne doit passer au vert (ou jaune) que si un train a demandé le passage vers une destination, que son trajet ne rentre
pas en conflit avec celui d'un autre train et que les aiguilles ont été positionnées pour ce trajet. Et il faut souvent pouvoir gèrer
le feu en avance, alors que le train n'a pas encore passé le signal précédent.
Pourquoi ne pas mettre un carré au vert en l'absence de train si les aiguillages offrent un trajet libre? Parce que si un train arrive
et qu'un autre train demande le passage le feu va passer au rouge devant son nez.
Donc il faut une gestion d'itinéraire qui va gérer des réservations au moins à deux cantons devant un train.
La définition de cantons ne suffit pas pour la gestion des carrés. Il faut définir des trajets constitués de plusieurs cantons,
avec des sens de circulation pour chaque canton avec la possibilité de réserver un trajet pour plusieurs trains si ils vont dans le même sens.
Il faut aussi définir les trajets incompatibles entre eux. Par exemple les trajets utilisant un groupe d'aiguillages ou deux trajets
avec un croisement.
La boucle de retournement pose également un problème particulier (le train en N est aussi en N+2 mais dans l'autre sens!)
La gestion du carré violet impose également le système d'itinéraire car il faut savoir si le train est en manoeuvre ou pas et
ça ne peut pas se faire automatiquement.
Enfin il y a les conflits à longue distance. Par exemple il ne faut peut-être pas engager un train sur une voie unique si il n'y a pas
de voie libre dans la gare suivante.
Voilà ma proposition pour les coupures de zones, les zones, les aiguilles et les signaux.
Bonjour Christophe,
La notion d'itinéraire est INDISPENSABLE. Regarde la gare pourtant assez simple de MERU : c'est même un PRS (Poste tout Relais à transit Souple), le top des itinéraires
D'autre part, le Carré est fondamentalement différent des autres signaux car il peut être commandé manuellement, indépendamment des positions des trains et des aiguilles.
C'est l'Aiguilleur, un métier complexe qui décide (ou non) de lancer un train en fonction de tout un tas de critères.
C'est Etienne66 qui a raison.
Denis
Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.
Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?Non il y a des erreurs et des manques.
Sur mon réseau je suis à la fois le conducteur de toutes les locomotives, aiguilleur et aussi celui qui vend les billets.
Un billet n’est-il pas un itinéraire à une heure donnée et à un prix donné ?
J'avais réalisé un gestionnaire dans TrainZ que j'ai du abandonner car Auran refusait un patch de leur moteur de jeu sans lequel ça ne pouvait pas marcher.
Sans itinéraire le gestionaire ne sait pas où va un train et ne peut donc pas commander les aiguilles.
Si Christophe bouge les aiguilles lui-même c'est que c'est lui le gestionnaire du réseau. Il sait où vont ses trains (donc il connait les itinéraires) et il prend des décisions connaissant ces itinéraires. Et la signalisation est ajustée à ses désirs sans tenir compte de la règle d'or de l'avertissement avant un arrêt.
Et ça peut fonctionner parceque nos trains ont des distances d'arrêt très courtes comparées aux trains réels et n'ont donc pas toujours besoin d'un avertissement.
Bon est-ce bien la version définitive pour que l'on puisse commencer à travailler ?Non il y a des erreurs et des manques.
Pierre
Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel de ralentissement au besoin !Si tu as le contrôle manuel des aiguillages tu peux bloquer un train au dernier moment avec un feu qui passe du vert au carré devant son nez. Ce n'est pas sensé arriver.
Je pensais que l'on avait été clair, la gestion d'itinéraire est optionnelle. Et je ne vois pas pourquoi tu dis que je n'ai pas d'avertissement ??? J'ai même un avertissement et un rappel de ralentissement au besoin !Si tu as le contrôle manuel des aiguillages tu peux bloquer un train au dernier moment avec un feu qui passe du vert au carré devant son nez. Ce n'est pas sensé arriver.
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
La notion d'itinéraire est INDISPENSABLE. Regarde la gare pourtant assez simple de MERU : c'est même un PRS (Poste tout Relais à transit Souple), le top des itinérairesIl existe encore à la SNCF beaucoup de postes d'aiguillages sans itinéraires, par exemple les MU (Mécaniques Unifiés) et le EMU (ElectroMécaniques Unifiés). Dans ces postes une bonne partie de la sécurité se fait avec des tables d'enclenchements mécaniques, mais il y a aussi des enclenchements électriques. Pour faire passer un train l'aiguilleur manoeuvre les bonnes aiguilles avec des leviers si les enclenchements le permettent, puis ouvre le bon signal avec un levier si les enclenchements le permettent. Pas besoin d'itinéraires.
D'autre part, le Carré est fondamentalement différent des autres signaux car il peut être commandé manuellement, indépendamment des positions des trains et des aiguilles.
Pas besoin d'itinéraires.
L'ouverture d'un carré est toujours soumise aux enclenchements, bonne occupation des zones, bonne position des aiguilles, conflit avec d'autres itinéraires, autorisations, ...
Pierre
Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
Redescendez un peu sur terre, on parle de petits trains électriques ! Et dans la vraie vie, ton aiguilleur devenu subitement fou ne peut pas modifier au dernier moment une aiguille ce qui conduira inéluctablement au même résultat.
Je pense que je mettre en pause le temps que vous vous mettiez en phase sur des choses raisonnables et réalistes pour la grande majorité des modélistes qui au fond ne cherchent qu’à se faire plaisir sans se prendre la tête.
@Christophe,
Le mieux serait que tu proposes sur mon plan initial, les zones, signaux, les noms et les circulations que tu envisageraient pour servir de base à tes satellites autonomes.
Je joins le dessin sur lequel tu vas ajouter ces éléments.
Il faut bien que nous partions d'une même référence pour que la discussion soit constructive.
Pour la voie banalisée "simple" voir mon dessin initial et la mettre au "nord" du dessin de Dominique me parait simple à faire.
Je pense aussi qu on peut ajouter une voie en impasse. Cela enrichira bien les scenarios d exploitation...
Nono, non, donne le même cahier des charges à tout le monde et quand vous serez d'accord vous me faites signe.
Bonjour
@Dominique et Denis
Dans cette version V0 les zones Z4 et Z12 sont non utiles car elles sont a attacher aux zones Z6 et Z10 ( électriquement, fonctionnellement aussi)
Le pourquoi est simple pour déterminer une "indépendance" ou une "dépendance" d une aiguille ou d un groupe d aiguille.
Si un mouvement de circulation ne peut passer que par 1 seul endroit alors il y a dépendance ( et donc enclise), si à l inverse on à une ou plusieurs alternative de passage alors on est indépendant et donc des zones séparées.
Rm si on met des à présent des zones séparées alors on se facilite les évolutions futures... ( dont notamment les sections isolées ( éclisse(s) coupure de rail, ...)
Ltr
Chouette ça va être beau 🤩
{
"zones": [
{ "nom":"Z1","no":1 },
{ "nom":"Z2","no":2 },
{ "nom":"Z3","no":3 }
],
"aiguilles": [
{ "nom":"A1","no":1 },
{ "nom":"A2","no":2 },
{ "nom":"A3","no":3 }
],
"voisins": [
{ "voisin1": { "zone":"Z1","vois":"Z2"}},
{ "voisin2": { "zone":"Z1","cas": [
{ "vois":"Z2","aigs":[ {"aig":"A1","pos":"gauche"}, {"aig":"A2","pos":"droite"} ]},
{ "vois":"Z3","aigs":[ {"aig":"A1","pos":"droite"}, {"aig":"A2","pos":"gauche"} ]}
]
}}
]
}Par ailleurs Processing a tous les types de Java : boolean, char, byte, short, int, long, float et double.Bien sûr, Processing possède tous ces types. Mais il n'y a que 3 types pour les Table() : int, float, string.
Je ne suis pas convaincu par la typographie de JSON : c'est lourd et sujet à plein d'erreurs de frappe.
Ce que je crains, c'est qu'on s'achemine vers une méthode totalement incompatible avec mon gestionnaire, bien qu'elle ait, elle aussi, besoin d'un bus CAN pour passer des trains virtuels aux trains réels.
class Node
{
private:
…
…
public:
Node();
Node *nodePeriph [nodePsize];
Aig *aig[aigSize];
Loco loco;
Sensor sensor[sensorSize];
Signal *signal[signalSize];
…
…
} for (byte i = 0; i < nodePsize; i++)
this->nodeP[i] = nullptr;Ou alors, dois-je comprendre que ton gestionnaire et ton outil graphique ne font qu'un ?Oui, justement, le gestionnaire et l'outil graphique ne font qu'un.
Les lignes :
Voir le schéma (il vaut mieux l'imprimer pour pouvoir comprendre et vérifier :
Les zones (en dehors de z3, z4, z11 et z12) sont constituées d'une seule ligne.
Je donne comme nom de ligne un entier (ça prend peu de place) qui démarre par 1, non significatif.
Il est composé du numéro de zone, puis du numéro de ligne dans la zone.
soit 100000+10*z+l
La ligne 0 (= z0) s'appelle 100000
La ligne 1 (= z1) s'appelle 100010
La ligne 2 (= z2) s'appelle 100020
…
La ligne 10 (= z10) s'appelle 100100
Passons maintenant aux appareils de voie :
z3 est composé de 3 lignes :
100031, 100032, 100033
z4 est composé de 2 lignes :
100041, 100042
z11 est composé de 3 lignes :
100111, 100112, 100113
z12 est composé de 2 lignes :
100121, 100122
Comme on le voit, j'ai volontairement mis un 0 comme numéro de ligne quand il n'y avait qu'une ligne dans la zone. Ainsi, quand on lit le nom de la ligne, on sait immédiatement qu'il n'y a pas à chercher d'autre numéro de ligne dans cette zone.
Dans les appareils de voie, les lames donnent une seule direction pour une position donnée.
Donc, la position des lames donne une et une seule ligne.
Le dernier chiffre de la ligne donne donc la position des lames.
Remarque importante :
Les lignes sont orientées et j'ai mis (en rouge sur le schéma) un 0 au début de la ligne et un 1 en fin de ligne.
La notion SNCF de pair-impair est difficilement applicable strictement aux réseaux miniatures à cause des boucles de retournement et, dans la pratique, on pourra toujours trouver des cas où ça n'est pas applicable. Il suffit donc de mettre des 0 et des 1 pour le sens de la ligne ET DE S'Y TENIR.
Comme je l'ai dit, ça fonctionne avec des trains virtuels ... sur un PC.
Donc, il me faut une interface PC/CAN pour que ça marche avec des trains réels.
Mon (gros) problème sera de les synchroniser en position entre le terrain et l'écran (comme dans CDMRail)
Mais je ne vois pas de solution pour passer d'un texte brut avec un fichier JSON dont vous semblez tous avoir besoin.
D'autre part, vous pensez "gestionnaire pur" qui, c'est vrai, n'a pas besoin de TCO.
Or, pour moi, c'est le TCO sur PC qui commande les trains.
On n'a pas du tout la même façon de voir le problème.
Voilà
Denis
CiterLes lignes :
Voir le schéma (il vaut mieux l'imprimer pour pouvoir comprendre et vérifier :
Les zones (en dehors de z3, z4, z11 et z12) sont constituées d'une seule ligne.
Je donne comme nom de ligne un entier (ça prend peu de place) qui démarre par 1, non significatif.
Il est composé du numéro de zone, puis du numéro de ligne dans la zone.
soit 100000+10*z+l
La ligne 0 (= z0) s'appelle 100000
La ligne 1 (= z1) s'appelle 100010
La ligne 2 (= z2) s'appelle 100020
…
La ligne 10 (= z10) s'appelle 100100
Passons maintenant aux appareils de voie :
z3 est composé de 3 lignes :
100031, 100032, 100033
z4 est composé de 2 lignes :
100041, 100042
z11 est composé de 3 lignes :
100111, 100112, 100113
z12 est composé de 2 lignes :
100121, 100122
Comme on le voit, j'ai volontairement mis un 0 comme numéro de ligne quand il n'y avait qu'une ligne dans la zone. Ainsi, quand on lit le nom de la ligne, on sait immédiatement qu'il n'y a pas à chercher d'autre numéro de ligne dans cette zone.
Dans les appareils de voie, les lames donnent une seule direction pour une position donnée.
Donc, la position des lames donne une et une seule ligne.
Le dernier chiffre de la ligne donne donc la position des lames.
Remarque importante :
Les lignes sont orientées et j'ai mis (en rouge sur le schéma) un 0 au début de la ligne et un 1 en fin de ligne.
La notion SNCF de pair-impair est difficilement applicable strictement aux réseaux miniatures à cause des boucles de retournement et, dans la pratique, on pourra toujours trouver des cas où ça n'est pas applicable. Il suffit donc de mettre des 0 et des 1 pour le sens de la ligne ET DE S'Y TENIR.
En gérant les "côtés", c'est comme gérer pair/impair.
La problématique, c'est qu'il y a, de façon sous-jacente, une structure dans JSON (et c'est tout l'intérêt, d'ailleurs) et que le fichier Excel n'a aucune structure. C'est du texte brut.
Remarque : dans mon système, c'est le programme qui remplit le fichier Excel. Là, je l'ai fait à la main pour montrer ce qu'on peut obtenir.
Je suis venu aussi à séparer le gestionnaire du TCO, c'était déjà le cas avec l 'ancien Locoduinodrome.
Je vais avoir d’autres questions mais dans un premier temps, pourquoi la distinction voisin1, voisin2 ?Une zone a deux cotés on entre par un coté et on ressort par l'autre ou inversement. Comme je l'ai déjà dit les appellations précédente et suivante induisent un peu un sens pour la zone, cela me gène avec les zones parcourues dans les deux sens. d'ou mon appellation voisins (1 et 2).
@Pierre, la seconde question ne s'est pas fait attendre.Il faut deux niveaux de définition :
Je ne vois pas comment se fait le cantonnement, j'entends par là quels sont les zones qui appartiennent au même canton ?
Christophe
Zone = là où il y a une détection électrique
@Christophe: tu indiquais que si le nombre d éléments augmente ( tu en as retenus 8) on peut s orienter vers des saturation de mémoire. Si je ne me trompe pas les plus gros ESP32 disposent de 16Mo soit 4 fois ceux que tu a retenus pour tes satellites autonomes ( mais peut être pas dispo avec USB etc. en module?) Donc jusqu' à cette saturation on a encore un peu de marge.
"p00":"null",
"p01":"null",
"p10":"null",
"p11":"null",
"m00":"null",
"m01":"null",
"m10":"null",
"m11":"null",
class Node
{
private:
…
…
public:
Node();
Node *nodePeriph [nodePsize]; // nodePsize = 4, 6, 8 ...
…
…
} for (byte i = 0; i < nodePsize; i++)
this->nodePeriph[i] = nullptr;Mais livrons-nous à un petit calcul, nous parlons ici de pointeur comme nous l’indique l’astérisque ( Node * nodePeriph[4]), un pointeur, quelque soit l’objet sur lequel il pointe, c’est toujours 16 bits en mémoire.Dans un système avec 4Mo de mémoire les pointeurs sont en 32 bits. Tu peux avoir des pointeurs 16bits sur les UNO mais pas sur les esp32.
Imaginons que nous ayons que nous ayons 25 cantons avec chacun 4 pointeurs cela donne :
25 x 4 X 16 bits = 1600 bits ou /8 = 200 octets. Bon ça commence à faire mais pas de quoi perturber un ESP32 même à 4Mo de mémoire flash.
Christophe
Oh que non!
Et en procédant ainsi, IL N’Y A RIEN D’AUTRE à renseigner. Les aiguilles sont par exemple créées automatiquement par le logiciel. Si P00 est non nul et P01 est non nul, le logiciel en déduit qu’il y a une aiguille. CQFD mon cher Wattson !
Et il en va de même des signaux et même des cibles à placer.
Christophe
@ Christophe
Ton raisonnement sur la description du réseau se tient pour le vrai réseau que tu testes.
Mais quid des croisements ?
Comment peux-tu le décrire ? Il n'y a pas de position des lames. D'une carte canton à l'autre, c'est tout droit, tout le temps, dans les 4 cantons qui l'entourent.
Par ailleurs, il faut tenir compte de l'occupation par un itinéraire, même avec rien dessus. Or je ne vois pas de notion d'itinéraire dans ton gestionnaire.
C'est peut être en gestation et tu ne l'as pas encore développé, mais, à un moment, il te faudra des itinéraires.
Denis
N'y a t'il personne sur ce fil pour faire un peu de modération ?
Écoute Etienne, tu es dans une entreprise de dénigrement systématique :Christophe,
On était parti dans la définition de certains termes.On n'a pas de permissivité possible vu qu'on n'a aucun moyen de gèrer la présence de 2 trains sur un même canton (ce n'est possible qu'avec un comptage d'essieux)
Je propose qu'on indique dans le cahier des charges qu'on a une signalisation type BAL (Bloc Automatique Lumineux).
Il existe à la SNCF de nombreux types de blocs correspondant à différents types de situations. Mais on se limitera ici au BAL qui est le plus utilisé aujourd'hui.
On n'a pas de permissivité possible vu qu'on n'a aucun moyen de gèrer la présence de 2 trains sur un même canton (ce n'est possible qu'avec un comptage d'essieux)On a effectivement pas de permissivité possible mais on peut envoyer une machine sur un canton occupé (pour faire une mise en tête par exemple) avec des itinéraires en manoeuvre, signal carré présentant le feu blanc (M), cela se fait à l'a SNCF dans les grandes gares.
donc on peut utiliser des cibles BAL,BM ou BAPR pour le réalisme vu qu'en réalité on sera toujours informatiquement sur du BAPR.
Si on revenait au JSON de Pierre ?En json on regroupe tout avec des accolades et on y accède avec des "clés", sauf les tableaux dont les éléments sont entre crochets et on y accède avec des indices.
Parce que je suis tout à fait novice sur ce format de données qui m'a l'air intéressant.
Qu'est ce qui doit être entre crochets [...] et qu'est ce qui doit être entre accolades ? {...}
Je pense qu'il faut faire les choses dans l'ordre.Description minimale :
Pour l'instant, on se cadre sur la description du réseau.
Denis
@ EtienneTu as raison.
Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr :P
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?
Denis
Bonjour EtienneD'accord pour la position par défaut et la vitesse.
Sur les aiguillages je pense que tu peux ajouter quelques rubriques utiles:
- position par défaut: droite/déviée
- type de moteur ( servo; solénoïdes, moteur lent,...)
- orientation du moteur ( pour les servo)
On peut peut être aussi évaluer si cet aiguillage doit être couplé à d autres (cas de "bretelles")
Enfin on peut envisager aussi une vitesse de circulation selon les directions( MAX, 70, 60, 30,...)
Ltr
Concernant les positions des aiguilles, on m'a reproché à juste titre (pour les TCOs) que deviée/directe posait des problèmes notamment avec les aiguilles symétriques, et on m'a proposé gauche/droite.Donc pour les aiguillages il faudra gauche/droite/symetrique, et pour le canton on a la position droite ou déviée donc on peut en déduire la direction.
Pour les itinéraires, comme pour le BAL, ou verra plus tard.
Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.
Pierre
Donc pour les aiguillages il faudra gauche/droite/symetrique, et pour le canton on a la position droite ou déviée donc on peut en déduire la direction.Non c'est gauche/droite dans tous les cas (même pour les cantons).
Pour les aiguilles appairées c'est tout simple : un seul décodeur mais 2 aiguilles dans le logiciel avec la même adresse DCC.
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.
Je voudrais ici faire le point sur la manière d'écrire un gestionnaire.
Deux grandes manières :
- écrire du programme comme dans la série d'articles que j'avais proposés
• avantages on peut faire absolument tout ce que l'on veut, c'est la solution la plus performante et la plus souple
• inconvénients c'est généralement un gros programme et il faut avoir de bonnes compétences en programmation (object)
- écrire un fichier qui décrit tout ce qu'il faut, avantages : l'utilisateur n'a pas à écrire de programme juste saisir un fichier, inconvénients : difficultées à saisir le fichier en respectant les règles et limitations à ce qui est prévu. Il faut derrière un programme qui prends en compte ce fichier, plusieurs solutions sont possibles :
• le programme créée des objects en fonction de modèles préétablis, avantages : bonne efficacité, programme assez facile à écrire, inconvenients : le programme qui crée les objects ne sert qu'une fois mais après encombre la mémoire
• le programme élabore du code (lignes de programme) qui sera ensuite compilé pour produire le gestionnaire, avantage meilleure efficacité si le programme fait des optimisations et non présence du programme qui élabore le code dans le gestionnaire, inconvénients : programme qui élabore le code beaucoup plus laborieux à écrire
Pierre
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).
Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).
Pierre
Perso je ne vais pas utiliser un gestionnaire sur Arduino.(J'ai choisi JMRI) je suis juste là pour les conseils.Je verrais plus le json comme intermédiaire entre le PC et l'arduino et un programme à base de menus sur le PC pour créer ce json.Donc si je te comprend bien on fait un programme sur PC pour aider à la saisie (quel language) du fichier json, puis le fichier json sert pour faire le gestionnaire de l'Arduino, avec quelle méthode ( il faut sérieusement envisager aussi de prévoir le gestionnaire pour PC ou mini-PC).
Pierre
En fait dans un gestionnaire tout arduino on n'a plus la liaison USB donc il faut un lien bidirectionnel. Avec loconet et autres on n'a que le sens retrosignalisation. L'autre sens doit passer par la voie avec la limite de débit que ça impose.
Si le gestionnaire est sur PC (ou miniPC) il commande la centrale DCC (trains et accessoires en DCC) comme d'habitude via USB/Ethernet et il récupère la rétrosignalisation comme d'habitude en S88, Loconet, etc. On continue avec JMRI, RocRail, etc.. C'est juste un gestionnaire de plus avec un mode d'emploi comme les autres.
Alors qu'est-ce que ça change de ne pas utiliser le Can ?
Si le gestionnaire est sur une carte Arduino connectée au CAN, comme les aiguilles, détecteurs, signaux avec un satellite V1 ou V2, alors il y a une innovation réelle par rapport aux solutions courantes et des possibilités de modules distribués sur le Can (TCO, manettes, configurateurs).
Je ne cherche pas d'influencer vos choix, mais je préfère la 2ème solution.
Je pense que l'utilisation de JSON permet de créer un fichier suffisamment structuré.Si tu génères la configuration avec le PC en c++ avec la même structure de données que dans l'arduino tu n'as plus
Par contre, jamais un novice n'ira là dedans tout seul.
Or c'est le but de ce fil : avoir un gestionnaire puissant sans être au fait de toutes les subtilités de la SNCF.
Donc, le challenge, c'est d'avoir une interface ordinateur (PC/MAC) simple qui génère le JSON.
Dans ce but, je trouve qu'on devrait s'en tenir, dans un premier temps, au stricts cas utiles dans le Locoduinodrome.
Cela me permettra, au passage, de comprendre un peu mieux ce qu'est vraiment un fichier JSON.
Denis
Pour quelqu'un qui part de zéro, il faut faire un "éditeur de JSON".
Denis
Non, je veux quelque chose qui lui pose des questions.Et surtout ça élimine les erreurs dans le json et donc du code côté arduino. Le code de validation des données est sur le PC.
"Quelle zone voulez vous rentrer ?"
"Dans quel sens voulez vous rouler sur cette zone ?"
etc...
Que l'utilisateur ne soit pas conscient qu'il est en cours d'écriture d'un fichier JSON.
Denis
Validez vous ma vision des choses :
"éditeur de JSON" -> JSON -> Gestionnaire Locoduino
En disant que je m'occupe de la partie "éditeur de JSON", je serai aussi confronté à mon problème : "mon éditeur graphique" -> fichiers textes -> JSON.
Mais c'est mon problème.
Denis
@ Pierre,
Je décortique ta proposition de JSON.
Si j'ai bien compris, Voisins1, c'est "en reculant" et Voisins2 c'est "en avançant" ?
Par ailleurs, dans une TJS, pour aller vers z1 en venant de z3, il suffit que A1 soit tout droit. A3 indifférent. (voir PJ)
{
"nom" : "Z3",
"sens" : "pairimpair",
"aiguilles": [
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A3"
"pos2" : "droite"
"vois1" : "Z5"
"vois2" : "Z0"
}
{
"aig1" : "A1"
"pos1" : "droite"
"vois1" : "Z5"
"vois2" : "Z1"
}
{
"aig2" : "A3"
"pos2" : "gauche"
"vois1" : "Z4"
"vois2" : "Z0"
}
]
},
Mais je ne sais pas si ça a un sens ?{
"nom" : "Z0",
"sens" : "pairimpair",
"aiguilles": [
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "gauche"
"vois1" : "Z2"
"vois2" : "Z3"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "droite"
"vois1" : "Z2"
"vois2" : "Z4"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "gauche"
"vois1" : "Z2"
"vois2" : "Z7"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "droite"
"vois1" : "Z2"
"vois2" : "Z5"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "droite"
"vois1" : "Z2"
"vois2" : "Z6"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "gauche"
"vois1" : "Z1"
"vois2" : "Z3"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "gauche"
"aig3" : "A3"
"pos3" : "droite"
"vois1" : "Z2"
"vois2" : "Z4"
}
{
"aig1" : "A1"
"pos1" : "gauche"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "gauche"
"vois1" : "Z1"
"vois2" : "Z7"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "gauche"
"aig5" : "A5"
"pos5" : "droite"
"vois1" : "Z1"
"vois2" : "Z5"
}
{
"aig1" : "A1"
"pos1" : "droite"
"aig2" : "A2"
"pos2" : "droite"
"aig4" : "A4"
"pos4" : "droite"
"vois1" : "Z1"
"vois2" : "Z6"
}
]
},
En PRS, ça simplifie puisque chaque appareil de voie est une zone, mais, c'est pas facile quand même.
Je viens de tester. Ça fonctionne, mais je ne retrouve pas tous les voisins (ou je n'ai pas compris)Z3 a deux voisins1 et deux voisins2, cela fait 2x2 quatre voisins ?, pareil pour Z11.
z3 et z11 ont plus de 2 voisins et je ne les retrouve pas dans le test, vraisemblablement des choses à rajouter dans le JSON ?
TEST
zone : Z0 voisin1 : Z3 voisin2 : Z11
zone : Z1 voisin1 : Z3 voisin2 : Z11
zone : Z2 voisin1 : Z12 voisin2 : Z4
zone : Z3 voisin1 : Z4 voisin2 : Z0
zone : Z4 voisin1 : Z3 voisin2 : Z6
zone : Z5 voisin1 : Z7 voisin2 : Z3
zone : Z6 voisin1 : Z4 voisin2 : Z8
zone : Z7 voisin1 : Z9 voisin2 : Z5
zone : Z8 voisin1 : Z5 voisin2 : Z10
zone : Z9 voisin1 : Z11 voisin2 : Z7
zone : Z10 voisin1 : Z8 voisin2 : Z12
zone : Z11 voisin1 : Z9 voisin2 : Z9
zone : Z12 voisin1 : Z10 voisin2 : Z2
@ Denis
Faut pas trop s'inquiéter, le fichier json a encore plein d'erreurs (Z3 c'est une erreur) et je n'ai toujours pas eu de réponses sur le nommage des TJS, mais je pense que pour les TJS (comme les TJD) il faut la position des deux aiguilles, à voir.
Faut plus se focaliser sur la forme du fichier json et sur son traitement.
Pierre
Aigs [A1, A2, A3, A4, A5, A6]
Zones [
Z0->Z3•Z11,
Z1->Z3•Z11,
Z2->Z12•Z4,
Z3->[Z5_si_[A1=droite, A3=droite],
Z4_si_[A1=gauche, A3=gauche]]•[Z1_si_[A4=droite, A3=droite],
Z0_si_[A1=gauche, A5=gauche]],
Z4->[Z2_si_[A2=droite],
Z3_si_[A2=gauche]]•Z6, Z5->Z7•Z3,
Z6->Z4•Z8,
Z7->Z9•Z5,
Z8->Z5•Z10,
Z9->Z11•Z7,
Z10->Z8•Z12,
Z11->[Z9_si_[A5=gauche, A6=gauche],
Z12_si_[A5=droite, A6=droite]]•[Z9_si_[A5=gauche, A6=gauche],
Z12_si_[A5=droite, A6=droite]],
Z12->Z10•[Z2_si_[A4=gauche], Z11_si_[A4=droite]]]
TEST
zone : Z0 voisin1 : Z3 voisin2 : Z11
zone : Z1 voisin1 : Z3 voisin2 : Z11
zone : Z2 voisin1 : Z12 voisin2 : Z4
zone : Z3 voisin1 : Z4 voisin2 : Z0
zone : Z4 voisin1 : Z3 voisin2 : Z6
zone : Z5 voisin1 : Z7 voisin2 : Z3
zone : Z6 voisin1 : Z4 voisin2 : Z8
zone : Z7 voisin1 : Z9 voisin2 : Z5
zone : Z8 voisin1 : Z5 voisin2 : Z10
zone : Z9 voisin1 : Z11 voisin2 : Z7
zone : Z10 voisin1 : Z8 voisin2 : Z12
zone : Z11 voisin1 : Z9 voisin2 : Z9
zone : Z12 voisin1 : Z10 voisin2 : Z2
(...)
- un seul train par canton,
- des signaux positionnés selon ces règles (sémaphores, carrés, avec ralentissement, etc..),
- des commandes des trains pour le respect des ralentissements et arrêts selon la signalisation,
- des détecteurs de présence et/ou d'identification(RFID, RailCom) des trains par canton, zone, aiguille, etc.
(...)
Dominique
Colonne
{
"zones" : [
{
"nom" : "Z1",
"sens" : "Pair",
"vois1" : "Z2",
"vois2" : "Z3",
}
]
}
@ EtienneTu as raison.
Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr :P
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?
Denis
D'accord pour la position par défaut et la vitesse.suffit pas : si tu fais une commande segmentée des moteurs , il faut (tout simplement) attendre le moment où le dernier moteur a terminé sa course
Pour les moteurs c'est plus un problème à régler au niveau du décodeur. Et il suffit d'une temposisation entre le moment où
on change les aiguilles et l'ouverture du signal pour tenir compte des moteurs lents.
(...)
Il est vrai qu'à la SNCF les bretelles sont traitées spécialement, les deux aiguilles sont appairées, elles sont nommées Axa et Axb et toujours manoeuvrées ensembles, pour des raisons de sécurité.as t'on besoin de faire pareil.
Pierre
Avec loconet et autres on n'a que le sens retrosignalisation. L'autre sens doit passer par la voie avec la limite de débit que ça impose.à priori non , les messages de commande transitent par loconet , donc ils peuvent être utilisés par les décodeurs ; cela a d'ailleurs été vendu comme moyen d'alléger le traffic des packets dans le DCC
Le CAN étant bidirectionnel il s'impose comme la solution idéale.
Terminologies :gauche/droite cela marche des tous les cas
Je propose d'employer TD pour tout droit et DV pour dévié.
Pour les aiguilles enroulées, TD sera la voie à grand rayon et DV celle à petit rayon
J'appelle AB la première diagonale d'une TJD (TJS, croisement) et CD la deuxième diagonale pour les TDje vois pas trop l'utilité dans le fichier json
J'appelle AD et CB les deux courbes d'une TJD (en DV)
Pour une aiguille simple, AB pour TD et AC pour DV
Pour un triple, AB pour TD et AC pour la gauche et AD pour la droite
Je ferai le JSON avec, en plus, les données vitesses limites.oui on peut associer des vitesses, mais où les mettre, ce n'est pas urgent
Dans les zones, cela correspondra aux TIV, pour les aiguilles, sur voie DV (30, 60 et 160)
Je ne sais pas s'il y a des limites de vitesse en TD sur TJD.
Je propose de mettre "banalise" au lieu de "pairimpair"pourquoi pas mais dans mon esprit il pourra avoir des variantes avec les manoeuvres , du
Je sortirai deux ArrayList "Zones" et "Aiguilles" et, éventuellement, un 3ème ArrayList pour les connecteurs, si c'est utile.dans mon esprit les voisins sont les connecteurs, mais à revoir
Par contre, là, j'ai vraiment besoin de savoir comment on rentre une tjd, une tjs et ... un croisement (l'éternel vilain canard :() dans le JSON. J'ai mis quelque chose, mais je ne suis pas sûr de moi.Pour une TJD ou une TJS on met deux aiguilles (il y a deux noms de prévu), pour un croisement je le considère comme une aiguille sans moteur (c'est utile si on veut des tracés d'itinéraires continus).
"trajets" : [
{
"trajet" : "AB",
"voisin1" : "Z5",
"voisin2" : "Z1",
"aigs" : [
{
"aig" : "A1",
"pos" : "droite"
},
{
"aig" : "A3",
"pos" : "droite"
}
]
},
{
"trajet" : "AD",
"voisin1" : "Z5",
"voisin2" : "Z0",
"aigs" : [
{
"aig" : "A1",
"pos" : "droite"
},
{
"aig" : "A3",
"pos" : "gauche"
}
]
},
{
"trajet" : "CD",
"voisin1" : "Z4",
"voisin2" : "Z0",
"aigs" : [
{
"aig" : "A1",
"pos" : "gauche"
},
{
"aig" : "A3",
"pos" : "gauche"
}
]
}
]
J'ai beaucoup de mal à comprendre les demi-trajets pour les appareils de voie à base de croisements.Le point fictif c'est le centre du croisement, et l'aiguille fictive sert à sélectionner les bons demi-trajets
Il faut imaginer un point fictif, partir de ce point et ne parler que d'une aiguille alors qu'il en a deux...
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
"Zone": [
[
"nom" : "Z3",
"sens" : "banalise",
"trajets" : [["Z5","Z1",["A1","droite","A3","droite"]
["Z5","Z0",["A1","droite","A3","gauche"]
["Z4","Z0",["A1","gauche","A3","gauche"]]
]
[ "nom" : "Z4",
"sens" : "pair",
"trajets" : [["Z3","Z6",["A2","gauche"]
["Z2","Z6",["A2","droite"]]
]
]Mes impressions sont le suivantes principalement par rapport à ce que je m'attendais à voir venir.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.
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).
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).
Re-bonjour,
Je suis inquiet.
J'étais rentré sur ce fil (et je m'y suis investi) pour trouver une solution à mon problème : trouver une interface Processing-CAN pour faire marcher mon gestionnaire et l'améliorer avec des idées nouvelles qui seraient développées dans ce fil.
J'y ai appris l'existence de fichiers JSON qui, à mon avis, permettent d'unifier le passage de la description de réseau au gestionnaire.
Mais si le but est obligatoirement de porter le gestionnaire sur un ESP32, là, je ne trouverai jamais la solution à mon problème.
Denis
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
Je continue mes recherches. Je pense que c'est assez simple. Au moins une question supplémentaire : la zone est-elle une zone de manœuvre ?
Denis
Concernant les signaux leur génération automatique pose pas mal de problèmes :Je pose la question de l'emplacement dans le programme
- il faut trouver où les implanter
- il faut trouver le bon type de signal (un S ou un SR, ...)Je demande les vitesses, on doit donc pouvoir en déduire pas mal de choses
- 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 violetsJe vais poser une nouvelle question : zone de gare (pour ne pas afficher S) et zone de manœuvre pour les feux spécifiques.
inline GZone* GZone::selonAiguille(GAiguille* a,GZone* z1,GZone* z2) { return a->directe()?z1:z2; } GZone* GZ6::suivantePaire() {
return selonAiguille(Ga16, selonAiguille(Ga13, NULL, Gz39), selonAiguille(Ga15, NULL, Gz2));}ou GZone* GZ26::suivanteImpaire() {
return selonAiguille(Ga0, selonAiguille(Ga1, Gz27, selonAiguille(Ga3, NULL, Gz44)), selonAiguille(Ga2, NULL, Gz15));}#define leds_iti (1 + 14)// 1 + nombre max de leds dans l'itinéraire
// la 1ère colonne donne le nombre de leds dans le chenillard
// les leds hors chenillard (aiguilles protégeante) sont à ajouter à la fin
const uint8_t led_iti[itis * leds_iti] PROGMEM = { /// protégeantes à revoir /// problématique du sas ?
// ↓ iti ↓nb 1 2 3 4 5 6 7 8 9 /*-*/ 10 11 12 13 14 <- led
/* h6_sa */ 5, d_h6, d_h6a, d_h5r, d_h4r, d_s_n, /*-*/ d_h3n, o_, o_, o_, o_, o_, o_, o_, o_, // 0
/* h5_sa */ 5, d_h5, d_h5a, d_h5n, d_h4r, d_s_n, /*-*/ d_h3n, o_, o_, o_, o_, o_, o_, o_, o_, // 1
/* h4_sa */ 4, d_h4, d_h4a, d_h4n, d_s_n, /*-*/ d_h3n, o_, o_, o_, o_, o_, o_, o_, o_, o_, // 2
/* sa_th */ 3, d_s_n, d_t_n, d_th, /*-*/ d_s2n, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, // 3
/* h6_th */ 9, d_h6, d_h6a, d_h5r, d_h4r, d_s_r, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_h3n, d_s3n, d_e1n, o_, o_, // 4
/* h5_th */ 9, d_h5, d_h5a, d_h5n, d_h4r, d_s_r, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_h3n, d_s3n, d_e1n, o_, o_, // 5
/* h4_th */ 8, d_h4, d_h4a, d_h4n, d_s_r, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_h3n, d_s3n, d_e1n, o_, o_, o_, // 6
/* h3_th */ 8, d_h3, d_b3n, d_h3a, d_h3n, d_h3b, d_e2n, d_s2r, d_th, /*-*/ d_b2n, d_s_n, d_s3n, d_e1n, o_, o_, // 7
/* h2_th */ 7, d_h2, d_b2n, d_h2a, d_h2r, d_s3r, d_s2r, d_th, /*-*/ d_b3n, d_p_r, o_, o_, o_, o_, o_, // 8
/* h1_th */ 8, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3r, d_s2r, d_th, /*-*/ d_p_r, o_, o_, o_, o_, o_, // 9
/* tp_th */ 8, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3r, d_s2r, d_th, /*-*/ o_, o_, o_, o_, o_, o_, // 10
/* h6_hd */ 10, d_h6, d_h6a, d_h5r, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, d_s3n, d_e1n, o_, // 11
/* h5_hd */ 10, d_h5, d_h5a, d_h5n, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, d_s3n, d_e1n, o_, // 12
/* h4_hd */ 9, d_h4, d_h4a, d_h4n, d_s_r, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, d_s3n, d_e1n, o_, o_, // 13
/* h3_hd */ 9, d_h3, d_b3n, d_h3a, d_h3n, d_h3b, d_e2n, d_s2n, d_s1n, d_hd, /*-*/ d_b2n, d_s_n, d_t_n, d_s3n, d_e1n, // 14
/* h2_hd */ 8, d_h2, d_b2n, d_h2a, d_h2r, d_s3r, d_s2n, d_s1n, d_hd, /*-*/ d_b3n, d_p_r, d_t_n, o_, o_, o_, // 15
/* h1_hd */ 9, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3r, d_s2n, d_s1n, d_hd, /*-*/ d_p_r, d_t_n, o_, o_, o_, // 16
/* tp_hd */ 9, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3r, d_s2n, d_s1n, d_hd, /*-*/ d_t_n, o_, o_, o_, o_, // 17
/* h6_hm */ 10, d_h6, d_h6a, d_h5r, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_t_n, o_, o_, // 18
/* h5_hm */ 10, d_h5, d_h5a, d_h5n, d_h4r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_t_n, o_, o_, // 19
/* h4_hm */ 10, d_h4, d_h4a, d_h4n, d_s_r, d_s_r, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_t_n, o_, o_, // 20
/* h3_hm */ 9, d_h3, d_b3n, d_h3a, d_h3n, d_h3b, d_e2n, d_s2n, d_s1r, d_hm, /*-*/ d_b2n, d_s_n, d_p_r, d_t_n, o_, // 21
/* h2_hm */ 8, d_h2, d_b2n, d_h2a, d_h2r, d_s3r, d_s2n, d_s1r, d_hm, /*-*/ d_b3n, d_p_r, d_e2n, d_s1n, o_, o_, // 22
/* h1_hm */ 9, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3r, d_s2n, d_s1r, d_hm, /*-*/ d_p_r, d_e2n, d_s1n, o_, o_, // 23
/* tp_hm */ 9, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3r, d_s2n, d_s1r, d_hm, /*-*/ d_e2n, d_s1n, o_, o_, o_, // 24
/* h3_se */ 5, d_h3, d_b3r, d_h2a, d_h2r, d_s3n, /*-*/ d_p_r, d_e2n, o_, o_, o_, o_, o_, o_, o_, // 25
/* h2_se */ 5, d_h2, d_b2n, d_h2a, d_h2r, d_s3n, /*-*/ d_p_r, d_e2n, o_, o_, o_, o_, o_, o_, o_, // 26
/* h1_se */ 6, d_h1, d_h1a, d_h1b, d_h1r, d_h2n, d_s3n, /*-*/ d_p_r, d_e2n, o_, o_, o_, o_, o_, o_, // 27
/* tp_se */ 6, d_tp, d_tp1, d_tp2, d_p_n, d_h2n, d_s3n, /*-*/ d_e2n, o_, o_, o_, o_, o_, o_, o_, // 28
/* se_hm */ 2, d_e1n, d_hm, /*-*/ d_s1n, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, // 29
/* tp_p1 */ 7, d_tp, d_tp1, d_tp2, d_p_r, d_p1n, d_p1a, d_p1, /*-*/ d_h1r, o_, o_, o_, o_, o_, o_, // 30
/* tp_p2 */ 8, d_tp, d_tp1, d_tp2, d_p_r, d_p1r, d_p2a, d_p2r, d_p2, /*-*/ d_h1r, o_, o_, o_, o_, o_, // 31
/* tp_p3 */ 8, d_tp, d_tp1, d_tp2, d_p_r, d_p1r, d_p2a, d_p4n, d_p3, /*-*/ d_h1r, o_, o_, o_, o_, o_, // 32
/* tp_p4 */ 8, d_tp, d_tp1, d_tp2, d_p_r, d_p1r, d_p2a, d_p4r, d_p4, /*-*/ d_h1r, o_, o_, o_, o_, o_, // 33
/* h3_h2 */ 3, d_h3, d_b3r, d_h2a, /*-*/ o_, o_, o_, o_, o_, o_, o_, o_, o_, o_, o_ // 34
} ;
@trimarco232
La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
certes , mais en analogique , il faut une alim traction dédiée à chaque itinéraire compatible , j'ai restreint pour éviter ça
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.
c'est pour cela que je planche sur ça https://forum.locoduino.org/index.php?topic=1601.0 (https://forum.locoduino.org/index.php?topic=1601.0)
et donc pour ça que je suis ce que tu fais , car il me faudra quelque chose pour le piloter , tout en haut
Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.
mon principe perso , c'est de banaliser tout le réseau , et d'ailleurs d'avoir tout en VU , pour économiser de la place
Denis
Pour commencer la discussion sur les manoeuvres, quelques précisions :
Il n'y a pas de différences entre les carrés violets haut et bas.
Pierre
Je posterai sur mon projet en temps voulu.
…
Après il faudra des tutos et ça risque d'être long.
L'interface avec JMRI (en direct USB, sans can ni c-mri ni autres bus préhistoriques) va générer automatiquement les objets avec des noms parlants.
Bonjour,
L'interface avec JMRI (en direct USB, sans can ni c-mri ni autres bus préhistoriques) va générer automatiquement les objets avec des noms parlants.
Peux-tu nous en dire plus ?
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).
Pierre
Bonsoir
Pierre dans ce que tu définis comme une "zone de manœuvre" sur laquelle entrer avec une occupation cela me semble aussi ressembler aussi à une option de "forçage" du bloc.
Les cas d'usage sont multiples indépendant du concept de manœuvre pure:
mise en tête/queue d une loco sur une rame assurant une détection de présence sur la zone
cas des UM /couplages
refouler /avancer une loco qui "aurait fait des petits" pour raccrocher
Pour toute ces raison le mode manœuvre ouvre une sorte de dérogation permanente sur des section bien précises
Dans le cas du forçage c est une condition externe à caractère "spécifique et temporaire".
La facilite c est aussi de tout déclarer possiblement en manœuvre... mais la sécu du bloc va en prendre un coup!...
Ltr
Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.
Oui : Une zone amont et une zone aval.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
(...) au moins, il faut tondreet tant pis pour la biodiversité ;)
(...)
for (Zone zone0 : toutes_zones) {
//-------------------------------- on balaie toutes les zone0----------------------------------------
if (zone0.type == 99) {
//---------------------------- on part obligatoirement d'une section ----------------------------
for (int cote0 = 0; cote0 < 2; cote0++) {
//------------------------ on teste les 2 cotés de la zone0 ---------------------------------
for (Zone zone1 : toutes_zones) {
//-------------------- on balaie toutes les zone1 ---------------------------------------
if ( zone1.type == 99) {
//---------------- on part obligatoirement d'une section ----------------------------
if (zone1 != zone0) {
//------------ on ne peut pas avoir zone0 = zone1 -------------------------------
for (int cote1 = 0; cote1 < 2; cote1++) {
compte_ori_ext++;
zone_depart = zone0;
cote_depart = cote0;
zone_arrivee = zone1;
recherche_itineraires(zone0.connecteur[cote0][0], zone1.connecteur[cote1][0]);
}
}
}
}
}
}
}
Je fais la distinction car j'impose aux signaux de n'être que sur des sections
Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.Les zones Z16 et Z30 sont aussi des zones de manoeuvres, mais ne sont pas en blanc ! en fait ce sont des zones hybrides ligne/manoeuvre.
Il y a deux types de limitation de vitesse.Les TIV sont surtout utilisés en ligne, même en présence d'aiguilles (en talon). En présence d'aiguilles en pointe, si la vitesse est limitée à 30 ou 60 on utilise de RR30 ou RR60, sinon un TIV est utilisé. Il y a même des cas ou un RRxx et un TIV sont utilisés pour deux vitesses différentes suivant la position d'aiguilles.
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
- Les limites liées à une position déviée d'aiguille.
A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant.C'est quoi une marche avant ou une marche arrière (par rapport à quoi).
Auparavant, on a permis l'affichage de S, A, VL (Sémaphore, Avertissement, Voie Libre) sur tous les signaux.- a propos de Vl, les carrées d'entrée des gares terminus n'affichent jamais Vl
Remarque : (on l'a déjà dit dans un précédent post) un signal de gare gérée par itinéraires n'affiche pas le S. Donc, quand je donnerai à toutes les voies de gare la possibilité d'afficher le C, il faudra effacer le S.- dans les postes avec des itinéraires permanent, s'il y a du cantonnement, certains carrés peuvent présenter le S, pour assurer la continuité du cantonnement à la traversée d'un gare, d'une bifurcation , ...
Il n'y a qu'un signal de manœuvre : le Cv (Carré Violet). C'est le seul qui ne soit pas un signal de cantonnement.- il peut avoir d'autres signaux qui ne soient pas des signaux de cantonnement (avertissement, carré, ...)
Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.
Les zones Z16 et Z30 sont aussi des zones de manœuvres, mais ne sont pas en blanc ! en fait ce sont des zones hybrides ligne/manœuvre.
Concernant les parités, j'ai abandonné, dans le gestionnaire, les cotés 0/1 ou 1/2 pour des cotés pair/impair, c'est beaucoup plus simple. Et ceci pour toutes les zones. Cela implique aux changements de zone des transitions pair vers impair ou impair vers pair.
Il y a deux types de limitation de vitesse.
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
- Les limites liées à une position déviée d'aiguille.
Les TIV sont surtout utilisés en ligne, même en présence d'aiguilles (en talon). En présence d'aiguilles en pointe, si la vitesse est limitée à 30 ou 60 on utilise de RR30 ou RR60, sinon un TIV est utilisé. Il y a même des cas ou un RRxx et un TIV sont utilisés pour deux vitesses différentes suivant la position d'aiguilles.
A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant.
C'est quoi une marche avant ou une marche arrière (par rapport à quoi).
- à propos de VL, les carrés d'entrée des gares terminus n'affichent jamais VL
- a propos de S, ce feu n'est utilisé que pour le cantonnement (BMU,BAL,BAPR, ...), sur un réseau il peut avoir de parties sans cantonnement (donc avec des signaux sans S)
- dans les postes avec des itinéraires permanent, s'il y a du cantonnement, certains carrés peuvent présenter le S, pour assurer la continuité du cantonnement à la traversée d'une gare, d'une bifurcation , ...
- dans les postes avec du transit souple, s'il y a du cantonnement, les carrés peuvent s'ouvrir au sémaphore (S)
- il peut avoir d'autres signaux qui ne soient pas des signaux de cantonnement (avertissement, carré, ...)
- il y a un autre signal de manœuvre, dans les grandes gares un feu de manœuvre (M : blanc) peut être utilisé pour les départs en manœuvre sur les carrés (compter les feux des signaux de grande gares : 5 feux (A, S, Vl, M, C)
Bonjour ,Citer- dans les postes avec des itinéraires permanent, s'il y a du cantonnement, certains carrés peuvent présenter le S, pour assurer la continuité du cantonnement à la traversée d'une gare, d'une bifurcation , ...Je suis d'accord avec toi, c'est possible, mais pour qu'il y ait du cantonnement DANS la gare, il fait qu'elle soit vraiment grande. Je n'ai pas d'exemple de réseau miniature qui ait eu besoin de ça. Ceci dit, c'est simple à faire : je vais garder le S pour les cas où, DANS une gare, il y a 2 sections qui se suivent.
- dans les postes avec du transit souple, s'il y a du cantonnement, les carrés peuvent s'ouvrir au sémaphore (S)
Mais à partir du moment où il y a des itinéraires, je vois mal l'aiguilleur donner le S. Ou il donne le C, ou il donne au train la possibilité de partir.
il n'est pas logique (voire interdit à la sncf ?) , de présenter une indication M au sol , alors que celle-ci peut être , tout simplement , présente sur le panneauCiter- il y a un autre signal de manœuvre, dans les grandes gares un feu de manœuvre (M : blanc) peut être utilisé pour les départs en manœuvre sur les carrés (compter les feux des signaux de grande gares : 5 feux (A, S, Vl, M, C)Effectivement, il faut penser à cette possibilité. A développer.
Dans la pratique du réseau miniature, je préfèrerais utiliser des signaux au ras du sol pour aller vers les zones de manœuvre depuis les voies principales et ne pas avoir de signal combinant les signaux de voie principale et des signaux de manœuvre. Mais je suis d'accord que ça existe.
1°) Il y a un fichier JSON indépendant qui ne sert pas ?L'onglet Z1 est le json pour l'ancien Locoduinodrome (voie unique en boucle avec évitement), l'onglet Z2 est le json pour le nouveau Locoduinodrome (voie double en boucle avec évitement)
2°) Tu as 2 onglets Z1 et Z2 j'imagine que Z1 est une ancienne version et que tu utilises Z2 ?
3°) Tu utilises maintenant pairETImpair, pairOUImpair. C'est quoi la nuance ?Pour l'instant il y a quatre cas :
4°) Comment tu coderais une zone sans feux (dans une zone de manœuvres, par exemple) ?Comme les autres mais sans signaux
5°) Plutôt que des 0/1, tu utilises exclusivement les notions de pair/impair, partout ?Oui c'est beaucoup plus simple pour le gestionnaire
6°) C'est quoi, les balises ?Le but ultime c'est d'arrêter les trains, même en pousse, juste devant un signal fermé. Pour cela le gestionnaire pourra mettre en oeuvre une odométrie pour localiser les trains. Les balises sont juste une détection ponctuelle des trains un peu avant le signal, cela permet de corriger les erreurs de l'odométrie. En attendant cela sert à arrêter les trains, même un peu brutalement, pour assurer la sécurité, en évitant les zones d'arrêt avec tous les problèmes que cela pose
7°) J'ai un peu de mal avec tes aiguilles : tu as 2 aiguilles dans une bretelle, ce qui est logique, mais je ne vois pas de bretelle, vu que ce sont des TJS. Et je ne vois qu'une aiguille dans les TJS ?Une TJD ou TJS a deux aiguilles indépendantes, on peut avoir une bretelle avec une des aiguille d'une TJD/TJS et une autre aiguille, voire avec une aiguille d'une autre TJD/TJS
8°) Je vois la valeur des ralentissements dans les signaux (en donnant la position de l'aiguille qui nécessite ce ralentissement). Je trouve ça bizarre. Je pense que ce serait plus logique dans l'aiguilleUn ralentissement peut dépendre de la position de plusieurs aiguilles. De plus c'est plus pratique pour le gestionnaire de traiter cela au niveau du signal
9°) Dans les itinéraires, il n'y a qu'une liste de zones. Mais j'aurais tendance à y mettre aussi la position des aiguilles, de façon à ne pas avoir à la recalculer quand on appuie sur un bouton.Oui c'est vrai, mais cela allège le fichier json (pour le nouveau Locoduinodrome il fait déjà plus de 4000 octets)
10°) C'est quoi "auts" ?C'est des autorisations. Quand deux postes d'aiguillages partagent des voies sur lesquelles ils peuvent envoyer des trains, voies uniques, voies à quai, ... il faut se prémunir contre les nez à nez. Pour cela on utilise des autorisations, celui qui a l'autorisation peut envoyer un train l'autre pas (exclusivité). Ce mécanisme n'est utilisé que pour l'ancien Locoduinodrome, pour gérer le partage de la voie unique
Mais pour gérer les itinéraires, il faut que toutes les zones aient un voisin et le plus facile, comme il faut bien mettre quelque chose, j'ai pris le parti de mettre le nom de la zone.Tu peux aussi mettre null, mais tant que cela reste dans ton éditeur cela n'a pas d'importance.
En plus, quand on recherche des itinéraires, on change de sens de parcours aux butoirs. Il n'y a même pas besoin d'avoir un cas particulier, l'inversion se fait d'elle même.
Par ailleurs, j'ai beaucoup de mal à dire qu'une zone est paire ou impaire. Je conçois, par contre, très bien qu'une zone ait un côté pair et un côté impair. Ça me va parfaitement.Il n'y a pas de sens des zones dans le fichier json, les "sens" c'est des sens de parcours autorisés pour les trains
Dans les itinéraires, on a une liste de zones. L'ordre de cette liste donne le sens de parcours. Là encore, l'info "sens" est redondante.C'est vrai, mais le sens est dur à extraire de la liste des zones de l'itinéraire.
Concernant les ralentissements, je propose que cette info soit au niveau des feux R et pas de feux RR, comme ça le train a directement l'info quand il en a besoin.Les trains n'ont pas besoin des infos de ralentissement issues du json, c'est le gestionnaire qui gère.
Mais le fait de ne mettre "rien" soit " ", un blanc…Rien c'est rien, même pas un blanc, pour le fichier json.
Donc "un blanc" peut signifier un butoir !
"a13" : {
"type" : "aiguilleD",
"bretelle" : ["droite", "a16"],
"no" : 13
}
Z25 (section) signal1 signal1
Z26 (triple droit) L0 a0 a gauche + a1 a droite TIV
Z27 (section) signal1 signal1 vitesse maxi 60 km/h TIV
Z29 (triple gauche) L0 a11 a droite + a9 a gauche TIV
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 292
Z25 (section) signal1 signal1
Z26 (triple droit) L1 a0 a droite vitesse maxi 60 km/h RR
Z15 (TJD) L0 a2 a droite + a4 a droite vitesse maxi 30 km/h TIV
Z42 (aiguille droite) L1 a5 a droite vitesse maxi 30 km/h RR
Z14 (section) signal0 signal0 vitesse maxi 30 km/h TIV
Z43 (aiguille gauche) L1 a6 a gauche vitesse maxi 30 km/h RR
Z12 (TJD) L1 a7 a gauche + a8 a gauche vitesse maxi 30 km/h TIV
Z29 (triple gauche) L1 a11 a gauche vitesse maxi 60 km/h RR
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 293
Z25 (section) signal1 signal1
Z26 (triple droit) L2 a0 a gauche + a1 a gauche vitesse maxi 60 km/h RR
Z44 (aiguille gauche) L1 a3 a gauche RR
Z28 (section) signal1 signal1 vitesse maxi 30 km/h TIV
Z29 (triple gauche) L2 a11 a droite + a9 a droite vitesse maxi 60 km/h RR
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 294
"Z22" : {
"nom" : "Z22",
"sens" : "impair",
"signI" : "C1",
"balI" : "B17",
"voisP" : [36,"Z35"],
"voisI" : [37,"Z24"],
"no" : 15
},
"Z23" : {
"nom" : "Z23",
"sens" : "impair",
"signI" : "C3",
"balI" : "B19",
"voisP" : [38,"Z35"],
"voisI" : [39,"Z24"],
"no" : 16
},
"Z24" : {
"nom" : "Z24",
"voisP" : [40,"Z25"],
"voisI" : [[37,"Z22","a18","gauche"],[39,"Z23","a18","droite"]],
"no" : 17
},
"Z25" : {
"nom" : "Z25",
"sens" : "impair",
"signI" : "C5",
"balI" : "B21",
"voisP" : [40,"Z24"],
"voisI" : [44,"Z26"],
"no" : 18
},
(...)bonjour , cette solution me va bien , et je pense que nos figurines , bien que toujours terriblement pressées , peuvent bien s’accommoder d'une milliseconde de traitement supplémentaire
3°) Il est tentant de calculer le nombre de zones parcourues par chaque itinéraire et de prendre l'itinéraire qui a le plus petit nombre de zones. Mais je crains que cela nuise à la fluidité.
Denis :P
Si j'ai bien compris, tu vas mettre le gestionnaire sur un processeur en C++ et continuer à gérer le TCO en Processing.Je préfère, et de loin, écrire et tester le gestionnaire en Processing.
Et échange des infos via un "tuyau" ?
Je préfère, et de loin, écrire et tester le gestionnaire en Processing.Ah oui !! ;D
Concernant la position des aiguilles, pour le gestionnaire, la solution idéale est de pouvoir obtenir leurs positions mais cela nécessite un dispositif approprié sur les moteurs d'aiguille, alternativement le gestionnaire peut positionner systématiquement toutes les aiguilles, mais cela pose problème pour les aiguilles des zones occupées où il y a normalement des trains.J'ai essayé ces deux méthodes :
Concernant les zones il est assez facile d'obtenir leurs états (libre ou occupé), mais quasiment impossible d'obtenir des infos sur les trains qui les occupent.En effet mon TCO manuel (leds d'occupations et de positions d'aiguilles) reflète les états des zones et transmet ces états au gestionnaire via Can.
Les sauvegardes peuvent se faire de différentes façons :En ce qui me concerne, j'ai banni l'ordinateur et je n'ai que des modules sur le bus Can.
- avec un ordinateur ou un mini-ordinateur sur un fichier
- avec un micro-contrôleur sur carte SD ou en mémoire non volatile (eeprom) ou autre