Messages récents

1

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

2

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

3

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

4

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 !!

5

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.

6

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

7

Vos projets / Re : Nouveaux AVR:coeur AVRx avec MEGACOREX, DXCORE, MEGATINYCORE: utiliser le HARD:

« Dernier message par laurentr le mai 04, 2024, 11:07:45 am »

Oui les possibilités sont presque illimitées et il devient grâce à ces outils de concevoir des choses très modulable "on demend"!

Je note ta remarque sur l'hysterisys qui ne manque pas d intérêt. A teste "sur site"!

Les seules limites par exemple pour le comparateur est de ne jamais devoir dépasser le Vmax de 5V sur les broches sinon il faut brider ( résistance & zener par exemple)

J ai utilise une fonction simple pour comparer deux valeurs entre elle provenant de deux sources connues "calibrées".
On peut comme tu le soulignes utiliser des valeurs internes ce qui est un peu plus complexe pour les néophytes mais reste tout à fait utilisable simplement avec ces librairies. ( je ne l'ai pas personnellement encore expérimenté)

Une autre astuce est d utiliser un composant de référence de tension externe si on veut avoir précision et moins se faire de nœuds au cerveau. Un TL431 peut bien faire le lob au besoin.

Les exemples de portes logiques en cascades sont intéressant à exploiter aussi dans l'optique de ne pas avoir à encoder tout cela au niveau soft et de bénéficier de la souplesse de la logique programmable.

On pourra trouver qu'il en manque encore et que plus ne seraient pas mal venues!

La série 2 des TINY semble indiquer qu'on peut utiliser en parallèle la sortie physique et simultanément établir une liaison via EVENT ce qui augmente de fait les combo de sorties possibles.

Je n'ai pas retrouve ce cas d'usages/possibilités sur les AVR Dx y compris les DD.

Mes remarques sont pour dire que si plus de deux blocs logiques sont requis alors il faut passer sur les TINY série 2 à minima sinon sur les AVR Dx.

A 'inverse si on veut bénéficier de plusieurs comparateurs (max3) il faut être sur la série 1 TINY ou AVR DA & DB exclusivement.

J ai garde le meilleur pour la fin sur les portes logiques!

Et bien nous connaissons ce qui va se passer selon ce qui est mis sur les entrées... et bien il ne reste que simplement par soft dans notre code à piloter des sorties de broches qui seront alors reliées par des pistes aux entrées... et la logique fera le reste si j ose dire à la vitesse de l'éclaire avec un temps de commutation proche de celui de bascule d une ou plusieurs broche au niveau code.

Rudement efficace!

Je sens bien toutefois qu'il va falloir illustrer toute cette circuiterie à travers un petit projet démo qui mettra en avant les apports.

Je réfléchis, je verrai bien la gestion d'un carrefour routier par exemple mais on doit pouvoir trouver d'autres cas à illustrer.

Des idées?

Ltr

8

Vos projets / Re : Nouveaux AVR:coeur AVRx avec MEGACOREX, DXCORE, MEGATINYCORE: utiliser le HARD:

« Dernier message par trimarco232 le mai 04, 2024, 09:47:03 am »

Bonjour ,
merci Laurent pour cette présentation !
je découvre notamment l'existences des frameworks , qui simplifient l'écriture et surtout rendent les choses + compréhensives , c'est mieux que les exemples de Microchip , qui s'éloignent à peine du bare metal

pour les comparateurs , j'activerais systématiquement l'hystérésis : pour les entrées très raides , ce n'est pas utile , mais pour les signaux variables , cela évite d'avoir ceci : _______|‾|_|‾|_|‾‾‾‾‾‾‾‾ , en sortie lors des transitions
dans ton exemple , tu as utilisé une tension externe comme tension de référence , mais on pourra souvent utiliser une tension interne , voir le DAC si la valeur est critique , cela économise une broche ; il peut cependant se produire que cette tension de référence soit disponible sur l'entrée (-) alors que , zut , on la voulait sur l'entrée (+) : dans ce cas il suffit d'intervertir le rôle des entrées (+) et (-) , et d'actionner l'inverseur en sortie du comparateur (en fait amha , l'inversion en sortie permet surtout de permuter les entrées , si besoin)
on notera aussi la présence de la broche de sortie , non disponible sur les AVR classique : elle permet par exemple , par une contre-réaction positive , d'obtenir des valeurs d'hystérésis supérieures aux 50mV disponible dans le hardware du comparateur

concernant le Configurable Custom Logic (CCL) , il y a une très intéressante notte d'application , qui montre notamment qu'on peut faire une porte à 5 entrées , en combinant 2 portes à 3 entrées , mais pas que , voir aussi l'astucieuse configuration du TRUTHn register : https://ww1.microchip.com/downloads/en/AppNotes/TB3218-Getting-Started-with-CCL-90003218A.pdf

9

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

« Dernier message par Dominique le mai 04, 2024, 09:31:16 am »

Bonjour,

Pouvez-vous regarder de ce côté là :
https://forum.locoduino.org/index.php?topic=1700.msg19105#msg19105

10

Aide / Re : Re : Problème de démarrage serveur.

« Dernier message par Tony04 le mai 04, 2024, 12:26:52 am »

Je souhaiterais deja essayer de la faire 'tourner' sans rétro signalisation mais lorsque je téléverse, rien ne se passe par la suite.

Bonjour Cyril,

83, pas très loin du 04...

Je ne vais malheureusement pas t'apporter de l'aide pour ton problème exposé dans ce fil, mais quand tu auras trouvé la solution et que tu vas passer sérieusement à la rétro signalisation, ne fais rien avant d'avoir étudier ce nouveau principe.

Imagine coté centrale un câble de 20 à 30cm de long avec 5 fils qui vont à une carte composée simplement d'un WeMos D1 MINI et de 3 BSS138 (adaptateur de niveau 3,3/5V), montés sur un circuit pastillé comme ceci:



Voila tout ton bus S88 opérationnel pour les 512 retours, maximum acceptés par les centrales.
Je te joins au message 2 sketchs, l'un pour 1 word de 16 bits, et l'autre pour 15 word de 16 bits (ce dernier gère actuellement 4 TCOs dont celui de la vidéo plus bas dans ce message), juste pour te montrer la simplicité de l'ensemble.

De l'autre coté tu pourras mettre des détecteurs d'occupation de ce type, en 4 entrées:



ou 8 entrées (pas de photo de la carte fini, juste de mon PCB):



Ou des TCOs dans ce genre: https://www.youtube.com/shorts/YZ18kNaU1LU qui sont juste reliés par 2 fils pour le 12V (et 2 fils DCC si on veut gérer le retour des trames DCC de la centrale)

Ou toute autre commande pour une animation quelconque, bref tout ce qui peut se faire par la rétro signalisation S88...

Mais sans aucun fil à part l'alimentation des cartes ou le DCC selon le résultat à atteindre.
Et surtout plus d'achat de modules de rétro assez onéreux.

La fragilité (relative) du bus S88 est totalement balayée, car plus aucune longueur de câble et le S88 est géré par la majorité des centrales y compris les centrales "Locoduino".

Alors si tu veux plus d'infos tu peux me contacter par MP.

Cordialement
Antoine