Messages récents

Pages: [1] 2 3 ... 10
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« Dernier message par DDEFF le Aujourd'hui à 05:07:32 pm »
Bonjour,

Depuis des années, je suis persuadé qu'on peut calculer les signaux à partir du dessin du réseau et quelques infos simples.

La vraie question qui se posait, c'était de savoir quelles infos étaient absolument indispensables.
Je viens de franchir une étape que je vais vous détailler.

Je vais le faire sous forme d'une série de posts. Le programme sera proposé dans le dernier post.

Pour l'instant, il sort plusieurs fichiers complets, faciles à lire (et à comprendre, j'espère), mais il faudra en extraire les infos utiles au fichier JSON en ce qui concerne les signaux et les itinéraires.
En gros, il y a "trop" d'informations et il ne faudra garder que celles absolument nécessaires au gestionnaire. Par exemple, quand il y a plusieurs itinéraires entre un point A et un point B, lequel choisir ?

Infos minimales :

Je prends comme exemple le réseau de Dominique qui est assez représentatif des difficultés rencontrées par de nombreux modélistes.


 
Sur ce dessin, sont représentés les infos qui doivent être rentrées dans mon programme pour que tous les calculs soient faits.
Il faut faire ce dessin, avant de rentrer les infos.
 
Dès le dessin, il faut prendre des décisions : sens de circulation des zones, leur nom, la position des signaux.
 
A noter que j'ai retiré les numéros de voie et je n'ai gardé que les noms de zone.
On pourra, par la suite, donner des numéros de voie, mais ils ne serviront pas dans un gestionnaire.

Sont représentés :

1°) Le dessin du réseau :

En rose, les "appareils de voie" (aiguilles, TJD, croisements, …).
En bleu, les "sections", c’est-à-dire tout ce qui n'est pas un appareil de voie (rails droits, courbes, flexibles)

Exemple : Z17 est un appareil de voie (une aiguille) et Z16 est une section.

Je fais la distinction car j'impose aux signaux de n'être que sur des sections.

Une première difficulté apparait sur la Z46 qui est, pour moi, une "zone complexe". Elle est composée de l'aiguille a20, d'une section de longueur nulle qui supportera le signal et de l'aiguille a10.
Dans le programme actuel, la Z46 est une TJD sans signal.
C'est une erreur, mais je réserve pour la suite le traitement des zones complexes. J'ai une idée assez précise de ce que je vais faire, mais on en parlera plus tard. Il y a déjà assez de questions à se poser avant.

Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.

Je considère qu'il y a 2 gares : la gare g0 en bas (hors zone de manœuvres) et la gare g1 en haut.

Par ailleurs, une navette se promène sur les zones vertes (de Z40 à Z41).
 
Je n'ai pas considéré que Z40+Z0 et Z41+Z3 soient des gares, mais on aurait pu le faire car, dans la réalité, ce serait le cas.
Mais l'intérêt de déclarer un ensemble de zones comme étant une gare, c'est qu'on peut attribuer des itinéraires à cette gare. Et là, … les itinéraires…

2°) L'orientation des zones (les flèches rouges) :

Toute zone a un sens privilégié, ne serait-ce que pour la dessiner.
Je préfère raisonner par "côtés" (voir un précédent post à ce sujet).
Le sens privilégié (la grosse flèche) va du "cote0" au "cote1" (de A à B). Donc, quand vous sélectionnerez une section, vérifiez bien que le sens que vous avez choisi correspond bien à celui du dessin du réseau.
Pour les appareils de voie, j'ai fait un récapitulatif des différents cas :


 
Le point rouge correspond au cote0, les autres extrémités étant cote1. Je reviendrais sur ce schéma dans les itinéraires.

Le point bleu sur le dessin du réseau correspond à la présence d'un signal.
Pour les zones n'ayant qu'un seul sens de circulation, le signal est toujours "cote1".
Pour les zones ayant les deux sens de circulation (les zones "banalisées"), on a une deuxième flèche, plus petite.
Pour moi, les zones banalisées "ont un sens". Pensez-y en choisissant où vous mettez les feux (côté A ou côté B dans le programme) : il y a un signal "cote0" (= A) et un signal"cote1" (=B).

3°) La parité :

