Faire le bon choix ?

JLuc31 a écrit:

Ouaip,
mais il ne suffit pas de remonter l'info vers TC.
Il faut que l'info soit prise en compte par TC et qu'il sache quoi en faire et là ce n'est pas automatique et il faut établir des conditions...

Il me semble que ça c'est le boulot de Jürgen...

Si c'est le boulot de Jürgen ... je ne dis plus rien

Bonjour,
Je ne suis pas aussi matinal que Jean Luc, mais je suis cette affaire de près, mais j'avoue ne pas suivre certains propos.

Pour répondre à Yann, avec l'aide de Jean nous avons posé la question à J. FREIWALD que est je suppose le Jurgen dont tu parles et voici la réponse:

Dear Sir,

thank you very much for your inquiry.

This feature is currently supported in the following way: when a turnout on
the layout changes its position and the connected hardware (decoder)
ensures, that this change is reported back to the ECoS, then this
information is forwarded to the computer screen and the TrainController
refreshes its display accordingly.

Best regards
Juergen Freiwald

Pour les non pratiquants de l'English dont je suis, voici une traduction moins barbare que celle que j'ai mis en ligne sur LR, et que nous devons à notre ami Jean_01 que je remercie au passage:

"Cher Monsieur,

Merci beaucoup pour votre requête.

La fonctionnalité est actuellement supportée de la façon suivante: quand un aiguillage change de position et qu'il est connecté à un décodeur qui assure que ce changement est remonté à l'ECoS, l'information est transmise à l'écran et Train Controller procède au rafraîchissement correspondant de l'affichage."

Il me semble que sa réponse est claire que faut-il de plus

Salutations

Capitole

Bonjour à tous ,

Comme le dit Pascal :

Qu'indique le decodeur comme retrosignalistion ?

1- que l'odre de modifié la position de l'aiguille a été transmis au moteur d'aiguillage si c'est ce cas on ne peut pas être sur que les aiguilles ont bougé.

2 que les aiguilles de l'aiguillage ont réellement bougé si c'est cette dernière comment fonctionne le mécanisme.


Cette question me préoccupe depuis trés longtemps.

Ce problème me préoccupe également depuis longtemps.

En effet RRTC dans sa conception actuelle, en cas d'erreur mécanique d'un aiguillage, ne réagit pas.
En mode itinéraire, il perd totalement le contrôle du train qui poursuit sa route d'une manière fantaisiste et sans éviter les collisions.

QQ chose m'échappe.

En mode itineraire le logiciel doit connaitre son enchainement de blocs.
Chaque bloc est défini au minimum par un contact indicator avec une " adress/input" spécifique.
Donc si la progression connue ( memorisée ) est differente de la progression réalisée, RRTC devrait réagir et envoyer une alarme et bloquer le convoi.
Si mon raisonnement est cohérent et juste, il y aurait une suggestion à faire à Freiwald.

Ce type de protection est utilisé par un autre logciel que j'utilisais precedemment.

Salutations

René

Bonjour à tous

Il est difficile pour RRTC de suivre d'une maniére simple la progression. La méthode existe mais je pense ne pas me tromper si je dis ( les pros arrêter moi si c'est faux) il faut opter pour le systeme qui permet cette fonction qui est à ma connaissance la detection par lecture de code barre coller sous la loco par exemple , ou je crois savoir que certain systeme type Selectrix peuvent le faire mais là je ne suis pas sur du tout pour ne jamais avoir poussé mes investigations plus loin dans ce dommaine.

Pourquoi RRTC ne peut detecter une erreur d'itineraire avec un autre type de detection? Pour la bonne et simple raison que le train reste dans le bloc de l'itinerraire et le quitte lorsqu'il est détecté dans le suivant. Or s'il le train n'est pas detecter dans le suivant pour RRTC( qui ne connait pas la durée de transit dans le BLoc) il est toujours dans le bloc faisant partie de l'itinairaire choisi et ne lui donne pas d'instruction.

Il faudrait donc que RRTC calcul en permanence cette durée de transit qui n'est autre que Longueur du Bloc diviser par vitesse du convoi, et là se pose nombres de questions sur la fiabilité du calcul.

J'espère être comprehensible.

Pas facile à réglé ce sujet vaste débat.

Pour ma part je teste la possibilité de le faire sour forme de programmation mais je ne peux en dire plus pour le moment.


Bon Train à tous

Pascal

