Comment anticiper l'automatisation du réseau?

Questions et Réponses
22

Et je retombe dans le brouillard. J’ai du mal à comprendre l’avantage que cela peut procurer. Si j’ai bien bien suivi les explications de @johnjeanb, tout est paramètrable dans Rocrail, quelques points de contacts “discrets”, judicieusement répartis sur le canton devraient donc suffire. Je ne pige pas et cela me semble important de piger ce point ! :grimacing:

Oui, nous sommes d’accord, c’est une méthode "fait maison’ pour se confectionner un rail C de contact à moindre coût. On “charcute” (proprement) le rail.

Cela non plus je ne pige pas. En quoi est-il plus diifficile de “charcuter” un 24130 ou 24230 pour en faire un rail de contact plutôt qu’un 24172/24188/24360 etc. Tu fais peut-être référence à la voie K ?

23

Non je parle bien de voie C, dans le catalogue Märklin il y a 2 références de rail de contact, un droit et une courbe. je me rappel plus de quel rayon il s’agit mais il n y a qu’une référence pour 5 rayons de courbes différents dans le catalogues. Donc selon le rayon de courbures que l’on utilise, le rail de contacts Märklin s y intègre pas super bien.
Dès lors il vaut mieux modifié son 24430 ou 24530 soit même.

Psk johnjeanb ne parle que pour sa paroisse et Rocrail.
Hors comme je l’ai dit dans un message précédents, il vaut mieut regardé les logiciels et leurs nomenclature nécessaire.
itrain ainsi que Train Controller n’ont besoin que d un seul contact faisant l entier du canton pour gérer ce dit canton dans les deux sens.

2 « J'aime »
24

Encore une fois cette affirmation depends du logiciel que l’on emploi.
Itrain et Train Controller n ont besoin que d’un seul contact de la longueur du dit canton pour gérer ce canton de manières bidirectionnel.

Maintenant si c est Rocrail, comme je l ai deja dis précédemment, il faut adapter son setup…

2 « J'aime »
25

On va mettre un coup de frein aux querelles de clocher qui surviennent sur quasimment tous les sujets touchant à la détection de présence.

@Alain2 Le choix du logiciel est donc à intercaler entre le découpage du réseau en cantons et l’installation de l’infrastructure. Rocrail, Itrain, TrainController se tirent la bourre et se valent très probablement dans l’ensemble (et il doit y en a en avoir d’autres, des logiciels!). Mais chacun semble requérir une installation spécifique des rails de contact pour permettre toutes leurs fonctionnalités / subtilités. Après ces échanges, toujours partant pour l’automatisation ? :sweat_smile:

Rocrail repose sur le principe de la contribution volontaire, cad logiciel gratuit mais dons fortement encouragés (ce qui me semble approprié). Les autres sont payants. L’interface de Rocrail est très aride je dois dire. Je vais peut-être regarder Itrain aussi pour me faire une idée…

Il y a une autre question de néophytes à laquelle il est difficile de trouver une réponse concise et claire sur le forum: en termes d’automatisation, que permet le pilotage par ordinateur qu’il n’est pas possible de mettre en application avec une centrale (type Märklin CS3 ou ESU ECOS), aussi sophistiquée soit elle ? J’ai mon idée, mais je n’arriverais pas à l’articuler correctement sans créer davantage de confusion.

1 « J'aime »
26

Du peu que j’en avais lu, je n’avais pas compris que le choix du logiciel avait une influence sur les composants et la structure du réseau.
Merci à toutes et tous pour vos contributions.

Alain

27

J’ajoute quelques fils récents que je trouve tres pertinents a propos du sujet lancé ici meme par Alain.

1 « J'aime »
28

Super. Merci Jérôme. Voilà encore de quoi lire :slightly_smiling_face:

29

Bonjour Jérôme, bonjour à tous,

Sachez qu’il est très facile de créer des automatismes basés sur des évènements ou des timers avec un Arduino.

Si l’on connecte un Arduino à l’une des entrées CAN de la Gleisbox on peut jouer une multitude de scénarii.