On n'a pas à rentrer spécifiquement la parité d'une zone.
Rien qu'en choisissant une section sur l'octogone de départ, vous définissez la parité de la zone. Puis, par itération successives, le programme calcule la parité des appareils de voie.
Par exemple, la zone 24 est déclarée "sens impair" par le fait que les zones Z22, Z23 et Z25 sont impaires.
La parité d'une zone est donc calculée et entrée directement dans le fichier JSON pour usage ultérieur dans un gestionnaire. Les zones banalisées sont dites "pairimpair".

4°) Zones complexes :

Pour l'instant, chaque appareil de voie est une zone à lui tout seul. Ce n'est pas toujours le cas dans la réalité.
On regroupe souvent des appareils en une seule zone ou une zone peut être constituée d'une section et d'un appareil de voie. C'est ce que j'appellerai une "zone complexe", pour l'instant non gérée par le programme actuel. A suivre, donc.

5°) Les vitesses limites :

J'ai défini (arbitrairement) la vitesse maxi à 160 km/h.
Il y a deux types de limitation de vitesse.
 
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
On la rentre simplement dans la section en cliquant sur le point blanc sur le tracé de la zone. On affiche alors la vitesse qui apparait dans un losange sur le dessin de la zone.
Dans les fichiers d'itinéraires, la vitesse limite sera alors suivie de "TIV".

- Les limites liées à une position déviée d'aiguille.
On la rentre de la même façon sur la branche concernée du dessin de l'appareil de voie.
Elle est également affichée dans un losange sur la branche concernée.
Dans les fichiers d'itinéraires, la vitesse limite sera alors suivie de "RR".
On verra dans le calcul des signaux que cette info est cruciale.

A noter que la vitesse limite dans la position "tout droit" est une limite de type TIV.

6°) Le calcul des zones de gare :

Les gares sont parfois importantes et, même si on peut rentrer ces infos à la main, zone par zone, cela peut être très fastidieux. J'ai donc développé un programme qui complète automatiquement les infos rentrées.
Dans une première version, j'arrivais à définir les gares en ne définissant qu'une seule zone. Mais il fallait des gares vraiment particulières.
Dans cette version, il faut rentrer les infos de zone d'approche et de zone de sortie, le programme ne pouvant pas toujours les définir automatiquement.

Dans le cas de la gare0 du réseau de Dominique, on rentre :
En zone 11 : "ap_g0" dans le champ "gare". C'est la zone d'approche de la gare0.
En zone 16 : "so_g0" dans le champ "gare". C'est la zone de sortie de la gare0.
En zone 25 : "ap_g0" dans le champ "gare". C'est la zone d'approche de la gare0.
En zone 30 : "so_g0" dans le champ "gare". C'est la zone de sortie de la gare0.
Et on rentre "g0" dans la zone 27, ce qui devrait permettre de calculer la gare.
Malheureusement, ça "bave" sur la zone de manœuvres qui se trouve ainsi déclarée "gare", ce que je ne veux pas.
Il faut donc, en plus rentrer "bloque" en zones Z36, Z45 et Z46. Et là, tout est OK.

7°) Le calcul des zones de manœuvres :

C'est un calcul similaire au calcul d'une gare, mais il n'y a pas besoin de bloquer puisque la gare est déjà définie et elle va bloquer l'expansion de la zone de manœuvres.
Il faut juste entrer :
En zone 16 : "ap_m0" dans le champ "manœuvres". C'est la zone d'approche de la zone de manœuvres 0.
En zone 30 : "ap_m0" dans le champ "manœuvres". C'est la zone d'approche de la zone de manœuvres 0.
Puis Z36 et Z37 définies comme "m0".

A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant. Les zone Z16 et Z30 sont donc banalisées.

Une zone de manœuvres est toujours banalisée.
 
Il s'ensuit que la zone de gare Z14 est forcément banalisée à cause de Z45 et Z46 banalisées, ainsi que la zone de gare Z28 à cause de Z36.

Voilà, on a fait le tour de toutes les infos nécessaires au fonctionnement du programme.

On voit qu'elles sont chacune assez simple à déterminer et que les connaissances de la SNCF sont très minces pour mener à bien cette mission.
Tout le reste est automatique.