Bonjour à tous,

( et en particulier à Pascal )

Certes ce n'est pas simple pour RRTC ( je ne sais pas l'évaluer ) mais mon idée serait d'en faire la demande à Freiwald dans la mesure où elle ne parait pas incohérente pour les autres colistiers.
Il serait toujours temps de voir sa réponse.

Par ailleurs je trouve RRTC très satisfaisant ,très élaboré mais certainement perfectible.

Je n'ai trouvé aucune information de la part des utilisateurs Americains ( cf forum Digitrax).
Il faut dire que leur méthode " pour jouer au train " est differente de celle des Européens.

Cordialement
René

Bonjour René,

Je pense que la réponse de Juergen est claire: si on a un système de rétrosignalisation de la position des aiguilles, c'est la position réelle de l'aiguille qui est remontée. C'est le cas du switchpilot évoqué plus haut qui remonte la position réelle de l'aiguille via Railcom jusqu'à l'ECoS et l'information est reprise par TC.

Conséquence, si un ordre a été donné à l'aiguille et que cet ordre n'a pas fonctionné, la position de l'aiguille sur le TCO ne change pas. Si on était en train de mettre en place un itinéraire, l'itinéraire n'est pas activé: le train est mis en attente dans le canton qui précède l'itinéraire.

Si on n'a pas de rétrosignalisation de la position des aiguilles, et qu'un ordre transmis à une aiguille ne fonctionne pas, TC l'ignore et le train part dans la mauvaise direction. C'est ce que dans le train réel on appelle une erreur d'aiguillage avec les conséquences qu'on connait.

Au niveau du suivi des trains sur le TCO, on voit le mauvais canton occupé et on a la possibilité d'agir sur le bouton d'arrêt d'urgence. Si, en plus on utiise un système numérique permettant l'identification des trains, on voit alors l'identité de la loco sur le mauvais canton.

Il n'y a pas de fonctionnalité plus avancée dans TC actuellement.

Jean

pascal a écrit:

Bonjour à tous
Il est difficile pour RRTC de suivre d'une maniére simple la progression. La méthode existe mais je pense ne pas me tromper si je dis ( les pros arrêter moi si c'est faux) il faut opter pour le systeme qui permet cette fonction qui est à ma connaissance la detection par lecture de code barre coller sous la loco par exemple , ou je crois savoir que certain systeme type Selectrix peuvent le faire mais là je ne suis pas sur du tout pour ne jamais avoir poussé mes investigations plus loin dans ce dommaine.

Là, on ne parle pas de progression des trains, mais de détection des trains et de leur identification. Au moins deux systèmes le permettent (Digitrax et Selectrix). Quant à la méthode code barre, à ma connaissance, elle n'existe pas. Je pense que tu veux parler du système Lissy d'Uhlenbrock: il ne fonctionne pas par code barre mais par détection infrarouge. C'est une simple détection de passage du train devant un détecteur, mais pas une vraie détection d'occupation.

pascal a écrit:

Pourquoi RRTC ne peut detecter une erreur d'itineraire avec un autre type de detection? Pour la bonne et simple raison que le train reste dans le bloc de l'itinerraire et le quitte lorsqu'il est détecté dans le suivant. Or s'il le train n'est pas detecter dans le suivant pour RRTC( qui ne connait pas la durée de transit dans le BLoc) il est toujours dans le bloc faisant partie de l'itinairaire choisi et ne lui donne pas d'instruction.

Avec un système permettant la détection des trains (voir plus haut), TC pourrait détecter la présence d'un train dans un canton qui ne lui est pas réservé lors d'un trajet et agir en conséquence. Cette fonctionnalité n'existe pas, c'est vrai

pascal a écrit:

Il faudrait donc que RRTC calcul en permanence cette durée de transit qui n'est autre que Longueur du Bloc diviser par vitesse du convoi, et là se pose nombres de questions sur la fiabilité du calcul.

Désolé, mais cela ne couvre qu'un seul cas de figure, celui du pilotage entièrement automatique du réseau.
Si le trajet est effectué manuellement, ce type de calcul ne sert plus à rien du tout, car l'opérateur du train peut décider d'arrêter le train dans n'importe quel canton du trajet.

Alors maintenant, essayons d'être un peu pragmatiques.

