Compatibilité de mon projet de réseau

[Jean-Claude74]

Bonjour à tous

Tout d’abord, je précise mon projet de réseau.

C’est un réseau à l’échelle HO en cours de construction, situé dans les combles de la maison (13m x 5m) de type tour de pièce; il comprend:
    • Une gare terminus
    • Une gare de passage avec embranchement d’une voie unique
    • Deux autres petites gares de passage sur la voie unique
Le réseau est constitué de voies doubles et voies uniques suivant les liaisons entre gares et une voie de retournement.
Nombre de cantons: environ 30
Nombre d'appareils de voie: environ 62 (aiguillages doubles et triples, TJD, TJS)

Passons à la partie exploitation avec les objectifs suivants :
Fonctionnement en simultané des trains en automatique et en manuel en toute sécurité.
Plusieurs trains roulent en automatique sur des itinéraires préprogrammés pendant qu’un ou deux autres convois roulent en manuel sous le contrôle d’un ou deux conducteurs.
Lorsqu’un canton est libéré, celui-ci devient disponible pour être inséré automatiquement dans un autre itinéraire préprogrammé.
Permettre le suivi des convois de cantons en cantons avec espacement des trains, arrêt en gare, boucle de retournement. Il peut y avoir plusieurs cantons qui se suivent entre deeux appareils de voies (aiguillages)

J'avais prévu de poursuivre dans cette voie en investissant plus tard dans un logiciel chef d'orchestre: RailRoad TrainController à plusieurs centaines d'euros !!! J'attendais que mon réseau soit terminé pour avoir la dernière version.

Au niveau des cantons, il y a généralement une zone de pleine voie, une zone de ralentissement et une zone d'arrêt (doublé sur voie unique). RRTC permet gérer la circulation des trains sans coupures des rails à l’intérieur des cantons (zônes de ralentissement et zônes d’arrêt). Cela permet de conserver l'éclairage des feux de la loco et la sono.

C’est ainsi que j’ai commencé à construire mon réseau : les seules coupures se trouvent aux extrémités des cantons en pleine voie et aux extrémités des aiguillages.

Mes questions sont les suivantes :
Est ce que certains projets de gestions de réseaux présentés sur le site répondent à la problématique des cantons sans coupures à l’intérieur (zône de ralentissement et zône d’arrêt) ?
Comment est traitée la voie de retournement avec Locoduino ?

J’ai essayé de chercher les réponses à ces 2 questions mais je n’ai rien trouvé jusqu’à présent dans les projets.

Quelles sont les différences entre les projets suivants :
« Comment piloter trains et accessoires en DCC avec un Arduino » développé par Dominique
« SGDD : Système de Gestion DD » développé par Denis
« Un gestionnaire en C++ pour votre réseau » développé par Pierre59
Quel est celui qui se rapproche le plus de mon projet.

Excusez mes questions de candide mais je suis complètement néophyte dans cette partie.

Merci pour vos réponses
Bonne soirée à tous
Jean-Claude

[Dominique]

Bonjour Jean-Claude,

Je vous remercie de vous intéresser à Locoduino et je comprends bien globalement votre projet.

Tout d’abord Locoduino ne cherche pas la concurrence des solutions commerciales comme RRTC ou les centrales du commerce. Mais vous trouverez parfois quelques compléments utiles, notamment dans les capteurs.

Locoduino se positionne complètement sur le DIY c’est à dire ce qui peut être réalisé par soi-même donc avec un fer à souder et de la programmation. C'est une base documentaire sur de multiples expériences de Locoduinistes mais pas une solution universelle. Chacun adapte ce qu'il trouve à son projet. Le votre est ambitieux mais faisable étant donné que le mien est similaire dans son but mais plus modeste.

Pour info, je décris mon réseau ici https://forum.locoduino.org/index.php?topic=290.0 et il n'est pas fini (il n'y a jamais de fin).

Locoduino concerne, en DCC, des centrales simples et peu onéreuses avec DCCpp le plus souvent (ou DCC++ qui en est à l’origine).
L'article

« Comment piloter trains et accessoires en DCC avec un Arduino » écrit par Dominique

est obsolète car la bibliothèque CmdrArduino l'est aussi.
Il faut s'orienter plutôt vers les articles:
https://www.locoduino.org/spip.php?article253
https://www.locoduino.org/spip.php?article304
https://www.locoduino.org/spip.php?article182
et de nombreuses questions et projets traités sur le forum.

Locoduino concerne aussi toutes sortes de capteurs de retrosignalisation qui remontent les événements au gestionnaire de réseau comme JMRI, RocRail ou des solutions personnelles, qui sont conformes au protocole DCC++, mais pas RRTC en tout cas qui ne l’est pas. Ii y quand même quelques articles sur la remontée de rétro à RRTC en S88.

Concernant les projets que vous citez :

