Forum Train

BR212 a écrit:Si avec un seul capteur c'est possible, tout est dans la configuration du bloc concerné au niveau de l'onglet "Itinéraire" de la fenêtre de configuration des blocs.

Donc pour un seul et unique capteur il faut sélectionner le capteur responsable du bloc et ensuite dans la colonne "Evènement" lui donner la fonction "Enter2in".
De cette façon la capteur générera le signal d'entrée (Enter) dans le bloc et ensuite que le train est bien dans le bloc (in) quelque soit le sens de circulation( coté + ou -).
Pour plus de liberté, il est possible via les cartouches "temporisation d'événement1" et 2 de faire varié l'espace temps entre les évènements " in" et" enter" afin d'affiné les réglages et donc les arrêts.

Par contre, il y a une fonction intéressante dans BTT qui est l'arrêt sur l'événement "In" pour des trains courts sur des itinéraires de manœuvre, ce que j'ai pour mes EP et une voie de garage.

Dans RocRail tout est possible si l'on prend le temps de comprendre et de faire des essais (comme RRTC d'ailleurs).

J'ai essayé le "enter2in" sur le réseau du club avec un copain "fana" de Rocrail : la loco s'arrête dès qu'elle est détectée à l'entrée du bloc, le reste du train sur le bloc en amont. Avec un delai entre le "enter" et le "in", ça marchotte pour une loco à une vitesse particulière. Des que la loco arrive avec une vitesse différente, soit elle dépasse le bloc, soit elle s'arrête trop tôt. Si on change la loco: idem. on n'a pas trouvé de début de solution.
Notre conclusion est que aucun réglage de délai ne permet un arrêt correct si on considère une circulation variée et variable.

Après, j'ai essayé sur mon petit réseau HOe, qui possède 3 voies en gare (de longueur a peu près egale) et 2 voies en coulisses. A condition que les locos roulent avec une vitesse assez faible (c'est parfait pour du HOe) et après réglage de l'inertie au freinage, ça marche à peu près bien. Mais c'est un cas très particulier que je ne saurai absolument pas appliquer à un reseau HO plus grand et varié (longueur des blocs variable) avec beaucoup de locos différentes...

J'avais essayé le bbt par loco (en HOe), sans succès. La meilleure solution étant un réglage de l'inertie au freinage du décodeur.

Je crois que je vais en rester là.......

BR212 a écrit:Je crois que je vais en rester là.......

+1

Nonodudu76 a écrit:

BR212 a écrit:Je crois que je vais en rester là.......

+1

Moi, ça fait déjà un certain temps, mais il faut quand même admettre qu'après avoir cassé sa tirelire il est difficile d'admettre qu'un logiciel gratuit puisse faire aussi bien, voire mieux.
Jean-Paul

PaulXpress a écrit:Moi, ça fait déjà un certain temps, mais il faut quand même admettre qu'après avoir cassé sa tirelire il est difficile d'admettre qu'un logiciel gratuit puisse faire aussi bien, voire mieux.
Jean-Paul

C'était aussi mon idée......

Francis

N'ayant pas de réseau personnel, a part un tout petit réseau HOe, je n'ai acheté aucun logiciel !
Mais je profite des versions de démo de TC et iTrain pour les tester, tout comme j'ai testé RR.
Rocrail a beaucoup d'avantages par rapport à TC, notamment d'être plus simple à utiliser une fois que tout est paramétré, mais il est faux de dire qu'il fait aussi bien que TC ou iTrain avec 1 seul capteur par block.
Chaque logiciel a ses défauts et ses avantages et je ne voit pas où est le problème a essayer d'être factuel.
C'est justement parce que je n'ai adopté aucun logiciel que j'essaye d'être objectif.