Personnellement, cela fait un certain nombre d'années que j'utilise le logiciel et un certain nombre de trajets que je fais effectuer par TC. Je n'ai pas encore eu d'erreur d'aiguillage. Bien sûr, cela implique qu'on vérifie de temps en temps le fonctionnement de son matériel.
Je sais que René a eu des problèmes dûs, si je me souviens bien à l'utilisation de moteurs Peco que certains décodeurs ont du mal à faire bouger.

Demander des développements de type usine à gaz à Freiwald est une chose et le garçon est assez doué pour les faire.

Mais cela a des conséquences: faudra peut être changer le PC qui pilote le réseau. PC qui est souvent un portable pas de première jeunesse et qui risque de ramer avec la version usine à gaz.
Jusqu'où êtes vous d'accord pour payer des développements qui vont peut être vous éviter un accident tous les deux ans sur le réseau?

Je vous laisse la parole, j'ai fait trop long déjà.

Bonnes fêtes de Pâques à tous,

Jean

Bonsoir à tous

Jean lorsque vous dites:

Citation :

"Quant à la méthode code barre, à ma connaissance, elle n'existe pas."

Je suis d'accord je me suis trompé, je parlais de "TRAIN DETECT " de LDT mais qui n'utilise pas de code Barre mais des transpondeurs coller sous la loco sous forme de pastilles.

Pour le reste Jean je suis assez d'accord avec votre constat.

Bon train

Pascal

Bonjour Jean,

Tout d'abord en rappel, vous m'avez très largement aidé ( avec le concours de Yann) à faire mes premiers pas avec RRTC et à convertir un réseau précédemment piloté par DR.
Réseau comportant en autres 79 moteurs d'aiguilles ( ceci pour expliquer ma précédente intervention ).

Un rectificatif s'impose :
J'utilise des décodeurs DS54 , DS 64 de Digitrax et DAC 10 de CML.
Les moteurs sont des PL10 , PL10W de Peco et PM1 de Seep.
Je ne rencontre aucun probleme d'électrotechnique.
Par contre les moteurs Peco ne sont pas fiables mécaniquement parlant et instables dans le temps malgrè le soin à leur implantation mécanique.
Ceci n'est que mon point de vue mais explique encore mon intervention.

Jean,

En réponse à votre pragmatisme, je proposerai une solution simple et efficace:
en votre qualite de Betatester de RRTC veuillez introduire le sujet aupres de Freiwald.
ce "garçon assez doué " saura nous dire :
s'il considère ce développement comme une usine à gaz
si le coût de la modification est onéreux ( une version light est toujours possible ).
si cela nécéssite un changement de configuration et d'en définir les parametres.

Jean,nous nous connaissons suffisemment et je pense que par votre canal nous aurons des éléments de réponse incontestables.

Cordialement

René ( Ex Ing. de maintenance Electronique / CERN Div. Physique Nucléaire )

Jean_01 a écrit:

Demander des développements de type usine à gaz à Freiwald est une chose et le garçon est assez doué pour les faire.

Mais cela a des conséquences: faudra peut être changer le PC qui pilote le réseau. PC qui est souvent un portable pas de première jeunesse et qui risque de ramer avec la version usine à gaz.
Jusqu'où êtes vous d'accord pour payer des développements qui vont peut être vous éviter un accident tous les deux ans sur le réseau?

ça sent l'argumentation "à la Freiwald" traduit en français que j'apprécie tout particulièrement

Pour moi, le contact de rétrosignalisation de la position de l'aiguillage mis à disposition par le SwitchPilot peut être intéressant dans le cas où l'on enclenche et joue avec le réseau sans allumer le PC (pour juste tester une locomotive ce qui se fait souvent au club, par exemple). Si des aiguilles ont été manoeuvrées pendant ce temps, il peut être intéressant que, quand TrainController est démarré, il y ait une interrogation de l'état des contacts de rétro. et actualisation de la positions des aiguilles sur les TCO de TrainController.

RB 83 a écrit:

Qu'indique le decodeur comme retrosignalistion ?

1- que l'odre de modifié la position de l'aiguille a été transmis au moteur d'aiguillage si c'est ce cas on ne peut pas être sur que les aiguilles ont bougé.

2 que les aiguilles de l'aiguillage ont réellement bougé si c'est cette dernière comment fonctionne le mécanisme.

Tout le problème est là, et c'est pour cette raison que jusqu'à présent Freiwald n'a pris aucune mesure particulière pour intégrer la rétrosignalisation de la position des aiguilles à TrainController, je l'avais lu sur le forum officiel.