« Comment piloter trains et accessoires en DCC avec un Arduino » développé par Dominique
« SGDD : Système de Gestion DD » développé par Denis
« Un gestionnaire en C++ pour votre réseau » développé par Pierre59

- le premier est obsolete.
- SGDD est resté à l'état de projet non matérialisé mais son auteur vous en dira plus, je l'espère.
- le 3ème est une boite à outil d'objets C++ qui est destinée à réaliser un gestionnaire dans un Arduino (pas dans un Mac ou PC). Mais l'auteur a développé aussi en Java donc pour d'autres plateformes. Je l'invite à faire une réponse plus détaillée. C'est ce que j'utilise actuellement dans mon réseau, dans une architecture distribuée autour d'un bus Can et il existe sans doute d'autres réalisations.

Mais dans ce dernier cas, vous n'avez plus besoin de RRTC !

Au plaisir d'échanger.
Cordialement
Dominique

[Dominique]

En ce qui concerne la boucle de retournement, il y a sans doute des contributions dans le forum : utilisez la recherche.

A+

[Pierre59]

Bonjour

Passons à la partie exploitation avec les objectifs suivants :
Fonctionnement en simultané des trains en automatique et en manuel en toute sécurité.
Plusieurs trains roulent en automatique sur des itinéraires préprogrammés pendant qu’un ou deux autres convois roulent en manuel sous le contrôle d’un ou deux conducteurs.
Lorsqu’un canton est libéré, celui-ci devient disponible pour être inséré automatiquement dans un autre itinéraire préprogrammé.
Permettre le suivi des convois de cantons en cantons avec espacement des trains, arrêt en gare, boucle de retournement. Il peut y avoir plusieurs cantons qui se suivent entre deux appareils de voies (aiguillages)

La boite à outils en C++ permet de fait tout cela. Nous avons présenté, il y a quelques années, à une expo à Orléans un mini réseau (Locoduinodrome) montrant tout cela. J'utilise aussi cette boite à outils pour mon réseau, mais dans une version Java.

La mise en oeuvre de cette boite à outils nécessite des connaissances en informatique (programmation objet) voire en électronique pour l'interface avec le réseau.

Mes questions sont les suivantes :
Est ce que certains projets de gestions de réseaux présentés sur le site répondent à la problématique des cantons sans coupures à l’intérieur (zône de ralentissement et zône d’arrêt) ?
Comment est traitée la voie de retournement avec Locoduino ?

Oui on sait gérer des cantons sans coupures, en étalonnant les vitesses des engins moteurs. On arrive à arrêter les trains automatiquement au pied des signaux. (avec éventuellement une petite détection ponctuelle des trains).
On peut aussi gérer automatiquement les boucles de retournement.
Plus généralement tout est possible en améliorant la boite à outils.

Indépendamment des choix que vous ferez pour la gestion du réseau, il faut soigner la pose de la voie et son alimentation, les gestionnaires sont généralement basés sur l'occupation/libération des zones et des cantons et les micros coupures peuvent êtres très perturbantes. Accessoirement le bon découpage en zones pour être crucial par la suite.

N'hésitez pas à poser des questions.

Cordialement

Pierre Lecouffe

[Dominique]

Pierre a raison, je n'ai installé qu'un seul détecteur par zone (sans zone d'arrêt sauf dans les gares) et le gestionnaire gère les ralentissements.

Petit à petit j'ai découvert quelques défauts de position des détecteurs, mais c'est gérable par logiciel.
De même pour les micro coupures car l'état du réseau est maintenu en permanence et la perte de présence électrique n'est pas enregistrée dans les états d'occupation pour le suivi des trains. On peut faire comme on veut par logiciel.

[msport]

Bonjour,

Comme dit Dominique, un projet n'est jamais fini, vous aurez certainement plusieurs étapes en fonction de vos découvertes.

je retiens de votre question "je suis complètement néophyte dans cette partie."

La première chose  à faire est de vous familiariser avec les solutions possibles en notant qu'il n'y a pas de solutions toutes faites en DIY.
On peut lire la série d'article Ma première ... qui présente les gestionnaires gratuits. https://www.locoduino.org/spip.php?article304

Par ailleurs, attention à ne pas être trop ambitieux et à ne pas se décourager. Une lecture de https://www.locoduino.org/spip.php?article233 peut être utile.

Et donc bon courage.

[DDEFF]

Bonjour Jean-Claude,

Il n'existe pas de système tout fait qui, d'un coup de baguette magique, réalise la gestion d'un réseau surtout un comme le tien (qui a l'air immense).

