Auteur Sujet: Les SATELLITES AUTONOMES: évolutions du socle initial  (Lu 69338 fois)

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #60 le: février 16, 2024, 02:54:44 am »
Dans la série des "petits module avec USB" il a la gamme de chez SEED STUDIO.

Gros intérêt de la maison SEED STUDIO des brochages similaires( 2 X 7 broches) présentant des pin avec usages similaires ( IC2, TX, RX, SPI...) aux même endroits!

Le cout reste raisonnable compte tenu du service rendu.(on peut même envisager de substituer certains produits par d autres pour peu que l on retrouve ce dont on a besoin! (ex pas de partie  web partout...)

https://wiki.seeedstudio.com/SeeedStudio_XIAO_Series_Introduction/

Les modules à base d ESP32 C3 et S3 tiennent la corde.
pour le C3
https://wiki.seeedstudio.com/XIAO_ESP32C3_Getting_Started/

Pour le S3:
https://wiki.seeedstudio.com/xiao_esp32s3_getting_started/

Un challenger toutefois en S3 mais avec un prix "exotique"( impossible à avoir en volume sinon a 8€... et une distribution des broches différente des SEEED:

https://fr.aliexpress.com/item/1005006495429840.html?src=google&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&isSmbAutoCall=false&needSmbHouyi=false&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005006495429840&ds_e_product_merchant_id=5326656560&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=20871206076&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=CjwKCAiAibeuBhAAEiwAiXBoJBv4vfCDZD0tIRO1RACXZ-dyqSKi0CU-2o9674Jr4EHytD_t2wNAJxoCw0sQAvD_BwE&aff_fcid=6de9d73656b6400f879095c45480380e-1708047788710-05008-UneMJZVf&aff_fsk=UneMJZVf&aff_platform=aaf&sk=UneMJZVf&aff_trace_key=6de9d73656b6400f879095c45480380e-1708047788710-05008-UneMJZVf&terminal_id=bb63e0b038954714a45b278c1b104d79&afSmartRedirect=y

On voir alors que l'offre SEED est plutot bien placée.

Ltr


bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #61 le: février 16, 2024, 01:52:57 pm »
1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi

Bonjour Marc,

Merci pour cet inventaire intéressant car exhaustif.

Je suis d’accord avec toi sur de nombreux points. Tout d’abord, concernant les Arduino, surtout les Nano. On a tendance à les oublier mais pour pas mal de choses, ils font le job. On les accuse de prendre beaucoup de place, pas trop les Nano mais les Mega par exemple. Sauf qu’un Mega c’est 3 ports série, et plus de 40 broches « vraiment » utilisables. Pas de concurrent à ma connaissance de ce point de vue. Et a-t-on toujours besoin de faire petit ?

Pour l’ESP32, je te trouve trop critique et là encore, tout dépend du besoin. Il est indéniable qu’à ce prix, avec les possibilités offertes, c’est absolument canon.

Sans avoir vraiment optimisé le programme, je fais du DCC avec et aussi du Railcom !!! Alors oui, j’ai 25% des trames qui sont hors des spécifications du NMRA mais tout fonctionne depuis longtemps et de façon très satisfaisante.

Et alors, concernant Railcom, je ne te suis plus du tout. Là aussi nous avons un certain recul (1 an ½) et aucun retour négatif. Michel a même testé avec succès trois lectures Railcom simultanées avec le même ESP.

Il y a un peu de doigté sans doute à mettre quand on développe avec l’ESP32. Chercher à utiliser les deux cœurs mais en sachant que toutes les applications asynchrones l’on fait avant nous (Serial, WiFi, CAN, Web…). Je n’ai pas de recul là-dessus mais je désactive maintenant le Wifi quand je n’en ai pas besoin et aussi le port Serie. Est-ce vraiment efficace ? Dans quelle mesure ?

Quant à DCC-Ex, tu confirmes ce qui se présentait qui est qu’ils ne développeront pas Railcom sur ESP32 ce qui n’est pas forcément une bonne nouvelle pour la Box. Ni pour moi, car même si je dispose d’une solution alternative, j’aurais préféré utiliser la Box avec les satellites autonomes.

Que l’on se comprenne bien, je ne dis pas, loin s’en faut, que l’ESP32 est exempt de défauts, mais qu’on ne peut pas l’exclure car il répond à de très nombreux besoins.

Et une fois encore, c’est le besoin puis le prix qui doivent nous guider. N’est-il pas par exemple plus judicieux de mettre deux ESP sur une carte en répartissant les tâches qu’un seul microcontrôleur qui vaut deux fois le prix.

Christophe
« Modifié: février 16, 2024, 02:43:00 pm par bobyAndCo »

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #62 le: février 16, 2024, 03:43:25 pm »
Bonjour

Je me suis avancé à projeter rapidement ce que pourrait être physiquement un décodeur à base  d ESP32 ( version C3 de SEEED STUDIO ici)  avec transceiver CAN MCP2562 pour gérer 2 servos conjointement à 2 relais couplés pour la polarisation de la pointe de cœur de chaque aiguille.

Un bouton pour l'appairage avec un satellite ou pour récupérer un ID CAN voir passer du mode RUN au mode PROG et deux autres boutons pour les valeurs de réglages en + ou en - ( course du servo)

Comme j ai mis des relais "DUAL COILS" le nombre d'I/O est un peu juste ( 11 dispo et 11 utilisées) sans pour autant offrir de témoin visuel pourtant pratique. Sur de simples relais je pourrai récupérer 2 I/O bien utiles pour d'autres usages.
On gagne toutefois la possibilité d avoir une page web pour les réglages.

Ce type de carte a t il du sens?

Si à la place de l ESP32 C3 (version SEED) on a d autres modelés on a peut être un gain...

Ou alors c est un autre type de CPU, comme un MEGATINY mais il faut alors ajouter un module CAN type 2515 ou 2517 et on perd le cote WEB...

J ai du mal à identifier la limite et la bonne combinaison à trouver.

Help!

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #63 le: février 16, 2024, 04:06:42 pm »

Ce type de carte a t il du sens?

J ai du mal à identifier la limite et la bonne combinaison à trouver.

Help!

@Laurent, c'est surtout que je ne vois pas d'où vient ce projet ni où il va ? Quel rapport avec ce fil que tu as toi-même ouvert et que tu as intitulé "Les SATELLITES AUTONOMES: évolutions du socle initial".

Avec ce dont tu parles, je vois plutôt une petite carte indépendante, un peu comme un décodeur d'accessoires en DCC mais ici en CAN, très bien !

Est une évolution du socle initial ? Pour l'instant je vois apparaitre différentes nouvelles propositions de cartes, mais sans voir la cohérence globale.

Comme j'ai pu le dire récemment, il faut réaliser un listing de besoins, le hiérarchiser et tenter de voir globalement comment répondre à ces besoins de façon rationnelle.

J'ai un peu le sentiment que tu procèdes dans le sens inverse, une technologie t'intéresses et tu te demandes ce que tu pourrais faire avec. C'est bien, mais tu es alors dans un processus de prospective et d'expérimentation.

Marc citait DCC-Ex dans un post récent. Au moins, il faut leur reconnaitre d'avoir une vision assez précise et un cheminement qui ne l'est pas moins.

Alors, pour répondre à ta question, oui selon moi cette carte peut avoir du sens, probablement pour se substituer à des commandes de servos en DCC mais dans les satellites, cela est pour l'instant réglé et s'il devait y avoir amélioration, c'est bien sûr toujours possible, je ne pense pas que ça prendra cette forme.

Christophe.

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #64 le: février 16, 2024, 04:40:35 pm »
Hello

L idée était venue pour une question de simplification/rationalisation/manque de place  de ne garder sur la carte satellite socle que l'interface CAN et de déporter les usages sur des cartes externes recevant le CAN comme bus de data.( quitte ensuite à étendre vers I2C, etc...)

C est en ciblant cet usage que j ai pensé à cette carte à titre d'exemple compte tenu d un choix sur ESP32 C3 ( XIAO) SEEED SUTDIO) ( d autres pourrait aussi bien faire le job)

J avais en tête les propos prudents de Marcel et de Michel sur l'usage de l'I2C au delà de 50cm... ce qui ne manque pas d arriver avec un carte satellite "centrale" et des usages à chaque bout d un canton de plusieurs mètres.  D'où le CAN comme "palliatif" au transport "moyenne distance" dirons nous.

J ai en effet les 3 fonctions "de base" à caser sur le socle:
1/PROTECTION/REVERSE
2/DETECTION PRESENCE
3/IDENTIFICATION RAILCOM

Ajoute à cela pour la hardware la gestion de l'énergie avec convertisseur DC DC
et le transceiver CAN avec un ESP32 au cœur du dispositif.

J ai toutefois besoin d I/O en sus et il me faut trouver les bons compromis pour les ajouter.
L'I2C que je pousse en est un moyen. pour une carte fille qui jouxte la carte principale mais pour aller un peu plus loin... le CAN a de nets avantages!

Perso avec des cantons de 3m en gros et des aiguilles à chaque bout la commande centralisée pour des servos est un gageure! (piloter un servo a plus de 2m de distance est une ineptie qui expose à tout un tas de parasites dont je me passe très bien!)
J ai des petits décodeurs locaux pilotant les servos et la polarisation des cœurs par relais mais leur commande est en DCC.( pas la fin du monde non plus!)

Mais comme il n'est pas question de mes solutions passées mais plutôt de solutions au service des satellites autonomes nouvelle version  je cherche des optimums.

Nous avons déjà les 3 besoins de bases identifiés( protection/inversion - détection présence - identification railcom)
Nous les complétons avec les 2 capteurs ponctuels à y ajouter

Vient ensuite la question de la gestion des aiguillages: pour nous dans un premier temps via des servos moteurs et idéalement de la polarisation des cœurs en relation
Vient également la question signalisation
S'ajoute aussi la gestion de boutons de commande distants ou non.

Je pense être complet sur les besoins "primaires" avec cette liste.

Les 3 premiers sont couverts, j'ai les solutions. ( avec un peu de dessin derrière)

Reste la suite!... Mais je conviens que ce que j ai en tête a besoin de schémas pour être compris et débattu.

Ltr


bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #65 le: février 16, 2024, 05:01:43 pm »
@Laurent,

Ok je comprends mieux mais effectivement c'est mieux avec le contexte et le besoin.

Cette carte dont tu parles doit s'analyser dans un cadre un peu plus large que tu as déjà abordé, les modules complémentaires ! Soit complémentaires par fonctions, j'entends par là celle qui ne sont pas des fonctions de base (détection, traction, protection...), soit complémentaire par leur implantation "décentralisée" par rapport au satellite.

Tu abordes ici ce qui est un vrai problème pour des réseaux d'une certaine importante (pas la cible visée par le satellite autonome actuel) qui est la distance entre le satellite et certains accessoires.

Dans l'esprit des satellites depuis le début, la piste est dans des cartes plutôt universelles et versatilles. Alors, oui, des cartes satellites "de sous-ensembles" où serait alors regroupées les différentes réponses techniques qui doivent être déportées en cas de besoin.

Alors, il faut lister ses besoins et la solution viendra ensuite.

Pour l'instant, mais peut-être à tort, j'hésite à m'éloigner des µC que l'on maitrise (Arduino, ESP32, ATTiny), je pense que ces trois là répondent déjà bien et je cherche à ne pas trop de disperser "façon puzzle" et ce n'est déjà pas facile.

Oui c'est vrai que je souhaite privilégier dans l'ordre chronologique :

J ai en effet les 3 fonctions "de base" à caser sur le socle:
1/PROTECTION/REVERSE
2/DETECTION PRESENCE
3/IDENTIFICATION RAILCOM

mais je ne souhaite pas non plus m'ingérer dans la conduite de ton projet !

Christophe

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #66 le: février 16, 2024, 05:22:07 pm »
Pendant que tu me répondais je dessinais ... sous PowerPoint cette fois pour illustrer la topologie que voici illustrée  8)

Oui le cas des distances plus longue est dans le pipe nativement... et aura surement ses propres solutions. ( "type satellites de satellite"  dont par exemple la carte de pilotage de servos esquissée plus tôt)

Pour le choix des CPU on a une assez bonne connaisse combinée des "classiques" cités ( AVR/AVR Dx/MEGATINY,ESP32 )et on doit pouvoir bien s'en sortir avec en conjuguant nos talents.

On imagine bien ici au "sud" (bas)  l'extension 75HC595 sur une approche similaire aux extenders à "l'ouest" (gauche)

Les3 blocs de fonctions en vert ici sont sur des modules enfichables sur le socle et facilement remplaçables (maintenance en cas de panne et ou réutilisation)

Ltr



« Modifié: février 16, 2024, 05:38:41 pm par laurentr »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #67 le: février 16, 2024, 05:37:16 pm »
Oui, outre le fait que ce soit joli, cela me parait cohérent. Je retrouve bien sur la carte principale ce qui doit y être selon moi. Cela la rend utilisable seule ce qui doit suffire pour petits et moyens réseaux. Normalement, compte tenu du fait que j'ai enlevé le RFID, il doit y avoir le nombre de pins.

Pour le soft, il va aussi falloir s'assurer que ça suive mais si on met un µC pour la protection et pour la détection de présence, ça va le faire. Je pense toujours que l'ATTiny pourrait faire le job.

Mais je ne vois pas d'µC sur extenders relais. De même sur extenders I2C (j'en déduit que tu comptes sur l'ESP32), je pense que ça va être dur dur pour le programme !

Merci.

Christophe
« Modifié: février 16, 2024, 05:49:37 pm par bobyAndCo »

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #68 le: février 16, 2024, 05:57:40 pm »
Ca va être à toi de me dire s'il peut traiter l I2C en // ou si c'est trop juste. ( auquel ca on va devoir se creuser pour des solutions)

Les MAGTINY joueront bien leur rôle sur chaque module

C est bien un chip I2C drivé par l'ESP32 qui va (doit)  traiter les I/O nécessaires pour piloter les relais ( leds, servo) supplémentaires) ou des boutons.

Ltr

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #69 le: février 16, 2024, 11:53:25 pm »
Petit ajout pour illustrer en cas d insuffisance de ressource sur l'ESP312 principal pour traiter l I2C un contournement par EXTENDERS incluant un ESP32 communiquant par bus CAN avec le socle du satellite principal.

Ces extenders avec CPU sont aussi un moyen de déporter localement des commandes (de type IN (bouton, detecteur ponctuel, ...) ou OUT (leds, servos, relais, moteurs, ...)

On comprend ainsi la philosophie de la petite carte "satellite de satellite" gérant 2 servo avec 2 relais évoquée plus tot

Ltr
« Modifié: février 17, 2024, 12:03:50 am par laurentr »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #70 le: février 17, 2024, 01:46:03 am »
Merci Laurent, je vois que tu a bien compris et intégré la philosophie générale.

Sur le principe, je préfère cela. Un ESP n'est sans doute pas nécessaire pour extender sat : led mais un autre ESP pour l'ensemble des extenders me plait bien.

J'aimerais bien avoir des avis autres comme de la part des concepteurs initiaux, Jean-Luc, Thierry, Dominique mais je ne pense pas me tromper quand à l'esprit et à la direction.

En fait, je veux être prudent concernant l'ESP principal. Il lui faut en effet maintenir une fréquence élevée pour ne pas louper d'évènements. A terme, la partie du programme qui s'occupe de la gestion de réseau doit pouvoir faire 1 cycle en moins de 100ms.

Si on lui donne trop de choses à calculer, il le fera mais hors délais.

Je vais écrire le code pour tester des charges intensives pour environ 20 satellites simultanément, déjà pour mesurer s'il ny a pas de messages CAN perdus et ensuite pour vérifier la bonne exécution de certaines commandes, surtout celles liées à la sécurité (ordres aux locos, coupure de courant en cas de CC).

Je vais essayer de pousser aux limites en réduisant le timing de la boucle de gestion de réseau de 100 à 90 puis 80 ms... Je peux commencer à écrire le programme de test mais je ne pourrai le mettre en œuvre que début mars.

Je sais qu'il y a des optimisations possibles du programme principal (par exemple à ce stade j'exécute le programme pour un sens de loco et pour le sens inverse.) Je peux aussi jouer sur des tâches secondaires comme l'allumage des signaux : Passer de 1 à 2 secondes n'est par exemple pas bien important.

Christophe
« Modifié: février 17, 2024, 01:50:52 am par bobyAndCo »

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #71 le: février 17, 2024, 02:47:01 am »
J ai exclu la l utilisation du WIFI (nbx effets de bords non désiré lorsqu'il est actif)  en mode AP entre sat et extenders y préférant le CAN. (par défaut)


Voici la vue du premier des 3 blocs fonctionnels en approche modulaire: celui ci gère la partie PROTECTION/REVERSE

Il est opto couplé avec l'ESP32 à qui il notifie un état de CC. l'ESP peut alors effectuer un RST pour (tenter) de corriger le défaut.
Visuellement un indicateur indique si la distribution des pôles DCC (J/K)  est directe ou croisée. Cette information n'est pas transmise à ESP32 ( économie de broches oblige) mais cela serait possible avec ajout d'un opto supplémentaire si cette exploitation de données se révèle pertinente.
A défaut c est auto géré en auto au niveau local.

Ltr

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #72 le: février 17, 2024, 02:58:42 am »
Christophe

Mars n'est pas loin, février n'a que 29 jours  :)

Pour tes tests tu vas pouvoir alléger la partie gestion des CC.
Le module de gestion de protection/reverse va notifier l'état OK/KO(CC) et couper la distribution du signal DCC.L'ESP32 pourra traiter cela comme une priorité (plutôt)  haute ( à définir pour enclencher le SWT qui changera l'état.) Si cet état est persistant l'ESP32 doit temporiser avant de relancer tout autre commande mais dans le même temps il devrait aussi:
A/assimiler le canton comme occupé (en dérangement) et agir sur les trains en conséquence si nécessaire.
B/fermer la signalisation
C/permettre de modifier une position d'aiguille.

Ltr

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #73 le: février 17, 2024, 03:06:10 am »
Juste une petite remarque, tu ne prévois pas de passage de vis ?

J ai exclu la l utilisation du WIFI (nbx effets de bords non désiré lorsqu'il est actif)  en mode AP entre sat et extenders y préférant le CAN. (par défaut)

On est d'accord de passer en CAN tant que cela est possible ou qu'il n'y a aucune tâche critique. C'est le cas pendant le processus de découverte ou quelques millisecondes de plus ou de moins n'ont pas d'importance.

Voici la vue du premier des 3 blocs fonctionnels en approche modulaire: celui ci gère la partie PROTECTION/REVERSE

Il est opto couplé avec l'ESP32 à qui il notifie un état de CC. l'ESP peut alors effectuer un RST pour (tenter) de corriger le défaut.

J'avais compris que tu ne passais pas par l'ESP32 en cas de CC Il n'y a pas besoin selon moi et je croyais aussi que tu avais prévu un système rapide (à l'instar du LENZ 200 je crois) pour couper le DCC. Tu gagnes une broche et surtout en rapidité. Il faut juste prévoir un réarmement du DCC après un petit délais, mais ça ce n'est pas très compliqué. Pourquoi pas le 555 comme dans le montage d'Eric.

Par contre pour l'occupation, il faut informer l'ESP que l'on est au dessus du seuil (réglable). On a dit que ça pouvait être un signal 0 ou 1. Si l'on est au dessus du seuil de CC, ce n'est pas grave, c'est une information "busy" comme pour l'occupation et c'est vrai en plus.

Visuellement un indicateur indique si la distribution des pôles DCC (J/K)  est directe ou croisée. Cette information n'est pas transmise à ESP32 ( économie de broches oblige) mais cela serait possible avec ajout d'un opto supplémentaire si cette exploitation de données se révèle pertinente.

Non je doute que la polarité des rails apporte quelque chose dans le logiciel.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1083
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #74 le: février 17, 2024, 03:13:31 am »

Mars n'est pas loin, février n'a que 29 jours  :)

Bon on n'est quand même que le 16 février ! Et je ne suis pas pressé de rentrer de vacances.

Pour tes tests tu vas pouvoir alléger la partie gestion des CC.
Le module de gestion de protection/reverse va notifier l'état OK/KO(CC) et couper la distribution du signal DCC.L'ESP32 pourra traiter cela comme une priorité (plutôt)  haute ( à définir pour enclencher le SWT qui changera l'état.) Si cet état est persistant l'ESP32 doit temporiser avant de relancer tout autre commande mais dans le même temps il devrait aussi:
A/assimiler le canton comme occupé (en dérangement) et agir sur les trains en conséquence si nécessaire.
B/fermer la signalisation
C/permettre de modifier une position d'aiguille.

Oui tout ça est vrai mais ce sont les autres auront à fermer leur signalisation et adapter le comportement des trains, ce qui est déjà le cas normalement car l'état occupé est déjà envoyé (à 100 ms près).

Christophe