Auteur Sujet: Projet partagé d'un gestionnaire de réseau  (Lu 25962 fois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2917
  • 100% Arduino et N
    • Voir le profil
Re : Re : Re : Projet partagé d'un gestionnaire de réseau
« Réponse #60 le: janvier 07, 2024, 01:07:22 pm »
Comment fait-on pour détecter une présence sur une aiguille ?
Faut-il isoler l'aiguille complètement ?
Faut-il un ou deux capteurs ?
...?
Oui,
Moi je le relie à un petit coupon de voie qui supporte l’éclisse isolante car l’aiguillage est fragile et il est souvent difficile de mettre une éclisse isolante. C’est plus facile aussi de souder les fils d’alim sur ce bout de voie.
Cordialement,
Dominique

laurentr

  • Hero Member
  • *****
  • Messages: 610
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #61 le: janvier 07, 2024, 03:04:41 pm »
Bonjour

Je vais essayer d expliquer le traitement des aiguillages, TJD et croisements.
On en déduira les attributions à faire avec.

Partons d un cas simple: une AIGUILLE A prise en pointe depuis un CANTON N-1 qui va de façon directe sur le CANTON N et en itinéraire dévié sur N bis

L'AIGUILLE A appartient géographiquement à une ZAP ( Zone d appareil(s)/zone d aiguille(s))
 
En mode directe on a
 C N-1 <>ZAP<> C N

En mode dévié on a
 C N-1 <>ZAP <> C N bis

Dans ce cas simple on peut ajouter au canton N l'alimentation et la détection de la ZAP  car tout mouvement de N-1 vers ou depuis ou N ou N Bis transite exclusivement par la ZAP
On devra toutefois arrêter nos trains avant l AIGUILLE A dans le sens N-1 vers N ou N bis.
Attribuer une détection sur une section aussi courte qu'une seule aiguille n'est pas optimum ( en terme de conso de ressources)

Passons au cas ou toujours sur ce modèle nous avons non plus une mais 2 ou plusieurs aiguilles qui adressent les cantons N Ter N Quatro ...

La longueur de la ZAP a augmenté. Tout mouvement de N-1 vers un canton N-x et réciproquement transite par la ZAP.

Il n y a pas de trajet sécant possible traversant la ZAP puis que nous avons une succession simple d aiguillese. Si une aiguille n est pas dans une position qui desserre le canton N-x alors la sécurité verrouille les mouvements.

On peut traiter le cas de deux façons:
Soit comme précédemment ( association à la dernière zone du canton précèdent)
Soit si la longueur est étalée ajouter une détection spécifique.

Cette configuration devient utile et nécessaire dans le cas d itinéraire(s) sécant sur la ZAP ou  d'entrées/sorties multiples
Ex aiguilles montées pointe contre pointe
On vient alors soit de
N-1 ou N-1bis <> ZAP<>N ou N bis ou Nx

La ZAP devient alors une section "autonome". Elle est logiquement la continuité des directions qu'elle relie mais électriquement elle est autonome ( sauf à la basculer d une section vers un autre ce qui complexifie le câblage du fait des combinaisons possibles!)
Cela devient un "cauchemar" si on a un grill d'entrée/sortie de gare qui est complexe et offre de multiples combinaisons

En effet en cas de GRILL il faut en fait pour fluidifier le trafic "paralléliser les ZAP" et les relier entre elles en cas d itinéraire sécant. ( Bretelles, TJD, TJS...)

On voit très vite qu'une ZAP et un objet LOGIQUE et PHYSIQUE
Rm: on ne cantonne pas sur une ZAP ( pas d arrêt commande par le BLOC)

