J'en avais parlé la fois précédente , une nouvelle platine est en passe de voir le jour pour le réseau . Une platine de détection comportant 48 points d'infos .
Logiquement elle est parfaitement inutile de part le concept même de CA Train !
En effet , une rétro-signalisation constante est automatiquement en dialogue entre les modules de puissances PWM et l'ordinateur de gestion .
En d'autres mots , le logiciel scrutte la présence des trains , les alimente en courant là où ils se trouvent , en anticipant les changement de cantons et le cheminement des rames . Donc , il sait , il détecte , en permanence là où se trouvent les rames .
Par contre , si l'ordinateur sait que " tel train est sur tel canton " , il ne sait pas précisément où sur ce canton !
Avec un réseau qui tourne régulièrement , qui reste " propre " , si les paramètres des rames ( vitesse réelle des déplacements , ralentis , etc .. ) sont correctement entrés en amont pas de soucis . Les longueurs de cantons doivent aussi se caler correctement suivant les distances des rails présents sur le réseau ...
Si de petites dérives ( inhérentes et habituelles --> un moteur un peu sale ( rame moins rapide ) , des hics de prises de courant ( idem ) , une rampe mal engagée ( idem ) ) font que les rames ont un peu de retard , pas de soucis non plus : Une temporisation réglable permet de recentrer ces déplacements , de resynchroniser les rames lors des sauts de cantons effectifs par les modèles réduits .
Une fois de plus , tout est histoire de bien entrer les paramétres du réseau et des rames dans le logiciel, et , avec tout ces bons paramètres en mémoire , les évolutions sur le réseau virtuel présent à l'écran doivent toujours être en avance sur les déplacements des miniatures . Votre serviteur gére d'une poigne de fer son réseau alors pas de dérive lors des roulements !! ( ... sauf avec la Loi de Murphy qui forcément sévit ... ) .
En revanche , si une rame est " en avance " ou qu'elle " déborde " de son canton lors d'un arrêt , là , gros soucis !
La rame continuera son chemin et la désyncro. sera actvée aprés un temps ( arrêt total du logiciel ) ... à moins qu'avant cela une catastrophe ferroviaire ne soit arrivé ...
Pour contrer ce probléme les concepteurs ont pensé à la détection complémentaire à endroits précis . En réalité , la détection est prévue pour les très long cantons , afin d'avoir une resynchronisation " en cours de route " , avoir un Bip de contrôle qui aide à mieux savoir où est la rame en cours de voyage sur le long canton pour aider l'ordinateur à ne pas perdre ses convois .
On peut aussi placer des Bips sur les voies de garage ( principalement sur celles cachées ) afin de marquer l'arrivée d'une rame et de freiner celle-ci suffisamment tôt pour un arrêt absolu ( une autre option possible sera de câbler un relais avec le feu de fin de voie et d'alimenter un tronçon en bout de voie de garage via le relais : Le feu est au rouge , le courant sur la fin de voie est coupé --> la rame s'arrête forcément )
J'avais envisagé le montage de la platine pour cette éventualité ( voies de garage cachées ) ; Mais c'est une autre utilisation prévue qui m'a décidé à l'assembler ...
Lors des conceptions d'itinéraires , une possibilité est : " Attente d'un événement extérieur " ; Le marquage de cet événement , doit passer par un point de contrôle , par un Bip --> Un train voyage puis , arrivé à tel endroit , il se met en attente d'une validation précise ( ... numéro de Bip XX ... ) afin de pouvoir repartir .
Les Bip sont donnés par des contacts classiques de style ILS , infra-rouge , ou autres ... C'est là que cela m'intéresse !!
Sans ces Bips les trains peuvent déjà se démarrer les-uns-les-autres sans soucis : Tel train , en arrivant sur tel canton , fait partir tel autre train , situé sur tel autre canton , etc , etc ...
Avec de nombreux trains et les possibilités de temps de pause en sus , on pourra trés vite , bien s'arracher la tête pour organiser de bonnes rotations et des itinéraires se recoupants ...
Mais , le systéme tournant en boucle ( tout les itinéraires sont obligatoirement bouclés ) , lorsque l'on revient au début de cycle cela ne s'arrête jamais et on repart d'office pour un nouveau cycle global ( --> petite lacune du logiciel ) ..... sauf à avoir , en fin de cycle , besoin d'un Bip de validation pour redémarrer !
Comme un contact Bip peut aussi être un bouton poussoir , j'aurai au moins besoin d'un BP pour relancer le cycle général de l'ordi. : Un top départ de début de cycle global .
L'autre utilisation sera , pendant les rotations , d'avoir les trains qui se figent : Tel train N°1 , attend un ordre ; Les autres , qui suivent ( travail des blocs cantons ) ou qui attendent le train N° 1 à tel endroit pour pouvoir se lancer , se retrouvent aussi en attente .
Comme tout est figé , en attente d'un ordre pour la reprise de la suite par la commande du logiciel , je peux basculer en manuel , faire des ( mes ) manoeuvres ( changement de loco en tête de train , formation d'une rame ... ) avant de Bippé un autre bouton qui fera repartir la gestion par l'ordinateur ...
Plusieurs "moments " d'attente pourront ainsi être organisés afin d'effectuer des séquences manuelles au réseau .
La platine comportant 48 points de Bip , ayant 16 voies de garage à pouvoir équiper , il me reste plus de 30 points de Bips libres pour organiser des passages en mode manuel ...
Le plus gros de l'assemblage est fait ; Tombé à court , j'ai dû attendre un arrivage d'une nouvelle série de quartz pour finir mes soudures ( Il m'en manquait 3 ) . Restera ensuite à me " replonger dans la méthode " et à programmer les PICs de gestion de modules , puis enfin à tester l'ensemble ...
Photo : La platine de 48 points de détections en phase d'être terminée ; Sur la droite , les quartz qu'il me manquaient pour finir les trois modules du bas , la rangée de PICs qui doivent être programmés sous peu ....
/fdata%2F3392990%2Favatar-blog-1126903998-tmpphpiQYdpr.jpg){kind=avatar}