Messages récents

1

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« Dernier message par trimarco232 le Aujourd'hui à 07:08:45 pm »

Bonjour,
subordonner , dans ce cas , la libération de la tjd. à celle de l'aiguille du bas ...
ou ne pas faire de transit souple , c'est pas indispensable en MF ...

2

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« Dernier message par Pierre59 le Aujourd'hui à 05:12:19 pm »

Le gestionnaire json comporte déjà un compteur du nombre de zones occupées par un train, une borne max permettrait de détecter les ruptures d'attelage.

On peut aussi, lors d'une libération d'une zone par un train vérifier que la (ou les) précédente(s) ne contient plus ce train, ce doit être la dernière zone du train.

Pierre

3

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« Dernier message par Dominique le Aujourd'hui à 02:25:18 pm »

Ne serait-il pas opportun d’inscrire et d’utiliser la longueur des trains dans leur objet et la comparer à celle des zones traversées et l’outil “provenance” ?

Évidemment cela ne nous met pas à l’abri d’une perte de wagon mais la détection de présence dudit wagon peut générer une erreur par rapport au passage du train complet.

Il faudrait donc compléter l’initialisation des trains avec des données plus larges, ce qui implique de préparer des compositions de trains à l’avance. Il y a longtemps que je ne suis rendu compte qu’on ne peut pas mettre n’importe quel wagon derrière une machine ou un wagon, à cause de la fiabilité aléatoire des attelages dans les courbes et les zones d’aiguille, surtout en N.

Quand les enfants viennent jouer, des trains non initialisés fichent la pagaille et je ne demande si on peut réduire cet inconvénient (zones pas libérées entre autres).

4

Vos projets / Re : centrale DCC / analogique modulaire

« Dernier message par trimarco232 le Aujourd'hui à 01:42:22 pm »

