par jpp38 » 17 Septembre 2012, 09:53
Bonjour,
Je vois que je ne me suis pas fait comprendre.
Ce n'est pas que je ne veux pas, c'est que je ne peux pas parce que c'est impossible. Et c'est impossible avec tout logiciel, RRTC, Windigipet, iTrain, RocRail, ....
Il s'agit d'un problème de fond, de principe.
Si vous envoyez une commande depuis un TCO, cet ordre est directement transmis à la centrale, qui l'exécute immédiatement, que ça plaise ou non au logiciel. Or si on attend du logiciel qu'il gère la sécurité, ça veut dire qu'à certain moments, il doit interdire la manoeuvre d'aiguille, si un train est dessus, par exemple. Donc, à partir du moment où on accède directement à la centrale, le mal est fait, même si le logiciel (qui voit la consigne de changement d'aiguille) envoit l'ordre inverse, pour rectifier, ça peut être trop tard, si un train était dessus.
Donc la seule solution est d'envoyer d'abord la requête au logiciel, et que ce soit lui qui gère cette demande.
Alors on pourrait imaginer un système de TCO où, au lieu de faire changer d'état une aiguille, on envoit une requête de changement d'état. Et les LEDs d'état indiqueraient aussi si une requête est en cours. Mais pour ça, il faudrait une interface particulière avec, dans le cas d'Xpressnet, 3 connecteurs:
un bus Xpressnet qui va vers le ou les TCO,
l'autre bus qui va vers la centrale,
et la troisième "sortie" vers le PC et le logiciel.
Et c'est le logiciel qui jouerait le rôle de centrale vis-à-vis du ou des TCOs.
Je vais plus loin. A partir du moment où on veut bénéficier de la sécurité du logiciel, ce qu'on veut faire en général , ce n'est pas de changer l'état d'une aiguille, mais de dire à un train de se rendre d'un point à un autre, ce qui implique en général de changer l'état de plusieurs aiguilles.
Du point de vue du fonctionnement interne, si on envoie les requêtes de changement d'état isolément, on risque d'arriver à des situations de blocage sur les réservations (deadlock). Alors que si on envoie les demandes de changement d'état en groupe, de façon cohérente, ça se passe bien.
Autrement dit le problème est très compliqué. Et il est très important car ça rejoint le problème classique "qu'est-ce qu'on peut faire pour empêcher le PC et logiciel de jouer tout seul au train", qui est le souci de la majorité des modélistes ferroviaires, et qui fait que beaucoup renoncent au pilotage par ordi.
Entendons-nous: je reste très ouvert à la discussion, et s'il y a quelque chose qui m'échappe, merci de me l'indiquer. Mais je me bats avec ce problème d'interaction entre contrôle manuel et automatisme du logiciel depuis plusieurs années, et c'est de loin le plus gros problème du pilotage par ordi.
J'ai fait des essais avec Robert sur RRTC qui est manifestement aussi passé par ces étapes. Nos essais ne portaient que sur la commande de vitesse, qui bien que complexe, est plutôt plus simple que la commande d'aiguilles.
RRTC a une foultitude de modes d'interaction différents, dont certains sont buggés, preuve qu'il ne maîtrise pas encore la question à fond.
JP
une astuce toute bête pour que les boutons d'un TCO puissent
