Messages

16

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: novembre 02, 2020, 06:56:07 pm »

Encore une question. Soit la configuration de voie suivante :

Code: [Sélectionner]

S1                     S2
-------------------------
          \
           \----------------- Z3

La fonction precedent() de l'objet S2 doit-elle renvoyer S1 ou nullptr quand l'aiguille mène à droite vers Z3 ?

17

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: novembre 02, 2020, 05:20:43 pm »

2 questions :

Que doit retourner la méthode CantonOccupe lorsque la prochaine zone ne fait pas partie d'un canton de BAL mais est une voie de service ou une voie de manoeuvre ?

Lorsque la position d'une aiguille prise en talon ne permet pas d'accéder au prochain canton, faut-il quand même renvoyer son état, forcer à true ou forcer à false ou est-ce sans importance ?

Un commentaire :

Ayant un souci de compréhension de ce que représente "directe" et "déviée" dans le cas d'un TJD, d'une TJS ou d'un aiguille symétrique, j'ai posé la question sur un autre forum et j'ai appris que ce n'est pas ainsi qu'on indique la direction à la SNCF. On y utilise "gauche" et "droite", ce qui est sans ambigüité. Je me suis permis de modifier les noms des méthodes en conséquence.

18

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: octobre 31, 2020, 03:20:00 pm »

@Pierre59 : pigé !

@Thierry : ici il s'agissait de savoir s'il était utile de créer des méthodes renvoyant un résultat non nul mais inutilisé (ce qui n'est pas un cas normal) dans un objet dérivé alors qu'il existe une méthode par défaut renvoyant un pointeur nul dans la classe de base.

Ce sont mes enchaînements de carrés violets logiques (sans signal physique) qui m'ont fait me poser cette question. A priori, l'état de ces Cv ne dépend pas des signaux voisins, uniquement de l'orientation des aiguilles, mais ça ne m'a pas coûté cher en temps d'écrire leurs méthodes.

19

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: octobre 31, 2020, 12:01:47 pm »

Dans les méthodes suivant() et precedent() de la classe Signal, est-il utile de renvoyer le pointeur du signal suivant ou précédent si celui-ci est un carré sans BAL ?

20

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: octobre 31, 2020, 10:18:40 am »

Ben c'est ce que j'ai dit.

21

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: octobre 31, 2020, 09:27:56 am »

La remarque de Pierre sur la boucle de retournement m'a titillé. Je pensais qu'il n'y en avait pas, or, il y en a deux. Je vais donc considérer que toutes les voies de la gare d'Abbeville sont dans le sens pair depuis Paris (à gauche) vers Calais (à droite). Les sections de changement de polarisation et de sens de circulation seront les Z42 et Z43 côté Calais, Z58 et Z59 côté Paris.

Merci Pierre.

22

Les réseaux / Re : Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: octobre 30, 2020, 03:45:54 pm »

Je vais essayer d'ajouter à ton gestionnaire quelques fonctions originales du mien :

- scission d'un train
- jonction de 2 trains
- régulation automatique de la vitesse en fonction d'un paramètre de chaque zone
- franchissement de signal fermé en "marche à vue" à une vitesse maxi de 15 km/h

Les deux 1ères fonctions nécessitent de pouvoir avoir 2 trains dans la même zone, repérés par le côté de la zone qu'ils occupent.
 
Les signaux qui n'ont pas de cible sur le plan ne sont là que pour la sécurité des manoeuvres, en cas de fausse manip ou d'oubli d'activation de marche à vue. Certains pourraient être supprimés si je testais l'occupation de la zone au lieu de l'état du signal qui en découle mais, dans mon gestionnaire actuel, les autorisations d'accès à la zone suivante et le ralentissement des trains sont basés sur la signalisation logique qui découle de l'occupation des zones et de la position des aiguilles. Les autorisations ne sont recalculées que s'il y a eu des changements. La régulation de marche des trains qui intervient toutes les 125ms n'a ainsi besoin de prendre en considération que :

- l'état du signal suivant
- la vitesse maxi autorisée sur la zone
- la vitesse et le sens indiqués par le poste de conduite.

Comme je vais migrer tous ces algorithmes dans le logiciel sur PC, le traitement sera plus rapide et je pourrais peut-être refaire les calculs d'autorisation à chaque itération.

Ce n'est pas très visible mais sur le plan le sens pair est indiqué par les flèches superposées aux sections de rail et aux aiguilles. Il n'y a pas de boucle de retournement (c'est un double ovale replié en os de chien et une voie unique) mais en plus des plaques tournantes, il y a deux endroits, entre la zone 5 et la zone 6, ainsi qu'entre les zones 39 et 40, où le sens de marche réseau doit être inversé. C'est dû à la 4ème voie à quai et à la voie de service qui peuvent être parcourues dans les deux sens et cisaillent la voie 3. J'ai mis un zoom sur ces zones en pièce jointe.

23

Les réseaux / Projet d'utilisation du gestionnaire en C++ de Pierre59

« le: octobre 30, 2020, 12:33:35 pm »

J'ai mis en pièce jointe le réseau que je vais construire.

Pour les quelques tests que j'ai effectués sur un ovale avec une voie de garage, j'ai utilisé la centrale économique D17, un BAL embarqué dans la centrale et SourisD17, la partie commande dans un PC sous Windows, Linux ou OS-X (détails ici). Pour le réseau grand modèle, je ne vais conserver dans le croquis de la centrale que les interfaces matérielles et, bien sûr, la génération du signal DCC. Toute la partie gestion va passer sur le(s) PC. Pour cette partie, j'envisage d'utiliser le gestionnaire en C++ de Pierre59. 

J'ai déjà vu qu'il faut que je crée un autre type de signal abondamment utilisé dans le projet (carré - BAL + blanc clignotant) et que je dois voir comment inverser le sens logique de marche des trains quand ils passent de la zone 5 à la 6, de la 39 à la 40 et vice-versa.

A suivre, si vous le voulez bien.

24

Présentez vous ! / Bonjour

« le: octobre 09, 2018, 12:19:47 pm »

Je débute en modélisme ferroviaire et en Arduino. J'ai monté une petite centrale DCC, des décodeurs d'accessoires, un module S88 et des détecteurs d'occupation en me basant sur des travaux publiés sur le net. Elle me sert à expérimenter différentes solutions en attendant la construction d'un vrai réseau.

25

Infos et bonnes affaires / Re : DHgate

« le: octobre 08, 2018, 06:32:39 pm »

La standardisation (ISO 11784 et 11785) a été tardive en 125 kHz ou 134.2 kHz. Il existe plusieurs modèles de puces incompatibles entre elles. Certaines ne peuvent être que lues (EM4100, EM4005, TK5530, etc.), d'autres peuvent être écrites et lues (EM4205, EM4150, Hitag1, Hitag2, Hitag S256, T5557, ATA5577, etc.). Enfin, certaines peuvent émuler une EM4100 (Hitag2, Hitag S256, T5557). Il faut donc savoir avec quelle(s) puce(s) est compatible le lecteur ou le lecteur-encodeur.

En 13.56 Mhz, il existe trois standards principaux,  : ISO 14443A (Mifare, ec.) , ISO 15693 (ICode, Tag-It) et le standard NFC ISO 18092 (Topaz, NTAG, Felica). Certaines puces sont compatibles à la fois avec ISO 14443A et ISO 18092. Là aussi, il faut savoir avec qulle(s) puce(s) est compatible le lecteur encodeur.