L'idéal serait d'avoir, comme en vrai, des contacts de contrôle de la position des lames. (cliquer sur la photo pour agrandir)



Ceci est difficilement réalisable sur nos réseaux. J'aurai tendance à utiliser les contacts de fin de course à disposition sur la plus part des moteurs du commerce comme ceux de Lemaco.

En ce qui concerne le repositionnement des aiguillages après une utilisation en manuel du réseau, il suffit de faire une macro qui vient mettre tous les aiguillages dans une position pré-déterminée.
Ca fonctionne très bien et on a un TCO conforme.
Cette macro est utile si on veut "jouer" en manuel.
Sauf erreur de ma part RRTC ne s'occupe pas de la position de l'aiguillage lorsqu'il établit un itinéraire et donc tous les aiguillages de l'itinéraire sont commutés.

JLuc31 a écrit:

il suffit de faire une macro qui vient mettre tous les aiguillages dans une position pré-déterminée.

Ouioui, et c'est la solution que j'applique. Mais c'est une solution qui doit être mis en oeuvre par l'utilisateur, alors qu'avec l'interrogation de la rétro. elle est automatique et intégrée, ce qui est plus confortable.

JLuc31 a écrit:

Sauf erreur de ma part RRTC ne s'occupe pas de la position de l'aiguillage lorsqu'il établit un itinéraire et donc tous les aiguillages de l'itinéraire sont commutés.

Tout à fait.

Bonsoir,

Je lis vos échanges avec beaucoup d'intérêt mais je ne suis pas sûr d'être complètement d'accord avec vous.

S'il y a un système de rétrosignalisation de la position des aiguilles, et que le système numérique permet la remontée au PC, alors dans la configuration des systèmes numériques, la case "Interrogation aiguilles et signaux est cochée". Donc la position des aiguilles est remontée chaque fois que le système procède à l'interrogation.

Par ailleurs, avant de demander des développements, je voudrais être certain que tel qu'il est aujourd'hui, le logiciel ne permet pas de détecter l'erreur de parcours d'un train.

Depuis l'arrivée du multiconditionnement un peu partout, il y a une fonction de TC que tout le monde semble avoir oubliée, à savoir les flagmen ou signaleurs dans la version française.

Est-ce que l'un d'entre vous a essayé d'utiliser cette fonctionnalité? Je suis un peu surbooké en ce moment, mais je me demande si on ne peut pas faire quelque chose en lorgnant de ce côté là.

Ce serait peut être pas mal qu'on y réfléchisse tous ensemble? Qu'en pensez-vous?

Jean

Appelons un chat: un chat
Je suis également ce fil avec intérêt.
J'ai eu des soucis de commutation d'aiguilles dus à un positionnement trop loin du moteur PECO par rapport à l'aiguille. Ayant mis ces moteurs directement sous l'aiguillage , je n'ai plus aucun problème.
En ce qui concerne la piste de Jean, je crois que c'est la seule pour l'instant à explorer.
En effet RRTC mais à disposition un certains nombres d'outils qu'il convient d'explorer avant de demander une évolution. Avant la naissance de ce forum, Jean 01 m'avait dit que l'un des atouts de RRTC était justement de jouer avec les possibilités de RRTC pour contourner un problème.
Le début de ce fil est "le bon choix" ce problème n'a jamais été remonté et pour ma part J'Ai un réseau qui tourne avec RRTC et je me suis posé la question pour un aiguillage un peu mal placé.
Ma solution consistait en un contact plus une condition sur les itinéraires. Ca marche mais si on rajoute trop de vérifications le PC rame, de plus il ne faut pas oublier le mode manuel et le mode automatique. Donc maintenant je fais confiance au matériel. Dans ce cas précis doit on vérifier la bonne position d'un aiguillage ou le bon positionnement d'un train par rapport à l'itinéraire qu'il doit suivre?
Je conseille donc à Capitole d'utiliser ce logiciel puis de revenir car il y a à mon sens d'autres modif à demander car les gouts et les couleurs .... c'est toujours discutable.
Je ne conteste pas que cette possibilité existe avec une centrale mais est ce que RRTC doit reprendre toutes les innovations y compris les plus absurdes ?
Pour moi, la fiabilité du matériel est essentielle et le logiciel est avant tout là pour conduire les trains. Mélanger les deux c'est demander à avoir une usine à gaz qui sur un gros réseau nécessitera un PC puissant.
Ceci n'engage que moi