Quelques exemples simples :

  • A partir d’un bouton poussoir, activer le sifflet d’une locomotive précise.
  • En plaçant un lecteur RFID sous la voie par exemple à l’entrée d’un tunnel comme j’ai pu le montrer dans un autre fil, on peut identifier différentes locomotives et leur demander alors d’activer leur sifflet, de ralentir à une vitesse donnée et d’allumer les feux. On peut bien sûr commander l’opération inverse à la sortie du tunnel.
  • On pourrait aussi imaginer un ou plusieurs boutons d’urgence répartis autour du réseau.

Avec de timers, on peut demander la répétition de telle ou telle action sur une locomotive. Activer différents bruitages…

Je pense que les limites sont l’ imagination mais aussi la cacophonie pour que tout cela ne devienne pas un cirque.

Christophe

30

Le sujet est vaste et il n’y a pas vraiment de documentation permettant d’avoir une vision complète du sujet sans rentrer dans la technique.

Ce que je peux rajouter par rapport à ce qui a déjà été écrit ci dessus ( outre le fait que andré ( waldame) a déjà bien cadré le sujet ) est que le logiciel qui me paraît le plus performant est Train controller.
Mais il n’a pas que des avantages et est très long à paramétrer
Le concept est le suivant ( basé sur des cantons principe général comme les trains réels)

a) Une fois que tu as déclaré que la loco 8 est dans le canton 12 -disons son point de départ

b) le logiciel calcule en continu la distance que parcourt la loco

c) et il sait donc en permanence ou est la loco

Il le sait car il connaît :

  • la courbe de vitesse de chaque loco que tu auras étalonné dans le logiciel
  • la longueur précise de tous les cantons et des aiguillages que tu auras saisi dans le logiciel
    ( ainsi que plein d’autres choses mais restons simple )

Comme il connait la vitesse et le temps écoulé le logiciel est donc capable de connaître la distance parcourue par la loco et comme il connaît le métrage du réseau le logiciel est donc capable de savoir précisément où est la loco sur le réseau

Dans un monde parfait il aurait même pas besoin de zone de rétrosignalisation

Mais comme le moteur de la loco et son décodeur ne sont pas totalement parfaits la locomotive peut en réel ne pas être exactement là où elle devrait être selon les calculs du logiciel
C’est pourquoi il faut que les cantons soient rétrosignalés ( soit à un point donné soit en 2 ou 3 soit tout le canton ) .

Cela permet à train controller de savoir que la loco 8 qui devait entrer dans le canton 17 vient de rentrer dans le canton 17 ( par ex) et donc de mettre à jour ses calculs afin d’être très précis et d’être plus fiable et de valider cette donnée

Cela permet aussi de paramétrer des actions ( sifflet , son , éclairage) à des endroits précis du réseau sans qu’il y ait besoin de contacts de retrosignalisation . Il suffit par ex de paramètrer dans le logiciel que la locomotive 8 doit émettre un sifflet quand elle passe le cm 223 du canton 14 ou d‘allumer les lampadaires de la gare quand elle entre dans le quai etc…

Ce que veut dire Christophe ( enfin je crois) c’est que le logiciel sait que c’est la loco 8 parce qu’il s’attend à ce que la loco 8 qu’il est en train de piloter rentre dans le canton 17 et que donc s’il y a un contact sur la zone de rétro il va en déduire que c’est la 8

Mais ce n’est pas la loco qui envoie un signal disant „moi je suis la loco 8 et je viens de passer la“ et c’est ce qu’il regrette . ( railcom en 2 rails ) d’autant qu’avec le mfx on pourrait penser que c‘est possible

Train Controller s‘en sort très bien sans et iTrain très bien aussi ( mais moins parametrable à souhait ) .

Autrement dit si toi à la main tu poses une autre loco par ex numéro 9 sur le contact de rétro du canton 17 le logiciel va croire que c’est déjà la loco 8 qui arrive et/ou tout arrêter en te disant qu’il y a un problème
Ce qui n‘est pas faux
Mais si tu changes a la main la loco de place sans le dire au logiciel il y a pb

Alors que Christophe aimerait que le logiciel puisse aller lire le décodeur de cette loco et voir que c’est la 9 ou la 8
Si j’ai bien compris

Voilà j’espère que cela t’aidera à comprendre

Après si tu veux savoir comment retrosignaler il faut te plonger dans la ou les doc des logiciels car ils sont différents ( la doc de Rocrail est bien fichue car elle explique les concepts et pas que le how to do)

