Bonjour à tous,
Je découvre ce post, et je vais essayer de répondre aux questions posées concernant iTrain.
D’abord, Michel, je trouve superbe la représentation de ton TCO, c’est clair et nette. (Clarinette, comme on disait à l’armée.) En phase exploitation, cette disposition alignée des cantons et des accessoires, facilitera grandement la lisibilité sans avoir à parcourir des yeux un trajet pour savoir à quel canton est associé un signal ou un contact. Certes comme te l’as fait remarqué Jean Paul, que je salue au passage, il manque les flèches de direction, (rien de grave, juste un icone à rajouter dans les cantons).
Motoriser donc digitaliser les aiguillages. Pour les cantons à sens unique, seuls les aiguillages abordés par le talon doivent être motorisés, car ils peuvent conduire un train dans deux directions différentes (droit ou dévié). Par contre s’il est exact, qu’il y aura toujours possibilité de motoriser un aiguillage pas la suite si l’on envisage de passer un canton en double sens, cela implique qu’il faudra intervenir sur la structure du réseau en démontant cet aiguillage, est ce toujours possible ? À bien réfléchir à la création du réseau.
Les versions iTrain : Actuellement nous sommes à la version 3, qui outre la prise en charges de nouvelles centrales, à nettement amélioré les parcours automatiques. Qui s’ajoutent aux itinéraires programmés. Ces parcours automatiques sont laissés à l’appréciation du logiciel qui saisie toutes les opportunités offertes (on n’est loin des trajets convenus). On peut, si on le souhaite, dicter des règles de conduite, en classifiant ses trains par type, et donc d’autoriser ou non certains trains ou type de trains d’emprunter certains cantons, par exemple éviter à un TGV de se balader dans une gare de marchandises, ou à un train de marchandises d’emprunter les voies de parade d’une gare d’une grande gare.
La version pro est notamment indispensable si l’on désire des contrats de rétrosignalisation directement branchés sur l’ordi, elle permet, entre autre, d’associer plusieurs centrales, de fonctionner en réseau (plusieurs postes branchés sur un même réseau), de dédier le TCO sur un écran séparé etc.
Signaux : nous avons remarqué avec Gilles, que le fait de mettre des signaux (absents sur le réseau mais présents sur le TCO), améliorait le fonctionnement du logiciel, donc pas de ‘modération’.
Contacts : ils sont les yeux du système, un train n’est repéré sur le TCO que dans la mesure où un contact à été actionné. l’éternelle question un ou deux contacts par canton. Personnellement je préconise deux contacts, le premier pour ralentir le train le second pour l’arrêter. On peut obtenir le ralentissement et l’arrêt d’un train avec un seul contact, mais il faut bien savoir que dés que le contact est sollicité, le ralentissement est effectif, par la suite c’est par un calcul fait par le logiciel, qui compte tenu des caractéristique de la loco, déterminera le temps nécessaire pour parcourir la distance différée indiquée. Le temps écoulé, l’arrêt sera envoyé à la loco, mais rien ne dit que la loco est effectivement au point désiré, il se peut que, par un dysfonctionnement quelconque, cette loco se soit arrêtée en court de route. Et ça le logiciel ne peut pas le savoir.
La multiplication des cantons permet une plus grande fluidité du trafic, par contre il faut faire attention, et dans ton cas, pour qu’un train soit autorisé à quitter st Vincent d’en haut pour aller sur abbesses, il faut impérativement que l’une des quatre voies de garages en suivant, soit libres ou alors permettre au train en arrêt aux abbesses de changer de direction, sinon tu arriveras à une situation de blocage. De ce fait, le canton intermédiaire entre st Vincent et les abbesses, n’est peut être pas justifié
Voilà pour un premier jet,
Amicalement
Yannick