Jean_01 a écrit:

S'il y a un système de rétrosignalisation de la position des aiguilles, et que le système numérique permet la remontée au PC, alors dans la configuration des systèmes numériques, la case "Interrogation aiguilles et signaux est cochée". Donc la position des aiguilles est remontée chaque fois que le système procède à l'interrogation.

Ouioui, of course, cela fonctionne bien sauf au démarrage lorsqu'il faut synchroniser justement, que se soit avec l'IB ou le MasterControl de Tams...

Bonjour à tous,
Je suis avec attention mais parfois silencieusement ce sujet, d'autant plus que j'en suis l'instigateur.

Permettez moi tout d'abord de tous vous remercier pour vos explications et vos conseils, et plus particulièrement Pascal (Pascine) qui m'a fait une démonstration convaincante et qui m'a prouvé que la rétrosignalisation de la position des aiguilles était intéressante.

Pour répondre à Jean-Luc( en attendant de nous rencontrer, peut être à Tournefeuille), j'essaie d'avoir tous les éléments qui me permettront de ne pas me planter sur mes achats et de pouvoir continuer à développé mon réseau par la suite. Je n'ai nullement l'intention de de demander la moindre modification de TC, car j'avoue ne pas le connaître au 1/10éme par rapport à vous autres utilisateurs expérimentés.
Ma seule grosse interrogation, était de savoir si la rétrosignalisation remontait jusqu'à TC en transitant par l'Ecos.
J. Freiwald que nous avons questionné avec l'aide de Jean_01, nous à confirmé que oui, et je l'en remercie énormément tout comme Jean qui nous a assuré la traduction.

Pourquoi j'insiste sur cette rétrosignalisation

Tout simplement car je suis de l'école ancienne, + de 35 ans d'analogique ne s'oublie pas facilement, et d'autre part je veux continuer à "JOUER" au train, donc TCO externe avec commande des aiguilles par poussoirs et affichage de l'occupation des cantons par leds le tout en parralléle avec TC.


Bon train à tous.

Capitole

Bonjour Jean ( et à tous ),

Pour mes interventions, je suis parti du fait que la fiabilité des moteurs d'aiguilles à 100% ne peut exister d'où une recherche par protection informatique.
Jean, si vous pensez qu'une solution multiconditionnement/flagmen est possible, je suis bien évidemment preneur.
Je reconnais que , actuellement , je ne sais pas mettre en équation toutes les conditions requises.
Quand j'entends parler " usine à gaz ", " PC puissant ", cela ne m'évoque rien.
Par contre si l'on me prouve qu'il me faut une surpuissance de X Mhz par block protége, je suis toujours preneur.
Je suis donc à l'écoute de chacun de vous plus " pointu " que moi-même.

Bon train à tous.

René

On ne peut quantifier X Mhz par bloc,
lorsqu'on met une condition sur un évènement, on crée une boucle de scrutation sur cet évènement . Cette boucle est perpétuelle càd tant que RRTC tourne.
Si on crée des conditions à vérifier sur un grand nombre d'évènement, le PC va devoir en même que la gestion des trains et le rafraîchissement de l'écran scruter le résultat de toutes ces boucles afin de voir si il n'y a pas un état qui change.
Pour faire tout ça sans qu'il y ait une tâche qui soit mise de côté il va falloir un microprocesseur costaud afin qu'il ait la vitesse et la puissance de calcul ad hoc.

JLuc

Attention ma réponse:
c'est du raccourci de chez raccourci mais je pense que ça donne une idée

Jluc

OK JLuc, parfaitement parfait,
Votre réponse est déja techniquement plus parlante ( boucle de scrutation).

Mon réseau dans sa configuration actuelle ( 120 blocks et en prévoyant 12 convois simultanés ) doit déja pédaler à 1Ghz.

Les UC à 1.6Ghx/800 Mhz et 2.4Ghz/1066 Mhz valent entre 400 et 600 €.
A la louche que preconiseriez-vous ?
Si le logiciel, dans sa version actuelle, permet de résoudre mon probleme, l'investissement me parait supportable.

Il est vrai que pendant 15 j'ai évolué au CERN dans un milieu " usine à gaz "

René