Si tu hésites entre rétro par masse ou par consommation de courant il y a un post sur le sujet

Voilà désolé d’être un peu long

1 « J'aime »
31

Cela est aussi ma compréhension - les logiciels “émulent” la position de chaque loco qui est induite par pur calculs théoriques depuis le point d’enregistrement initial de la loco et ces calculs se mettent a jour (se “re-calibrent”) constamment avec les infos de la rétro. Ce n’est pas la meme chose qu’une loco précise déclarant son identité et sa position “au systeme” en remontant son adresse dans chaque canton (via un signal “ping”). Okay, ce dernier systeme type RailCom semble etre le fin du fin du finaud, mais apres, a-t-on réellement besoin d’individualiser des fonctions pour chaque loco séparément…?

Cela permet peut-etre de concevoir des systemes d’automates a la fois précis et sans fioritures, qui s’affranchissent des logiciels du marché? Je suis certain que Christophe (@bobyAndCo) aura une réponse a cette question ! :smile:

1 « J'aime »
32

Bonjour Jérôme, bonjour à tous,

Ce sur quoi je n’ai sans doute pas assez insisté c’est que je ne parlais pas d’Arduino qui viendraient se substituer à d’autres systèmes comme les logiciels de gestions de réseau comme Rocrail ou Train Controler.

Je parlais au contraire de modules Arduino (ou ESP32, Raspberry Pico…) « autonomes » qui s’ajoutent à l’existant. Le bus CAN de Marklin, dont je ne cesse de vanter les mérites à juste titre, a ceci de magique c’est que de nombreux périphériques CAN peuvent envoyer des commandes. Et le protocole prévoit que les autres périphériques sont informés de ces commandes et se synchroniser avec ces informations.

Je vais prendre un exemple simple. Il est possible d’introduire sur les bus CAN plusieurs MS2 par exemple. Chaque MS2 peut prendre la main sur n’importe quelle locomotive et tous les autres périphériques (MS2, CS3, RR, TC…) se synchronisent sur les changements qui sont envoyés sur le bus.

L’exemple de l’Arduino équipé d’un module RFID est certainement à ce jour ce qui offre le plus d’interactivité.

Un tel module placé à l’entrée d’une gare peut permet de jouer des annonces personnalisées, de faire s’arrêter certaines locomotives (autorails) mais pas d’autres. Les faire repartir après une pause de 20, 60, 120 secondes !!! Cela ne perturbe en rien le fonctionnement d’un logiciel comme RR ou TC.

Je parle donc de « déléguer » certaines fonctions à des modules dédiés qui feront sans doute mieux le travail et plus simplement.

Je prends un autre exemple qui fonctionne sur RR (et donc probablement avec TC). On peut poser une locomotive sur le réseau, sur le lecteur RFID, ce qui permet à RR d’identifier immédiatement la locomotive plutôt que d’entrer manuellement l’adresse.

Enfin, j’avais aussi montré tout l’intérêt qu’il peut y avoir à identifier une locomotive à l’entrée et à la sortie d’une gare cachée pour déléguer à un Arduino la gestion de cette gare, la commutation des aiguilles, la gestion de l’occupation des voies, la signalisation au besoin.

Toi seul a la réponse à ta question car le besoin sera ressenti différemment d’un modéliste à l’autre. En générale, plus on a compris comment ça fonctionne et que c’est finalement assez simple, plus l’accessoire devient un besoin !

L’identification de l’adresse de la locomotive, c’est le Graal pour qui souhaite maitriser totalement son réseau et en particulier la sécurité.

Juste un petit mot sur l’identification en MFX. J’ai présenté dans un autre fil un schéma électronique dont j’ai bon espoir qu’il permette la lecture des informations retour des décodeurs. Je connais le protocole, il me faut le signal. J’ai commandé hier tous les composants nécessaires et je pense avoir traité ce point d’ici la fin d’année.

Christophe

4 « J'aime »
33

Merci pour ta réponse complete Christophe, je me permets de joindre le lien vers tes recherches dans ce domaine, pour ceux qui veulent en savoir plus:

1 « J'aime »
34

Merci d’avoir pris le temps d’expliquer clairement le principe général, Francis.

35

Très intéressant. Impatient de voir la suite. Merci pour le partage.

Alain