Bonsoir,
Je prends un peu le train en marche ... si on peut dire.
Deux capteurs pour Rocrail c'est effectivement mieux mais on y arrive avec un seul.
Concernant TrainController, le Suisse Jojo dans ses supers tutos explique très bien la problématique de la rétro. Il précise qu'une seule rétro par canton suffit pour un particulier mais que pour un club trois capteurs par canton sont nécessaires. Chaque modéliste arrive avec sa loco qui n'est jamais bien calibrée et apparemment ça pose problème.
Par ailleurs depuis quelques mois TC nécessite une connexion internet (sauf si ça a encore changé) ; c'est très pratique pour un club
Pour Phil095
J'ai actuellement à disposition une licence Silver V9 de TC sous clef USB et non sous connexion internet. Si ça vous intéresse, je pense que le propriétaire est prêt à la vendre car il ne s'en sert pas (et moi non plus).
PS : il faut toutefois vérifier si elle prend en compte les accessoires étendus, je n'en suis pas certain.

Bonjour Phil,

Comme toi j'ai essayé tout ces logiciels, si je t'accorde qu'avec RocRail c'est un peu plus compliqué que sur les autres, puisque ce n'est pas sa philosophie, mais avec une bonne connaissance du logiciel et certain investissement temps, tu peux arriver au même résultat.

Je vais essayer de t'expliquer le problème que pose l'utilisation d'un seul capteur.
Quand tu utilises cette méthode, tu es obligé de créer des détecteurs virtuels et pour le déclenchement de ceux-ci, tu utilises des boucles de temporisation. Sur le matériel que nous utilisons les systèmes d'exploitation ne sont pas multitâches, mais en temps partagé et la programmation est séquentiel. Ce qui a pour conséquence, que quand tu utilises une boucle de temporisation, celle-ci occupe le processeur à 100%. Donc tout événement qui se produira durant ce temps, sera au mieux retardé, au pire ignoré. Il existe bien des astuces de programmation pour réduire la durée de ces boucles, mais elles ont l'inconvénient de les multiplier.
Si cela ne pose pas trop de problème avec la détection de courant sur un petit réseau, c'est que la détection est constante durant toute l'occupation du canton, donc la détection sera peut-être retardée mais elle sera faite.
Le problème commence à se poser quand tu multiplies les détecteurs virtuels, il y a alors risque de surcharger le processeur et là, le décalage peut commencer à prendre une trop grande importance.
Alors oui, tu peux arrêter un train au centimètre avec cette méthode, jusqu'au jour où ton train dépassera le point d'arrêt et sortira du canton. Comme tu ne pourras pas reproduire le problème, tu mettras ça sur le compte d'un bug. C'est ce qui m'est arrivé avec l'utilisation d'un vieux PC trop lent, alors que je n'avais jamais eu le problème avec un PC plus rapide, c'est ce qui m'a motivé à en chercher la raison.
Je continu donc à affirmer que la détection par consommation de courant n'est pas aussi fiable que la détection de passage.

Jean-Paul

Bonjour ,
Perso j'utilise les deux méthodes de "rétro" (IR pour le passage) sur mon réseau principal,La plus ancienne est en IR et le reste en CC avec RailCOM.

Le coup du PC cela me l'a fait aussi, mais aussi avec un Raspberry et aussi la liaison entre la centrale et le PC via USB ou Ethernet et à chaque configuration des résultats bien différent avec des temps de latence très variables.
Par contre sur mon réseau de test, comme je n'avais plus de détecteur par CC, j'ai fait deux blocs hybride sur des voies de garages avec le capteur à CC en "Enter" et le "in" en IR et il se trouve que c'est fiable avec 0 défaut.

BR212 a écrit:Par contre sur mon réseau de test, comme je n'avais plus de détecteur par CC, j'ai fait deux blocs hybride sur des voies de garages avec le capteur à CC en "Enter" et le "in" en IR et il se trouve que c'est fiable avec 0 défaut.

C'est normal, puisque dans ce cas tu n'utilises pas de détecteur virtuel.
Jean-Paul