Bonjour ,
les 4 couches me permettent de diminuer le nombre de cartes , d'arduino , de câblages , donc je pense que je suis globalement gagnant ; je vous dirai combien ça coûte quand j'aurai lancé la commande (il y a aussi le coupon qui s'applique à la fin)

5

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« Dernier message par Pierre59 le Aujourd'hui à 11:20:54 am »

Bonjour

Je suis tombé récemment sur un petit problème avec le gestionnaire json, ce gestionnaire utilise un transit souple. Dans un transit souple dès qu'une zone d'un itinéraire est libéré après le passage d'un train, elle peut être utilisée par un nouvel itinéraire.

Prenons un cas concret, illustré par le bout de tco ci dessous, le train bleu parcours l'itinéraire de A vers X, le train rose est en attente de l'itinéraire de X vers 1 qui est en mémoire. Dès que le dernier essieu du train bleu libère la zone de la tjs, l'itinéraire en attente se forme et le train rose peut passer sur la tjs. Cela parait tout à fait normal et cela l'est.

Mais en pratique avec un réseau réel, sncf ou miniature (j'ai fait des essais sur mon réseau HO), quand le dernier essieu du train bleu quitte la zone de la tjs, le bout de la caisse du dernier véhicule engage encore le gabarit de la zone tjs et se ferait percuter par le train rose si le train bleu s'arrêtait.

Ce problème est assez général et peut se produire avec toutes les traversées entre deux voies à l'entrevoie minimum.

Des idées, des solutions ?

Pierre

6

Vos projets / Re : Ma première centrale DCC

« Dernier message par Jozef le Aujourd'hui à 12:41:09 am »

Bonjour,
J'arrive peut-être comme une cheveu sur la soupe mais j'ai réalisé une centrale avec Uno et un Lmd18200 comme moteur. Mon circuit comporte plusieurs contons donc je voudrais les alimenter avec des booster a la base du lmd18200. Mais je ne sais pas du tout comment récupérer DCC a partir de mon Arduino Uno.
Peut-on m'aider
Merci d'avance
Jozef

7

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« Dernier message par DDEFF le mai 04, 2024, 07:08:45 pm »

Merci Dominique !

J'admire ton optimisme ... mais ton expérience est biaisée.

Ton réseau a été présenté dans Locoduino et a servi de modèle.
A l'époque, Pierre, qui maîtrise parfaitement les subtilités de la signalisation de la SNCF, a réalisé des articles très complets sur ce que doit être un gestionnaire.
Ces articles sont toujours d'actualité, d'ailleurs.
Puis tu lui a demandé de t'expliquer où mettre des signaux et de quels signaux il s'agissait sur ton réseau, ce qu'il a fait.
Dans son programme, la description des signaux (et du réseau) est intégrée et ça fonctionne chez toi parfaitement.
En lisant le programme, tu as compris comment cela avait été fait. Mais aurais tu pu le trouver tout seul ? On ne le saura jamais...

En refaisant ce nouveau fil de discussion, on a décidé d'extraire les infos descriptives du réseau dans un fichier JSON.
L'idée était que l'on puisse avoir un point de passage clair, précis, adapté à n'importe quel réseau SANS CONNAISSANCES SNCF.
Donc, lorsque ce fichier aura subi tous les tests, il sera labellisé Locoduino.

A ce moment, n'importe qui pourra faire un éditeur dont le fichier de sortie sera le JSON Locoduino et il pourra dès lors utiliser le gestionnaire que Pierre est en train tel quel pour commander ses trains.
Le gestionnaire doit être "neutre", c'est à dire qu'il doit fonctionner à partir du fichier JSON (et rien d'autre).
De la même façon, si quelqu'un sait faire un gestionnaire qui fonctionne à partir du fichier JSON Locoduino de son réseau, il pourra utiliser mon éditeur pour générer le fichier JSON.

J'ai fini la partie "générer tous les itinéraires possibles d'un réseau", itinéraires qui contiennent la position des signaux.
Moyennant une partie de programme à faire, je vais calculer quel signaux doivent être affichés pour un signal donné, ce qui permettra de définir la cible (A,B...H) à acheter pour ce signal.
Les itinéraires de la gare seront extraits de la liste complète et intégrés dans le JSON, de façon à ne plus avoir à les calculer dans le gestionnaire.

Donc : je ne connais pas la signalisation SNCF, je sais juste qu'il doit y avoir un signal là, là et là. J'appuie sur un bouton et le programme me dit:
Là, il doit y avoir VL, A, S et RR, là C, A, R, etc...

Pour info (c'est totalement anecdotique) mon programme trouve et affiche en détail en 6 secondes la liste des 2 572 itinéraires possibles de ton réseau, parmi 3 582 couples départ/arrivée testés 

Denis

8

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« Dernier message par Dominique le mai 04, 2024, 06:27:04 pm »

Après quelque temps occupé par divers travaux et événements familiaux, de retour à la montagne, je plonge dans les derniers programmes Processing de Pierre : GestJ2 et GestTCO2.

Celui qui m'intéresse le plus est GestJ2 car c'est le gestionnaire pur et dur. Il est écrit en Java (ou Processing, c'est pareil ?) et j'arrive a faire des analogies avec les objets C++ comme dans la version C++ que j'utilise.

Les grandes différences avec mon gestionnaire C++ sont :
- la description des objets (zones, aiguilles, signaux, trains, ..) est issue d'un fichier JSON qui serait préalablement construit avec l'éditeur de Denis (je vais en reparler plus loin).
- les événements de rétrosignalisation (occupations, libérations, commandes des trains et des itinéraires, ..) sont générés sous forme de messages TCP en provenance de GestTCO2 : c'est donc de la simulation et non du réel, mais j'imagine bien qu'on pourrait détacher ce TCO et le remplacer par les événements réels d'un réseau.

Première remarque : le but est théoriquement bien atteint pour le gestionnaire paramètrable qui est le point de départ de ce fil du forum. Bravo !

Un tel gestionnaire pourrait donc être réalisé sous forme d'une carte Arduino "connectée". En gros, on aurait ainsi l'équivalent d'un JMRI, RocRail ou CDMRail sans PC !!

- connectée à un éditeur de réseau JSON qui servirait à paramétrer le gestionnaire en fonction du réseau du modélistes.

- connectée aux capteurs d'occupation/libération et autres capteurs (ponctuels, RFID, RailCom, etc..) du réseau réel.

- connectée à la centrale DCC pour les commandes des trains (régulation, automatismes, ..) et récupérer les états de mouvement des trains (direction, vitesse), ainsi que les incidents éventuels.

- connectée à un TCO graphique qui permet de visualiser ce qui se passe sur le réseau réel (ou simulé) - dans ce cas la description du réseau JSON du gestionnaire est à dupliquer en liaison avec des rendus graphiques pour une interface humaine sympathique.
Dans l'exemple GestTCO2, le TCO permet de commander les trains, les itinéraires, voire les aiguillages. Ce TCO simule les déplacements des trains et génère automatiquement,ent les occupation et libération. Il fait tout ce qui est décrit plus haut, sauf l'éditeur de fichier JSON qui est développé séparément par Denis.

Si on met tous ces éléments bout à bout, on obtient un gestionnaire complet comme JMRI, RocRail ou etc. qui ne tourne que sur PC/Mac, voire Rpi (mais ça rame peut-être)

Deuxième remarque : ce TCO GestTCO2 est beaucoup plus compliqué que le gestionnaire GestJ2

Mais on en a besoin pour voir et commander les trains et le réseau. Du moins en mode simulation.

Troisième remarque : si je dois appliquer tout ce travail à mon réseau Dominique, que dois-je faire ?


C'est mon avis évidemment et je peux me tromper :

1) traduire en C++ le gestionnaire GestJ2 pour l'installer dans un Arduino (Due en ce moment ou à base d'ARM, avec assez de mémoire et de CPU, mais cela ne semble pas critique)
2) la description en fichier JSON n'a besoin d'être faite qu'une seule fois donc inutile de construire un éditeur connecté au gestionnaire, l'intégration à la compilation est suffisante.
3) connecter toute la rétrosignalisation via un bus CAN ce qui est déjà fait ou très simple à faire la plupart des microcontrôleurs sont capables de communiquer en CAN : libérations, occupations, signalisation, aiguillages, et bien plus si affinité.
Toutefois, passer du mode simulation au mode réel en remplaçant les messages "parfaits" du TCO GestTCO2 par des messages Can qui ne seront pas forcément parfaits, nécessitera (comme actuellement) des travaux de mise au point et du monitoring des événements et états pour la mise au point.
Sans oublier la centrale DCC déjà reliée au CAN (Mega+DCCpp ou LaBox).
4) connecter un TCO graphique pour visualiser ce qui se passe, ce que j'ai déjà en chantier sur un écran 7" piloté par un Teensy3.6 (en passant, je regarde le développement des tableaux de bord de voitures qui ont des écran superbes dont les prix finiront par devenir abordables, mais seront-il accessibles aux programmeurs ferroviaires ??).
5) connecter éventuellement des organes de commandes des trains (les applications smartphone comme Z21 font l'affaire), des itinéraires et horaires, etc.. sur le TCO graphique en principe.

En ce qui concerne l'éditeur de Denis, pour obtenir le fichier JSON de description du réseau pour le gestionnaire, cela représente un développement important qui serait mieux valorisé s'il faisait partie d'un éditeur de réseau : pour le gestionnaire ET pour le TCO.
Je sais que ce n'est pas l'objectif initial de ce projet mais Denis a déjà plus ou moins cela dans son PC.
Donc l'avenir va être interessant !!

9

Les réseaux / Re : Projet de réseau Jean-Claude74

« Dernier message par Dominique le mai 04, 2024, 04:51:32 pm »

La retrosignalisation comprend la « retro » c’est à dire les capteurs d’occupation et autres capteurs. Les etats de ces capteurs sont remontés en protocole S88 (dans le cas qui vous intéresse), mais à quoi ?

En tout cas, pas à la centrale, mais à un gestionnaire de réseau comme JMRI, RocRail, CDMRail ou autre (dont ceux qu’on peut développer soi-même comme c’est mon cas, avec le bus Can).

Ce gestionnaire, dans lequel vous avez décrit votre réseau va pouvoir suivre les trains grâce aux états des capteurs remontés en S88, assurer leur sécurité (ralentissements, arrêts), et former les itinéraires en commandant les aiguillages et les signaux.
Dans ce dernier cas ces commandes de trains, aiguillages et signaux passent par la centrale qui les envoie en DCC sur les rail grâce au protocole DCC++ venant du gestionnaire par les pins RX et TX de la centrale.

Il y a plusieurs manières de raccorder des manettes, via le gestionnaire (votre pc), votre smart phone en wifi ou en radio avec LaBox en particulier. Tout cela est décrit un peu partout dans Locoduino.

Dans tous les cas ci-dessus, il n’y a pas de modifications de logiciel à faire.

Mon conseil est d’essayer LaBox qui est la centrale la plus aboutie pour le moment, même si vous n’êtes pas familier avec l’ESP32.

D’autres avis tout aussi pertinents vous parviendront aussi, j’en suis sûr.

Bon courage.

10

Les réseaux / Re : Projet de réseau Jean-Claude74

« Dernier message par Jean-Claude74 le mai 04, 2024, 01:43:29 pm »

Merci pour votre réponse.
En ce qui concerne le lien proposé, je n'ai pas compris en quoi cela pourrait être intéressant pour mon projet.
J'attendais des réponses sur mes choix de centrales DCC++ et manettes et donc, je pense, que ceux sont des bons choix.

Une autre question, comment la centrale DCC++ va interpréter les informations venant de la manette ou des Arduino Nano utilisés pour la rétrosignalisation; Bien sûr il y a le RX et le TX mais comment ça marche?
Aurait-il des informations à entrer dans le programme de la centrale?

Cordialement
Jean-Claude