Le système de Pierre59 donne une boîte à outils qui permet, moyennant de mettre un peu les "mains dans le cambouis", de réaliser tout ce que l'on veut.
Il a été testé en grandeur réelle par quelques locoduinautes en donnant parfaite satisfaction.
L'avantage est que, en le faisant, on a du "sur mesure" et on peut aller aussi loin dans le détail que l'on veut.
Tous les cas sont gérables, avec un parfait respect des règles SNCF.
C'est, actuellement, la seule solution complètement utilisable sur Locoduino qui puisse gérer ce niveau de détail.

Mon système (chercher "modélisation logicielle d'un réseau") avait un autre but : tester la faisabilité d'une solution basée entièrement sur le dessin du TCO.
On dessine le TCO, on répond à quelques questions sur la définition des zones, et cela génère automatiquement un système de gestion (c'est très (trop ?  ) ambitieux)
Les connaissances SNCF nécessaires sont minimes, on ne donne pas de nom aux aiguilles, on ne donne pas de nom aux signaux, on ne décrit aucun itinéraire et "ça se débrouille".

Mais, pour l'instant, il n'existe aucune interface qui permettrait de vraiment commander un réseau. J'en suis resté aux trains virtuels.
En plus, le dessin du réseau est "taillé à coup de serpe", avec des angles de 45° pour les aiguilles.

Je suis reparti pour la partie dessin qui sera le reflet exact du réseau (1pixel = 1 mm, angles précis au 1/10 de degré) et c'est presque fini.
Il faudra réécrire la partie gestion (mais j'ai le fil conducteur de la version présentée dans Locoduino)
Et faire l'interface CAN nécessaire.

Remarque : Il ne faudrait pas croire que RRTC soit une solution toute faite, malgré son prix.
Là aussi, il faut mettre les "mains dans le cambouis", du fait que les possibilité sont extrêmement développées.
Sans compter toutes les interfaces réseau nécessaires en DCC...

Denis

[Jean-Claude74]

Tout d’abord merci Dominique, Pierre, Denis et Msport pour avoir eu la patience de me lire et la gentillesse de répondre à mes interrogations.

Je désirais avoir une confirmation pour éviter d’utiliser RRTC pour la gestion du réseau et principalement de ne pas couper les rails à l’intérieur des cantons (zone ralentissement et zone d’arrêt) C’était ma principale réserve ; car pour le reste, après lecture des quelques projets développés par Domique, Pierre et Denis que j’ai cités, j’étais convaincu qu’on pouvais gérer un réseau avec Locoduino aussi bien ou presque qu’avec RRTC. Deux avantages à cela :

- Ne pas acheter un logiciel onéreux et fermé et comme le dit Denis ne répondant pas forcément à mon projet sous une solution toute faite.

- Avoir le plaisir de « faire soi-même » et de comprendre (ou essayer de comprendre « lol ») ce que l’on crée.
Et cela correspond bien à ma philosophie puisque je fabrique moi-même mon matériel roulant:wagons, locos (à l’actif : 240P, actuellement en cours de finition 141P et locotracteur Y7400) en laiton photogravé échelle HO. Dessin des pièces en DAO (logiciel NanoCad) , typons pour la gravure, flashage des plaques, photogravure dans une machine de ma conception par aspersion de persulfate de sodium. Pour d’autres pièces, j’ai un mini tour et une mini fraiseuse d’établi et bien sûr tout un équipement de soudage (parlons plutôt brasage) : fer à souder, mini chalumeau, poste SRE de soudure par résistance électrique. Tout ce « verbiage » pour vous dire que je suis un fervent du »faire soi-même »

Mais je n’ai jamais abordé ce domaine de la gestion des trains sur réseau et je ne me rends pas compte de l’effort que je devrai faire pour y arriver. Et vous m’avez tous aidé à m’orienter vers une piste à suivre parmi les 3 projets que j’avais mentionnés. Je vais quand même lire votre projet, Dominique, même s’il est périmé et le votre, Denis, même s’il n’est pas prévu pour piloter physiquement un réseau, mais je trouverai certainement des enseignements inintéressants pour moi.

Et bien entendu, sur vos conseils, je me plongerai complètement dans l’étude du projet de Pierre avec certainement comme corollaire beaucoup de questions à vous soumettre.

Merci encore pour vos contributions qui m’ont éclaircies de manière incroyable le brouillard dans lequel j’étais.

Bien amicalement
Jean-Claude

[Dominique]

  Je vais quand même lire votre projet, Dominique, même s’il est périmé

Juste une prévision: ce qui est périmé c’est la bibliothèque CmdrArduino utilisée dans l’article « Comment piloter trains et accessoires en DCC avec un Arduino ».
Cet article est conservé en ligne car il décrit les notions de base du protocole DCC.

Maintenant la technique DCC++ puis la bibliothèque DCCpp fonctionnent parfaitement et sont utilisées dans tous les projets, y compris le mien dans la centrale de mon réseau ici reseau Dominique - partie centrale.

Et la partie gestionnaire se trouve ici vers la fin : réalisation du gestionnaire