En principe on n'y stationne pas non plus ( sauf si le canton qui reçoit le train est plus court que le train à recevoir)( doit il dans ce cas le recevoir?)  on ne fait qu'y transiter . Pourquoi cette précision? et bien par ce que si notre convoi a une détection en tête et une en queue uniquement alors il est possible que la ZAP ne porte pas de détection ... on pourrait interpréter la ZAP comme libre... ce qui est un erreur de diagnostic. ( le train est a cheval entre N-1 et N et au dessus de la ZAP!

On voit alors que l'objet ITINERAIRE de réservation de ressource et ses conditions de libération sont très importantes.

Le système proposé par Denis couvre ce cas de figure et nous exempte d anomalie à ce niveau.

Le cas des TJD TJS et bretelle est donc la combinaison optimale de découpage des ZAP pour assurer un trafic fluide selon les combinaisons d itinéraires.

Laurent






Pierre59

  • Sr. Member
  • ****
  • Messages: 329
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #62 le: janvier 07, 2024, 04:18:58 pm »
Bonjour

Voila ci-dessous un exemple d'une zone complexe tout à fait possible pour un gestionnaire. Elle comporte une TJD et trois aiguilles, c'est une partie d'une image d'un ancien TCO.

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2917
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #63 le: janvier 07, 2024, 04:25:43 pm »
Je m'inquiete  un peu ! >:(: qui va coder un gestionnaire concret, utilisable dans la plupart des réseaux de nos amis modélistes, si on cherche d'emblée tous les cas difficiles que la plupart d'entre nous n'envisage pas de construire.

Va-t-on faire fuir nos lecteurs qui espèrent trouver un gestionnaire centralisé ou non mais surtout accessible au plus grand nombre  ?  :o

Au contraire, il faudrait plutôt réaliser un noyau simple de gestionnaire, compréhensible, qui puisse être étendu et complexifié par la suite.
Donc procéder par étape. Pierre vient de prouver  :D

Ne serait-il pas raisonnable de partir d'un exemple concret comme un Locoduinodrome (peut-être un peu plus large avec 2 voies en parallèle et en sens contraire) ?

On verrait mieux dès le départ les différents propositions de définition, d'organisation, de spécification et de réalisation avec les pour et les contres.

Je prend l'exemple de mon réseau, le gestionnaire est basé sur les articles de Pierre (un Gestionnaire en C++ pour votre réseau - voir les liens sur la première page).

Tous les objets qui le composent (zones, aiguilles, signaux, itinéraires, ..) sont hérités d'une classe de base qui est personnalisée (réécrite) pour chacun des objets réels afin d'y introduire les propriétés et méthodes réelles qu'elles doivent exposer. La topographie du réseau s'exprime au travers de ces personnalisations des classes.

Le gestionnaire de mon réseau est basé sur le même principe et je n'ai pas particulièrement souffert de ces personnalisations des objets, d'autant qu'il a été trés simple d'écrire des petits programmes de tests pour vérifier les bons enchainements des zones dans les itinéraires en fonction des positions des aiguilles et de tester tous les organes du réseau. De plus, je ne modifie pas mon réseau tous les jours et si c'était le cas, seuls quelques objets sont modifiés/ajoutés/supprimés.

Mais combien en ont fait autant ?

Est-il possible de réitérer un exercice semblable au Locoduinodrome, qui présente des alternatives à la construction de la topographie du réseau pour faire coopérer tous les objets qui le composent ?

Vos propositions seront les points de départ du ou des  projets partagés.


Cordialement,
Dominique

laurentr

  • Hero Member
  • *****
  • Messages: 610
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #64 le: janvier 07, 2024, 04:50:17 pm »
@Dominique

En fait si tu analyses bien un objet ZAP à un instant T 2 éléments clés
 un élément prédécesseur( ZAP ou canton ou zone
 un élément successeur ( zone ou canton ou autre ZAP)

C est la position des aiguilles qui route les combinaisons entée/sortie.

Il faut alors me semble il juste déclarer à quelle zone appartient une aiguille lors de design du reseau.

Pour ce qui est du nouveau LOCODUINODROME je suggere comme tu l indiques
1 double voie
1 boucle de retournement
1 double bretelle
1 croisement( type bif par exemple)
1 aiguille triple ( symétrique ou asymétrique)
1 bretelle  ou tjd
1 voie en impasse
1 évitement ( pourquoi pas faisant la liaison entre 2 boucle et servant de "garage actif")

Ca fait un peu de monde à caser mais la plus grande partie des cas est présente sur un réseau  de circulation

A vos crayon pour assembler le tout.

Et comme dit si bien Dominique vous avez 1 heure!  8)

Ltr



Pierre59

  • Sr. Member
  • ****
  • Messages: 329
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #65 le: janvier 07, 2024, 05:09:37 pm »
@ Laurent

Le locoduinodrome que tu propose est beaucoup trop compliqué. Le locoduinodrome d'origine est déjà assez compliqué comme ça. L'idée d'un locoduinodrome à double voie de Dominique est séduisante, mais avec une voie d'évitement. Cela fait deux aiguilles et deux TJS (bien lire Traversée Jonction Simple).

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2917
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #66 le: janvier 07, 2024, 05:19:12 pm »
Je suis d'accord avec Pierre : démarrons simple !

et en HO et Peco, c'est 60 à 70€ !

en N je ne trouve pas grand chose.
« Modifié: janvier 07, 2024, 05:35:15 pm par Dominique »
Cordialement,
Dominique

Pierre59

  • Sr. Member
  • ****
  • Messages: 329
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #67 le: janvier 07, 2024, 05:47:51 pm »
@ Dominique

Il y a des TJS Peco en N : SL-E380F Crossing, Single Slip

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2917
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #68 le: janvier 07, 2024, 06:38:25 pm »
Un tracé dans ce genre là (en mieux) ?
Cordialement,
Dominique

laurentr

  • Hero Member
  • *****
  • Messages: 610
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #69 le: janvier 07, 2024, 07:10:17 pm »
Je verrai bien quelques chose de ce genre.

Ltr


bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 948
  • HO avec DCC++
    • Voir le profil
Re : Re : Projet partagé d'un gestionnaire de réseau
« Réponse #70 le: janvier 07, 2024, 09:04:07 pm »
Un tracé dans ce genre là (en mieux) ?

Ok pour l'exercice mais il faudrait tout de même définir les zones de cantonnement. Je suppose que les deux rails 6001 après les aiguilles 6080 et 6081 et avant le TJS SL80 ne suffisent pas pour cantonner un train.

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2217
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #71 le: janvier 07, 2024, 09:06:56 pm »
Bon, voici un réseau qui existe vraiment, il est dans un tiroir sous un lit IKEA.
Aucun cantonnement, il est piloté en manuel.
Cordialement

Pierre59

  • Sr. Member
  • ****
  • Messages: 329
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #72 le: janvier 08, 2024, 01:57:21 pm »
@ Dominique

Je pensais à quelque chose comme cela (image ci-dessous), cela ressemble un peu à une petite gare de double voie.

Pierre

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2917
  • 100% Arduino et N
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #73 le: janvier 08, 2024, 02:21:09 pm »
@Pierre,

Oui c’est beaucoup mieux, on reste dans l’esprit du premier Locoduinodrome avec une gare entre les aiguilles, une TJS et une aiguille simple de chaque côté.
Cela permet 2 circulations en parallèle avec échange possible.

Ça fait pas mal de signaux et d’itinéraires possibles.
- 3 zones de gare
- 4 zones d’aiguilles
- 2 ou 4 zones de boucle (avec un sémaphore au milieu).

Je propose qu l’on parte sur ce dessin
Je regarde ce que cela fait avec des rails en N.

Maintenant comment modéliser ce tracé ?
« Modifié: janvier 08, 2024, 02:24:23 pm par Dominique »
Cordialement,
Dominique

Pierre59

  • Sr. Member
  • ****
  • Messages: 329
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #74 le: janvier 08, 2024, 02:48:09 pm »
il y a des travaux préparatoires :
- faire le découpage en zones
- choisir des signaux et leurs implantations
- donner des noms à tout

A titre d'exemple le PRS de Méru, structurellement très semblable. Tout est nommé, zones, signaux, voies, aiguilles, origines, destinations, ...

Pierre