super car faire des mesures me parait bien utileCC72000 a écrit:... En ce qui concerne l'outil mesure qui vient perturber la séquence en deuxième phase, je ne l'avais pas vu, mais je vais modifier cela, c'est d'ailleurs bizarre parce que j'ai fait des modifs pour qu'il ne vienne plus casser la séquence, mais en deuxième phase effectivement cela ne va pas.
si ces contrôles peuvent donner une popup d'alerte la plus explicite possible.CC72000 a écrit:Pour les contrôles sur les branches courtes, quand les paramètres sont incompatibles avec la longueur de celle-ci, je vais bien sur mettre des contrôles, j'y avais pensé et puis je les ait oubliés, parce que je voulais corriger la version du 1er juin qui donnait une signalisation inexploitable.
A noter que pour sommer une branche (hors tiroir), en plus de Lmini, on a 2 fois L1 ou L2 ... et au début je commençais à me gratter la tête !
tu n'es pas le seul je croisCC72000 a écrit:Pour ces histoires de phases, je n'ai pas encore eu le déclic pour les mettre en musique, et pour le moment ce n'est pas satisfaisant.
Je vais exposer ici le problème qui me pré-occupe :
- Il y a les règles de la signalisation que j'ai reprise dans la documentation sous la forme des 4 commandements pour en faciliter leur compréhension. Ce qui part du principe qu'un utilisateur lit la documentation avant de commencer
Effectivement !CC72000 a écrit:- il y a le découpage en BLOCK qui est fait à la construction du module et qui s’appuie sur la signalisation mise en place par l'utilisateur, qui normalement doit respecter les règles. Mais souvent comme les nombreux postes sur le forum en témoignent, une signalisation plus ou moins hétéroclite donne des BLOCK's plus ou moins hétéroclites...
Les BLOCK's ainsi construits ne sont pas enregistrés dans le fichier .lay, ils sont recalculés à chaque ouvert du fichier.
- il y a les itinéraires "classiques" qui s'appuient sur les segments et sur les signaux, mais pas sur les BLOCK's. Il y a les itinéraires à la volée qui s'appuient sur les BLOCK's, et les sections parallèles qui sont un mixte des deux, ce sont des itinéraires "classiques" sur les-quels on vient greffer des SP qui s'appuient sur les BLOCK's et qui sont vérifiées à chaque ouverture de fichier.
- la signalisation automatique, première phase, c'est à dire la protections des Zones d'aiguilles est un calcul théorique pour un jeu de paramètres L1, L2 et L mini de déterminer très précisément pour chaque segment, la zone d'aiguilles ou la branche à laquelle il appartient. Cette nouvelle propriété d'un segment est enregistrée dans le fichier .lay.
Les paramètres L1, L2 et Lmini ne sont pas enregistré dans le fichier .lay
- Une fois ce calcul fait, il est très "facile" de mettre les feux de protections sur une situation vierge, donc en ayant au préalable détruit la signalisation mise par l'utilisateur, les détecteurs et les actionneurs, les itinéraires et les contextes. Remarque la fenêtre de confirmation n'est lancée que lorsqu'il existe des itinéraires ou/et des contextes. (la première fois, il sont supprimés, donc ils n'existe plus pour un nième clique sur AbraKadAbra...
... je "sentais" bien que la chose n'était pas si simple.CC72000 a écrit:- Comme je l'ai écrit dans la doc, cette phase est importante... elle doit être vérifiée dans les BLOCK's qui en résultent avant de poursuivre, et il faudrait que je trouve un truc pour "valider" cette phase, pour le moment je ne vois pas comment le faire.
- Pour la phase suivante, il faut que les branches soient déterminées par le calcul précédant, pour le moment le critère pour avoir accès à cette phase n'est pas le bon (1 clic AbraKadAbra dans la session) alors qu'il faut des branches et qu'elles soient valident au sens première phase validée. Ce qui permet de revenir dessus.
- Nous sommes bien devant le problème de l’œuf et de la poule, et je ne voudrais pas avoir d'ennuis avec les coqs gaulois...
- Les BLOCK's sont le résultat d'une signalisation utilisateur (avec les erreurs de l'utilisateur)
- Les Zones d'Aiguilles / Branches sont le résultat des règles rigoureusement appliquées qui permet ensuite de mettre en place une signalisation correcte.
En fait, c'est peut-être se mettre une pression disproportionnée par rapport au bénéfice. Le test que je viens de faire sur mon réseau permet de voir que les modifs à postériori du processus de base permettent beaucoup de souplesse (bon, si ces modifs sont conformes aux exigences de la signalisation ! ... je n'ai pas testé en faisant des âneries !!) et en fait, avec 50 branches, c'est assez rapide (1/2 h en gros) même en y allant avec mesure et réflexion ! La seule chose étant alors de bien informer au départ (doc, fenêtre de confirmation) qu'il faut conduire le processus jusqu'à son terme ... sinon on recommence tout !!! ... tu me diras, faire et défaire ...
heu ... les cas sont peut-être assez faciles (sur le principe) à automatiser : signaux en sortie de tiroir : 2 feux blanc/violet, signaux Tête-Bêche : 3 feux de cantonnement, signaux pour voies encadrant aiguille ou grill : carré 4 feux ... après il ne resterait plus que des cas particuliers éventuels à reprendre "à la main" (sachant que le type de feu n'a pas d'importance au sens CDM, et que de toute façon, avec 3 feux, aux abords des gares notamment, on sera toujours loin d'être conforme à la SNCF, alors ... !!)CC72000 a écrit:Pour les petits feux violet de Maxime, pour le moment je n'ai pas jugé utile de mettre un bouton "type de feu" mais j'ai mis le feu le plus standard, sachant que dans ton cas, le clic AbraKadAbra place 191 feux en protection, j'imagine bien qu'ils ne soient pas tous identiques, donc il faut ensuite les reprendre pour les personnaliser (avec l’inconvénient actuellement c'est que l'outil d'édition peut changer de sens un signal) Mais si je fait comme je l'ai indiqué dans la doc, cette phase "branche" plus graphique, je pourrais mettre une sélection du type de feux... mais j'ai déjà tassé le tout pour que cela rentre dans ta définition d'écran... bon là je rigole, j'espère que tu ne m'en veux pas.
A + et bonne soirée