Je dirai qui peut le plus peut le moins.
Maintenant reste à savoir ce que le logiciel est capable de faire.
Je ne suis pas informaticien mais par expérience je sais qu'un flot continue d'informations ne se traite pas n'importe comment.
J'ai un petit réseau et je suis parfois surpris des options prises pour gérer un trajet donc pour un grand réseau avec beaucoup de locos ... il faut voir ou tester.
Si le numérique démarre, il est certain que le travail demandé au PC risque de suivre la même courbe que l'évolution de l'informatique.
Cependant le modélisme ferroviaire reste un jeu et je pense qu'on peut laisser une certaine place au hasard ou à l'imprévisible le tout-informatique n'est pas forcément la VOIE.

A part ça je connais bien votre région car j'ai passé 20 ans à Toulon dans La Royale

JLuc

Bonjour, j'ai lu ce fil avec intérêt et je trouve la simplification de JLuc31 très parlante en effet. Les PC récents sont tous maintenant équipés de processeurs multi-coeurs, 2 ou même 4, plutot efficaces pour traiter ces "boucles de scrutation" en parrallèle. Encore faut il que l'architecture de RRTC soit faite pour tirer profit de cette architecture ce qui n'est pas sûr. Peut être J. Freiwald pourrait le dire ?

Pour des aiguilles PECO j’ai peut être une idée pour faire contrôler la position d’une aiguille par RRTC, de telle sorte que si l’aiguille pour une raison mécanique n’est pas orientée correctement, RRTC stoppe le train concerné.

En partant du principe que les aiguilles PECO avec moteurs PL10 et inverseur de polarité PL13 destiné à alimenter les pointes de cœurs, si une aiguille ne peut changer de position pour une raison mécanique, l’inverseur de polarité ne changera pas de position.
Il faudrait donc créer dans un coin quelconque du TCO un canton hors réseau que l’on nommerait « Canton Position d’aiguille », y créer un indicateur d’occupation relié à l’aiguille, suivant croquis ci-dessous.



Le TCO de la bifurcation pour un trajet Canton A - - ->Canton B et un autre trajet Canton A - - ->Canton C.



Si l’aiguille fonctionne correctement, quand le train sera sur le « Canton 1 » on aura :
--Pour l’itinéraire « Canton 1<- - -> Canton 2 », le canton « Canton Position d’aiguille » sera occupé puisque la pointe de cœur sera alimentée par le décodeur d’occupation et quelle sera shunté par un résistance de 10 à 50 Homs (Cette résistance joue le même rôle que celui d’un train pour un détecteur d’occupation)
--Pour l’itinéraire « Canton 1<- - -> Canton 3 », le canton « Canton Position d’aiguille » sera non occupé puisque la pointe de cœur sera alimentée par le commun.
Si l’aiguille ne s’est pas déplacée correctement ce sera l’inverse pour le « Canton Position d’aiguille ».

Il faut dons paramétrer pour le trajet Canton A - - ->Canton B passant par Canton 1 vers Canton 2 :
Dans Canton 1 à L’onglet « Actions » à Entrée : une macro si « Canton Position d’aiguille » non occupé, stopper train.



Paramétrage Canton 1 du trajet Canton A - - ->Canton B



Macro onglet Opération



Macro onglet Condition


Pour le paramétrage du trajet Canton A - - ->Canton C passant par Canton 1 vers Canton 3, c’est la même chose, sauf que dans la macro à l’onglet Condition le « Canton Position d’aiguille » est occupé.


Je suis actuellement en vacance, je n’ai pas pu contrôler ceci sur mon réseau, mais le test logiciel est OK.

J’ai été un peut long, bien sur que si la solution est bonne Jean l’aurait expliqué plus clairement.

A bientôt

Pierrot

Bonjour Jluc ,

" Un ancien toulonnais, le monde est petit ".

Je suis en tous points en accord avec vous : le logiciel est-il capable de le faire?
Vous aviez testé une solution " flagman ".
Pouvez-vous la mettre en ligne ( ou par mail privé si vous préférez).
Je ne vise pas le tout informatique : des parties de mon réseau sont en mode manuel pour jouer au train avec des "walk-around"
Si aucune solution ne se dégage de la part de ce forum, il faudra tôt ou tard prendre contact avec Freiwald (cf JW 28 ).
Il existe une rubrique " Suggestions & Whishes " n'est ce pas Jean.
Je viens de lire la solution de Pierrot, je le contacte de vive voix( et voie ), nous sommes voisins.
A bientôt
René

rene.breuil@live.fr