LOCODUINO
Discussions Générales => Les réseaux => Discussion démarrée par: Bug Killer 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 (http://jmdubois.free.fr/dcc/index.html)). 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 (https://www.locoduino.org/spip.php?article154).
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.
-
Bienvenue Sur Locoduino,
C'est un grand projet donc beaucoup de techniques à déployer et faire fonctionner ensemble : ça va être interessant ;D
Bien amicalement
Dominique
-
Bonjour
Très très joli réseau. Je me permet de faire quelques remarques.
En général on ne met pas de signaux dans les dépots, les zones marchandises, les grils …
On est pas obligé de mettre des signaux partout, des petites gares peuvent être, comme en réalité, sans signalisation.
Les signaux avec blanc clignotant sont assez rares en réalité, assez courants avec le blanc fixe.
Le problème des "sens" est souvent assez délicat à gérer. Sur le réseau on a deux plaques tournantes et un retournement si je ne m'abuse. Cela nécessite des "changements" de sens pour les trains.
En général on donne un sens aux voies, pair ou impair habituellement, surtout en double voie. Certaines voie peuvent être parcourues dans les deux sens : zones d'aiguillages, voies uniques, voies des dépots, … Pour ces voies on peut donner un sens arbitraire, en cohérence avec les voies avoisinantes.
Le problème vient avec les trains, en voie double le train a le sens de la voie, ailleurs il peut changer.
Un train qui fait un retournement à Calais ou à Paris arrive avec un sens pair ou impair, mais repart avec un sens inversé (impair ou pair), mais le sens DCC ne change pas (cela doit être aussi vrai pour les plaques tournantes), pour un train on a donc besoin de deux sens : le sens réseau (pair/impair) et le sens DCC (avant/arrière). Une paire de booléens permet de gérer cela. On n'a besoin de mettre jour à ces booléens que dans deux cas : quand on inverse se sens de circulation du train par une commande sur la souris, quand on a un retournement de voie, une raquette ou un retournement sur un pont tournant. Le passage Z5/Z6 (et les autres) se fait alors tout seul, sans rien faire.
Cordialement
Pierre
Calais ou Paris
-
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.
-
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.
-
Bonjour
Ce serait peut être plus simple de mettre toutes les voies d'Abbeville dans le même sens et de faire l'inversion de polarité dans les deux retournements Paris et Calais.
Cordialement
Pierre
-
Ben c'est ce que j'ai dit.
-
Désolé j'ai lu trop vite
Pierre
-
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 ?
-
Quand on ouvre un carré même sans bal il faut l'état du signal suivant pour savoir si on l'ouvre à Vl ou A.
Quand on change les feux d'un carré il faut prévenir le précédent pour qu'il mette à jour ses feux.
Cela se complique un peu si le signal peut présenter le R ou le RR. De plus les suivants et précédents dépendent de la position des aiguilles.
Pierre
-
Il y a aussi une règle en développement : l'absence de retour d'une fonction est inutile, alors que retourner une information, même très faiblement utile, a une chance de servir à quelque chose... Par exemple, une fonction fait généralement quelque chose (sinon c'est la fonction elle même qui est inutile !), on peut juste retourner un booléen qui signalera si la chose a été faite, ou si l'on s'est trouvé dans un cas qui empêchait de faire le travail, ou l'ancieene valeur d'un objet mis à jour par la fonction, etc...
-
@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.
-
Dans le cas des Cv les méthodes précèdent et suivant ne servent pas.
Pierre
-
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.
-
Encore une question. Soit la configuration de voie suivante :
S1 S2
-------------------------
\
\----------------- Z3
La fonction precedent() de l'objet S2 doit-elle renvoyer S1 ou nullptr quand l'aiguille mène à droite vers Z3 ?
-
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.
Je ne suis pas certain que "gauche" et "droite" soit moins ambiguë que "droite" et déviée" pour une aiguille car "tout droit" peut-être sans ralentissement et "déviée" peut-être à gauche ou à droite mais avec ralentissement : dans ce cas spécifique, la programmation du comportementd'un train n'est pas simple en testant l'état de l'aiguille !!
Mais pour une TJS ou TJD c'est plus concevable peut-être.
-
Je vais juste citer la réponse que j'ai eu d'un cheminot ayant travaillé dans la filière Transport-Mouvement de la SNCF :
"Ce qui importe est la position de l'aiguille. Sur la photo ci-dessus, l'aiguillage comporte une voie directe à gauche, une déviée à droite.
La direction que donne l'aiguille est TOUJOURS déterminée en partant de la pointe, ce qui est très logique. On dit que l'aiguille est "à gauche", lorsqu'elle donne la direction de gauche, "à droite" lorsqu'elle donne la direction de droite, bien sûr.
Ceci résout, en particulier, le cas des aiguillages symétriques aux branches courbes, du même rayon ou pas.
La notion d'aiguille "à gauche" ou "à droite" est utilisée réglementairement dans toutes les fonctions concernées. Elle va être essentielle pour toute commande d'aiguille, par levier ou motorisée, et pour tout montage de parcours, enclenchements, position des signaux, ..., bref la commande binaire du oui -non, ou (+) - (-)."
-
Bonjour
Le gestionnaire de l'article est une version simplifiée qui ne prend pas en compte les voies de service ni les manoeuvres (pas de gestion du feu manoeuvre (blanc) dans les signaux).
Normalement pour passer à une voie de service il doit y avoir un carré (sans BAL) pouvant présenter le feu de manoeuvre (blanc).
La méthode cantonOccupe() a un résultat booléen, elle ne sert que quand on ouvre un signal de BAL pour savoir s'il faut le mettre au sémaphore ou pas.
Dans l'état actuel si suivant() ou precedent() retournent null c'est une erreur d'exécutuion. C'est une précaution pour éviter les oublis, mais cela peut être changé.
J'ai beaucoup de mal à répondre aux questions, sans savoir quel est le type du signal concerné (et les feux) ainsi que son insertion dans le réseau.
Cela serait bien d'avoir un "dessin" complet du réseau (avec les signaux (avec feux si possible) et des repères : noms de zones, d'aiguilles, signaux, …), cela permettrai d'avoir des réponses beaucoup plus pertinentes aux questions.
Cordialement
Pierre
-
Le plan complet est annexé au premier message du fil. Depuis ma question j'ai vu dans le code où se trouve les rejets de pointeurs nuls quand il n'y a pas de signal suivant ou précédent.
-
Après avoir cuisiné le modèle de Pierre59 à ma sauce, j'ai pu modéliser entièrement mon futur réseau qui, après évolution, comprend 62 blocs, 86 zones de détection, 37 appareils de voie, 2 boucles de retournement, 2 plaques tournantes, 86 itinéraires, permanents ou à destruction automatique, et 61 signaux dont 27 virtuels qui ne servent qu'à la régulation. Le mode simulation de mon logiciel m'a permis de vérifier le bon fonctionnement. Tout marche, le BAL, le BMVU, l'accès aux zones de service avec affichage du feu de manœuvre, le retournement d'une loco sur une plaque, etc.
Merci encore à Pierre pour ses travaux car je n'aurais pas eu l'idée par moi-même d'utiliser un objet dérivé par élément.
-
Bonjour
Très très belle réalisation, on aimerais en savoir un peu plus.
Pierre59
-
En fait, j'avais déjà un programme qui fonctionnait sur un petit réseau mais très difficile à appliquer à un gros. J'ai combiné ta méthode basée sur les objets avec mes propres développements : cantons multi-zones, présence simultanée de 2 trains par zone (si, si, ça marche avec un algorithme trapu de suivi des trains). Je n'ai pas réussi du premier coup et j'ai failli abandonner. Je suis donc reparti de presque zéro en implémentant les objets un par un tout en les adaptant à mes objectifs. Je publierai le code dès que je le trouverai suffisamment stable.
-
Bonjour,
J'ai hâte aussi d'en savoir plus notamment sur le suivi des trains.
J'utilise aussi les objets de Pierre59, prêt aussi à partager.
Bon courage
Dominique
-
Je peux actuellement publier le projet pour Eclipse et Code::Blocks sous Linux. Il vous faudra fabriquer et installer wxWIdgets-3.1.4 et wxSQLite3 4.6.9. ça vous va ?
-
Une version C/C++ est-elle envisagée ?
-
Le projet est entièrement en C/C++. Le passage à Windows avec VS2019 est en cours.
-
Je suis sur Mac !
-
Comme le projet est développé avec wxWidgets, normalement ça fonctionne aussi mais je n'ai pas testé car je n'ai pas de machine sous macOS. Plus de renseignements ici : https://www.wxwidgets.org/docs/faq/osx/
-
Eclipse aussi est disponible pour macOS https://www.eclipse.org/downloads/packages/
Installer et exécuter Eclipse Installer puis installer Eclipse CDT.
-
Okay, je ne cherche pas à compiler et exécuter ton développement mais seulement comprendre comment fonctionne le suivi et l’espacement des trains.
Je peux essayer de lire et comprendre les fichiers sources sur Mac, même sans installer Éclipse et wxWidget, surtout s’ils sont commentés.
Car on n’a pas exactement le même réseau et les même capteurs.
Merci d’avance
Dominique
-
J'ai extrait du code les fichiers les plus impliqués dans la gestion de la circulation. Ils sont dispos ici (http://jmdubois.free.fr/dcc/CentraleD17_extraits.zip).
-
Merci beaucoup,
J’ai suivi le projet D17 il y a un certain temps, bravo, quel boulot :D
Il y a beaucoup de fonctions intéressantes que je vais regarder progressivement. Je te demanderai ensuite comment ces fonctions sont appelées à partir des détections.
Dans mon réseau, le parsing des messages Can fait l’appel à toutes les fonctions de suivi et régulation. J’essaye de faire simple et c’est pas évident !
-
CentraleD17 est beaucoup plus complexe que SourisD17, la première version de mon projet. Mon cahier des charges était :
- toutes les communications en TCP/IP.
- échanges avec la centrale à base de Wemos D1 mini réduits au strict minimum.
- plusieurs stations gèrent le réseau en simultané.
- les stations affichent des informations synchronisées.
Les stations ne se connectent donc pas au Wemos mais à CentraleD17 qui gère les flux de données entre la centrale, le système de contrôle-régulation et les clients. Il y a 6 modules :
1. Le client interface avec D17 (ClientD17). Protocole à modifier pour s'adapter à une autre centrale.
2. Le serveur de flux ServeurD17. Protocole à modifier pour s'adapter à une autre centrale.
3. Le contrôleur-régulateur
4. Le client interface avec ServeurD17.
5. Le gestionnaire de TCO
6. Le(s) gestionnaire(s) d'interface de conduite. Actuellement 14 "souris". En préparation 4 "cabines".
Tous ces modules sont dans CentraleD17 ainsi que la gestion de la base de données d'état du réseau. CommandeD17 comprend 4, 5 et 6. ConduiteD17 4 et 6. CommandeD17 et ConduiteD17 n'agissent donc pas directement sur la centrale mais envoient des requêtes à CentraleD17. Son module de contrôle-régulation vérifie si elles sont exécutables. Lorsqu'elles le sont, il envoie des requêtes au Wemos et le résultat aux stations concernées.
Exemple : sur un ordinateur exécutant CommandeD17 l'utilisateur clique sur le bouton de construction d'un itinéraire. Localement, CommandeD17 n'a aucune idée de la faisabilité de la construction. Cette requête est envoyée à CentraleD17 qui vérifie si elle est exécutable. Si elle l'est, les appareils de voie et les signaux sont manœuvrés par une requête envoyée au Wemos et les blocs concernés sont marqués. Le changement d'état des ADV et l'état "construit" est envoyé aux stations exécutant le module 5. Le changement d'état des signaux est envoyé aux ordinateurs qui exécutent les modules 5 et 6. Si la requête n'est pas exécutable immédiatement, l'itinéraire est "en attente de construction". Cet état est envoyé aux stations exécutant le module 5.
La centrale ne retourne que très peu d'informations :
- état de l'arrêt d'urgence car un bouton matériel est présent sur son boîtier
- niveau de consommation de courant
- état des détecteurs, 96 bits, nombre ajustable
- état des ADV, 48 bits, nombre ajustable, une fois pour ceux à gauche, une fois pour ceux à droite
- état des variables utilisateur, 96 bits, nombre ajustable
- résultat de la lecture d'un CV
- résultat de l'écriture d'un CV
- résultat de la comparaison d'un CV
ServeurD17 interroge l'état du Wemos à chaque fois qu'il envoie un paquet de requêtes ou au bout de 125ms sans requête.
Actuellement, il n'y a pas de gestion centralisée des fichiers contenant les profils des engins moteurs et la description des TCO. Ces fichiers texte doivent être présent à l'identique sur tous les ordinateurs.
-
Effectivement c'est énorme et curieusement la doc de la sourisD17 fait... 17 pages !
J'ai une approche différente de la gestion de mon réseau, voir ici (https://forum.locoduino.org/index.php?topic=290.0).
J'interconnecte sur un même bus CAN :
- une centrale DCCpp à commandes manuelles par 12 potentiomètres (récupérés sur une table de mixage) qui permet donc le pilotage manuel de 12 trains (dont un parametrable). Chaque train peut être configuré (adresse, crans aux vitesses caractéristiques 15, 30 60, 90, sens inverse ou non, cran max, etc..) La centrale peut-être pilotée via Can (DCC on/off, mesure de courant, commande de chaque machine et les commandes de conduite sont envoyées sur le Can vers le gestionnaire, ainsi que les DCC on/off.
- une carte de commandes des aiguilles à bobine, par messages Can émis par le gestionnaire avec retour de messages d'état des aiguilles ou interrogation
- une carte TCO qui représente le dessin du réseau avec un voyant d'occupation par zone, un inverseur pour positionner les aiguilles et 2 leds de position pour chaque aiguille. Cette carte est connectée aux détecteurs d'occupation et c'est elle qui envoie les messages d'occupation au gestionnaire
- quelques satellites V1 adaptés pour des détections RFID (4 pour le moment de chaque coté de la gare principale, pour récupérer les numéros des trains qui passent à ces endroits) et des détections ponctuelles genre zone d'arrêt devant les signaux (j'en ai mis 4 dans la gare principale et 4 dans la gare cachée pour le moment). Ces satellites envoient des messages Can pour les détections et reçoivent des commandes de signaux
- Une centrale de va et vient qui peut fonctionner de façon autonome
- Une centrale de configuration de CVs qui, pour le moment est autonome
- Un gestionnaire de réseau comprenant un Arduino Due, une interface CAN et un écran graphique et tactile 5 pouces (bientôt 7 pouces). C'est lui qui doit assurer le suivi, la régulation, l'affichage sur son propre écran et permettre un certain nombre de commandes de scenarii de circulation
- J'ai prévu d'ajouter plus tard des commandes du gestionnaire et de la centrale avec une passerelle Wi-Fi- Can
Ce projet se veut de rester simple (si on peut dire !) sans PC ni tablette (jusqu'au moment ou la passerelle WiFI-Can existera, bien que je n'envisage pas de développer de soft sur PC/Tablette.
Donc le fonctionnement général s'articule autour de la messagerie Can, avec un identifiant par type d'événement. Le gestionnaire est basé sur celui de Pierre59 : tous les objets zone, aiguilles, signaux, itinéraires et trains sont adaptés pour mon réseau et un "double" graphique réprésente chaque objet sur l'écran, ce qui permet une mise au point facile et pratique.
Il y a donc dans la loop du gestionnaire un Parser qui analyse chaque message Can et fait ce qu'il y a à faire.
Je n'ai pas fini de développer le suivi et la régulation pour tous les trains, en m'attachant d'abord de ne traiter que les trains automatiques (avec des horaires) et en laissant les manoeuvres en manuel (ce qui peut arrêter un train automatique pendant une manoeuvre).
Pierre59 constatera que je n'avance pas vite, mais je fais durer le plaisir :D ;D
Et je pense que ton projet va m'aider à avancer et à découvrir ce que j'ai oublié. Cependant je fais des hypothèses simplificatrices qui vont probablement poser problème dans des cas particuliers, mais j'adapterai en conséquence.
En tout cas merci pour ton partage.
-
SourisD17 est un programme simple qui confie toute la régulation au croquis embarqué dans le Wemos. Le contrôleur à écrire n'utilise pas d'objets, seulement des évènements à traiter dans des fonctions. Il convient bien à un petit réseau avec un seul poste de commande et une ou deux souris sous Android. La mise au point du contrôle et de la régulation est très difficile car tout se passe dans le Wemos.
CentraleD17 et ses satellites sont plus complexes mais, avec le simulateur intégré, la mise au point est facile. Je déplace les trains pas à pas et j'examine ce qui se passe avec les outils de mise au point de l'IDE. L'utilisation des objets dérivés de ceux de Pierre59 permet de traiter chaque cas complexe isolément et, pour les cas simples, sans voies de service, son BAL fonctionne tout seul.
J'envisage d'utiliser un Raspberry Pi 400 avec un écran tactile pour faire tourner au moins un des postes de commande. Pour le fun.
-
J'ai extrait du code les fichiers les plus impliqués dans la gestion de la circulation. Ils sont dispos ici (http://jmdubois.free.fr/dcc/CentraleD17_extraits.zip).
En effet c'est trapu !
Le plus difficile ce sont les occupations (comment retrouver l'adresse DCC du train qui entre ou qui sort) et les libérations.
De mon coté, je note dans chaque train les enchainements de zones concernées par le train, partant qu'un train tient en entier dans une zone : la zone prévue (la suivante c+1 dans le sens de la marche), la courante (c), la précédente (c-1 - en général occupée en même temps que la courante c et qui impose un arrêt d'un train suiveur), la c-2 qui impose un ralentissement et la c-3 qui peut être libérée. Avec ce principe je n'ai plus besoin de traiter les libérations, sauf en cas de perte de wagon si les essieux sont graphités. Un train prévu est écrit dans c+1 pour le reconnaitre rapidement. Et dans c aussi pour les cas de détections multiples.
En cas de perte de train, je me sers des messages de traction qui me disent qu'un train roule donc va provoquer une détection de présence en arrivant dans une zone : l'événement d'occupation qui suit est pour lui en général, à condition qu'il n'y ait qu'un seul train qui roule à la fois. C'est un moyen de localiser les trains posés ou arrêtés n'importe où au démarrage et ça peut s'automatiser en pilotant les trains un par un par le gestionnaire. Et en plus le RFID recale les trains automatiquement au passage. Il n'y a pas besoin d'en mettre partout, ni du Railcom (que je n'ai pas).
C'est la partie la plus interessante et la plus compliquée du développement, avec beaucoup de sorties moniteur pour comprendre ce qu'il se passe (d'où le choix du Due qui encaisse bien, mais plante facilement en cas de pointeur erroné).
Avec la possibilité de 2 trains par zone, tu t'es bien compliqué la vie.
-
Si un train doit toujours tenir en entier dans un canton, il ne peut pas toujours tenir entièrement dans une zone. A l'entrée ou la sortie de ma gare principale, un train peut occuper jusqu'à 6 zones consécutives dont la liste varie en fonction de la direction des appareils de voie. Il peut être à cheval sur une zone de BAL (ralentissement ou arrêt), une zone d'ADV et une zone de service. Ce n'est cependant pas le plus compliqué à gérer. Ce qui a beaucoup compliqué, c'est ma fixette sur la possibilité de scinder et joindre deux trains dans une zone.
-
J'ai modifié les objets pour obtenir un affichage des signaux dans les postes de conduite plus réaliste. Désormais, au lieu d'afficher le signal de sortie de bloc dès que le train entre dedans, il n'est affiché que lorsqu'il entre dans la dernière zone avant la sortie. J'ai mis à jour les fichiers disponibles ici (http://jmdubois.free.fr/dcc/CentraleD17_extraits.zip). J'ai inclus les objets de mon projet de réseau avec le code des boucles de retournement et des tables tournantes.
-
Améliorations et corrections (http://jmdubois.free.fr/dcc/CentraleD17_extraits.zip), notamment du traitement de la séparation de deux trains dont l'un quitte la zone en circulant en sens impair.
-
C’est un très beau développement et on comprend bien la définition du réseau en lisant le fichier SchemaBK.h où se trouvent tous les objets dérivés.
Le simulateur pour la mise au point est une excellente idée.
Merci pour ce partage. Je m’en inspire ;D
-
Depuis la publication précédente j'ai ajouté l'affichage d'une cabine et celui des pancartes et tableaux, une seule pancarte ou tableau par cabine ou mini cabine de conduite.
-
C’est splendide ;D
Il ne manque plus que la caméra à l’avant de la loco et l’image à droite du panneau !! 😜
Ca va me pousser a ajouter des postes de conduite sur le bus Can. J’y pense en version individuelle (et sans caméra car en N c’est dur).