Informatiser sa maquette, réflexion générale

Bonjour,
une connaissance a récemment publié une vidéo ou tout les éléments de la digitalisation sont abordé, jusqu’à l’utilisation des divers logiciels:

  • Commande d’aiguillages et accessoires.
  • Rétro-signalisation, matériel employé et mise en oeuvre.
  • interface avec la centrale et l’ordinateur.
  • Organisation du câblage, et des différents modules.

c’est peu être un peu long pour certains, mais c’est assez complet. Aillant moi même fait ce cheminement pour ma maquette personnel, je pense que ça aidera bien du monde.

5 « J'aime »

Merci a Julie d’avoir partagé ce fil récemment.

@Alain2 Je crois que cette vidéo t’intéressera autant que moi :wink:

1 « J'aime »

Effectivement, merci pour le partage.

Merci beaucoup c‘est toujours intéressant :+1:
Une question toutefois :
d’après le sommaire c’est vu du point de vue RRTC

ou je me trompe ?

Car si les principes sont globalement les mêmes ( cantons , retrosignalisation ) les logiques des logiciels et le parametrage sont en pratique très différents .

Je veux dire par là qu‘un utilisateur de TC ne pourra pas aider à résoudre les problèmes d’un utilisateur de Rocrail

Ce n’est pas une critique juste une précision

Bonjour Francis,

J’interprète cette vidéo comme un tour d’horizon assez complet des considérations importantes à méditer avant de se lancer. Le niveau de détail fourni par l’auteur est bien pensé, je n’ai pas décroché une seconde (même s’il est vrai que je m’interesse particulièrement au sujet en ce moment).

Je pense que la plupart des principes évoqués pour RRTC restent valides avec d’autres logiciels de gestion mais tu as raison, ce n’est pas une vidéo sur l’exploration des fonctionnalités avancées/de la paramétrisation de chaque logiciel (il faudrait une journée entière voire plus rien que pour RRTC :grinning:).

Je regrette simplement de ne pas avoir vu cette intro détaillée avant, cela m’aurait fait gagner pas mal de temps en recherches chronophages ! Ce sujet complexe est malheureusement très éparpillé, fractionné, sur le forum.

Sur sa chaine, l’auteur couvre pas mal de sujets sur la programmation des décodeurs ESU pour ceux que cela intéresse…en ce qui me concerne, sa chaine est désormais dans “mes favoris” :grin:

2 « J'aime »

Ok merci
d’accord avec toi

Un complément d’info pour ceux qui hésitent entre tel ou tel logiciel :

a) Contrairement à ce que dit la vidéo on peut tester iTrain gratuitement pendant 2 mois full time
Plus commode que TC ( train Controller)

b) Train Controller peut faire plus ou beaucoup plus que iTrain mais au prix d‘un investissement en temps très important

c) TC et Rocrail sont appréciés des informaticiens ou de personnes à l‘aise avec cette matière , leur interface utilisateur est moins „user friendly,
iTrain est plus convivial et plus facile d’accès

Aucun n‘est le meilleur tout dépend quel critères on privilégie

J‘ajoute que la vidéo peut faire peur en insistant sur le besoin de tout séparer sur un grand réseau
Oui pour un très grand réseau de club mais plus rarement pour un réseau chez soi
Avoir des circuits séparés ( même si une seule alimentation ) pour le courant de la voie est par contre recommandé ( permet detrouve dans quelle partie du réseau il y a un pb)
On peut aussi avoir une alimentation spécifique pour les décodeurs des accessoires

Je confirme j‘aurai été plus vite si j‘avais eu l‘occasion de voir cette vidéo il y a quelques années :+1: je découvre ce post d‘André de 2020 …seulement maintenant :slightly_frowning_face::pray:

1 « J'aime »

C’est tout à fait vrai !
Le principe de fonctionnement de beaucoup de logiciels se ressemble - ce qui change, c’est l’implantation ou non de certaines fonctionnalités particulières, et si telle ou telle centrale est “supportée” ou pas.
Effectivement, et sur ce point Francis a raison, RocRail a fait un choix fondamental différent des autres, qui fait que sur tout ce qui touche à ce choix, il faut penser autrement.
J’y viens tout de suite, je voudrais juste avertir : le tableau de comparaison à la minute 9:00 et suivants du film est obsolète… les trois logiciels ont beaucoup évolué depuis, pour la mention Open Source j’ai un doute si en 2020 elle était encore valable, et les tarifs… hum. D’ailleurs, Rocrail n’a jamais évolué “en fonction de dons” mais en fonction des demandes des usagers et de la possibilité, parfois croisée à la bonne volonté, de les réaliser. Et sauf erreur de ma part, Rocrail est utilisé par Miniworld Lyon… depuis 2015 ? Fabrice était encore parmi nous.

Bon, je reviens à la différence profonde de Rocrail avec les autres.
Dans la minute 11:15 à peu près et la suite, il y a le beau graphisme avec les zones de ralentissement et zones d’arrêt. Deux contacts de rétrosignalisation (RS).
C’est, en principe, ce qu’utilise Rocrail, avec éventuellement un contact au milieu qui permet de mieux gérer les courbes de ralentissement. On se base alors sur les réglages du décodeur.
Rocrail ne demande pas une détection continue, deux contacts ILS ou Hall font l’affaire - et dans le cas d’une utilisation du canton dans les deux sens, les contacts peuvent remplir des fonctions différentes en fonction du sens de passage. Rocrail indique alors (je simplifie) “va à vitesse de ligne”, “va à vitesse réduite”, “va à vitesse minimale”, “arrêt”. D’autres indications plus fines restent possibles, mais ça marche déjà bien avec ces quatre références, qu’il faut évidemment enregistrer pour chaque locomotive.
RRTC et autres agissent directement sur la vitesse et calculent par leurs propres moyens la vitesse et la courbe de décélération mais aussi d’accélération. Le logiciel doit donc connaître la vitesse roulée à chaque cran digital, et le décodeur ne doit pas - c’est souligné dans la vidéo - interférer dans ce processus par une gestion interne des courbes d’accélération et freinage !
L’avantage TC et compagnie est qu’on peut alors faire avec un seul contact par canton, si la longueur du train et le porte-à-faux de la loco par rapport au premier essieu détecté sont connus. L’inconvénient est, si on fait abstraction du temps nécessaire pour chaque locomotive afin que le logiciel mesure la vitesse réelle à chaque cran de vitesse dans les deux sens, le nombre de calculs nécessaires - qui demandent un ordinateur performant - et de commandes passées à la centrale et par la centrale vers le réseau. Selon l’interface de la centrale, mais aussi les protocoles utilisés, on peut arriver à saturation ! Et on a besoin d’un ordinateur beaucoup plus performant, où Rocrail peut se contenter d’un RasPi.
Du fait de ces philosophies différentes, il faut prévoir différemment les dispositifs de signalisation de présence.

Gardant ce choix de base en tête, on peut largement profiter de cette vidéo même si certains détails d’information ont été dépassés par l’évolution des logiciels et des différents modules et appareils - le principe reste valable, et c’est le but de la vidéo de faire comprendre le principe.

:+1: :+1: :+1:

1 « J'aime »