En PJ, le réseau en plus grand, plus lisible, les appareils de voie, imprimables et le fichier "Zones" initial en .tsv (à ouvrir dans Excel) dans lequel on voit qu'il y a plein de cases vides...
On y voit aussi les cases remplies via les dessins de zones. On ne rentre rien directement dans le fichier sous peine d'erreurs et d'incohérences.

A suivre : les itinéraires

Denis :P
2
Vos projets / Re : Re : RailCom: Générateur de CutOut avec booster
« Dernier message par Brunotoutsimple le Aujourd'hui à 11:03:07 am »
Bonjour Bruno

C est une option mais la mise en œuvre n'est pas si trivial.

Ltr

D'accord, je pense que c'est plus compliqué de le faire que le dire. Moi, en temps qu'électricien-domoticien, j'étais confronté à des demandes qui étaient compliquées à mettre en œuvre.
3
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« Dernier message par laurentr le Aujourd'hui à 10:49:32 am »
Bonjour Bruno

C est une option mais la mise en œuvre n'est pas si trivial.

Ltr
4
Aide / Re : sprog3, DCC Center et DCC decoder
« Dernier message par PhilGuen le Aujourd'hui à 01:23:33 am »
Je pense que j'ai trouvé.

en fait, celà doit venir du mode d'adressage différent entre les locos qui commencent par 0 et les accessoires qui commencent par1

A vérifier demain

bonne nuit
5
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« Dernier message par Brunotoutsimple le Aujourd'hui à 12:11:31 am »
Bonsoir à vous

Laurent
Dites moi si je ne trompe, la sortie E de CDE permet de signaler un problème du booster. On pourrez récupérer et envoyer cette information au TCO en passant par le CAN. l'opérateur de gestion pourra réaliser manuellement ou automatiquement le détournement des trains sur une autre voies et signaler se défaut.
6
Aide / Re : sprog3, DCC Center et DCC decoder
« Dernier message par PhilGuen le mai 20, 2024, 10:40:39 pm »
Bonsoir Thierry.

Merci pour votre réponse ... même si je ne la comprends pas. Parle-t-on bien de la même chose?

Logiciel Windows(c)  DCC Center également nommé "Centre de Programmtion DCC" pour gérer une Sprog3

Sketch DCC Monitor fourni en exemple avec la bibliothèque DCC_Decoder.h

Comme le montre bien la copie d'écran, si j'utilise un accessoire avec l'adresse 100, le sketch "lit" 164. Il doit y avoir quelque chose que je n'ai pas compris.

Si quelqu'un a une piste sur cette anomalie, je suis preneur.

Bonne soirée à tous.
7
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« Dernier message par laurentr le mai 20, 2024, 08:21:05 pm »
Bonsoir Bruno

Je teste actuellement cette solution.
Je n'ai pas encore assez avancé pour publier le résultat ( autant ne publier que ce qui fonctionne!?) mais cela sera fait des que possible.

En effet on a bien l'équivalent des plots C et D.
Convertir les tensions ajoute de la complexité mais reste une option (à tester aussi)

Je n'ai pas travaillé sur une refonte de Labox intégrant un dispositif de cutout mais d autres membres du forum s'y consacrent.

Cela devrait aboutir dans de nouvelles propositions.

Ltr
8
Aide / compteur vitesse ho et n
« Dernier message par ludovic26 le mai 20, 2024, 04:51:14 pm »
bonjour  j'ai réalisé le montage  ,  https://www.locoduino.org/spip.php?article173            téléversé le programme, j'ai ensuite sur cdm, crée une boucle sans arrêt à vitesse constante de 80km/h ,(pour avoir une idée) sur l'écran du compteur , 7.52 km/h , je précise réseau ho j'ai aussi indiqué 0.50( la distance entre mes deux barrières ) au lieu de 0.22, comme mentionné pour du ho
ou ai mon problème , merci  de votre retour .
9
Bnjour à tous.

J'ai corrige une petite erreur typographique présente dans les exemples donnés.

Sur les blocs logiques j avais simplement mi:

LogicN.enable;
Ce qui est faux et doit etre remplacé par:

LogicN.enable = true;
Ex
Logic2.enable = true;
Mea culpa!



10
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« Dernier message par Brunotoutsimple le mai 20, 2024, 11:48:14 am »
Merci Laurent
Pages: [1] 2 3 ... 10