Messages récents

Pages: [1] 2 3 ... 10
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« Dernier message par Pierre59 le Aujourd'hui à 01:51:29 pm »
@ Denis

Citer
Il y a deux types de limitation de vitesse.
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
- Les limites liées à une position déviée d'aiguille.
Les TIV sont surtout utilisés en ligne, même en présence d'aiguilles  (en talon). En présence d'aiguilles en pointe, si la vitesse est limitée à 30 ou 60 on utilise de RR30 ou RR60, sinon un TIV est utilisé. Il y a même des cas ou un RRxx et un TIV sont utilisés pour deux vitesses différentes suivant la position d'aiguilles.
Citer
A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant.
C'est quoi une marche avant ou une marche arrière (par rapport à quoi).

Pierre
2
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« Dernier message par Pierre59 le Aujourd'hui à 12:03:27 pm »
@ Denis

Au sujet de ton premier post.

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

Ce n'est pas toujours possible. Tu parles de la Z46, en fait la Z46 ne comporte qu'une aiguille (a20) et c'est la Z38 comporte l'aiguille a10 et le carré violet, carré violet qui est sur une zone avec aiguille. Juste après un signal il faut un changement de zone pour aubiner le signal, sinon il faut une pédale (ou balise) pour le faire.

Citer
Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.
Les zones Z16 et Z30 sont aussi des zones de manoeuvres, mais ne sont pas en blanc ! en fait ce sont des zones hybrides ligne/manoeuvre.

Concernant les paritées, j'ai abandonné, dans le gestionnaire, les cotés 0/1 ou 1/2 pour des cotés pair/impair, c'est beaucoup plus simple. Et ceci pour toutes les zones. Cela implique aux changements de zone des transitions pair vers impair ou impair vers pair.

Pierre


3
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« Dernier message par DDEFF le Aujourd'hui à 10:25:33 am »
Bonjour,

Aujourd'hui : les itinéraires.

Il existe dans le programme un bouton "Itinéraires" qui donne tous les itinéraires entre un point A et un point B quelconque sur le réseau. C'est anecdotique.
C'est juste pour voir ce que ça donne. Je supprimerai certainement ce bouton par la suite.

En revanche, il y a un autre bouton, le bouton "Analyse", qui, lui, donne 3 tables qu'on peut lire par la suite dans Excel :
_TOUS_ITI____.tsv qui liste tous les itinéraires possibles du réseau
_TOUS_ITI_G__.tsv qui ne liste que ceux des gares
_TOUS_ITI_M__.tsv qui ne liste que ceux concernés par les zones de manœuvres.

Le fait que ce soit sous forme de tables est, là aussi, anecdotique.
Mais c'est utile en phase de développement.
C'est, comme le nom de la variable le dit bien : "littéral", c’est-à-dire lisible par un humain et il faudra qu'on décide ce qu'on garde pour le fichier JSON et sous quelle forme plus compacte.

Comment se calcule un itinéraire ?

Voici un exemple très simple :


 
En bleu, comme précédemment, les signaux, en rouge le "cote0" et, en "non rouge", le "cote1".

Je ne raisonne pas en aiguille à gauche/à droite, mais je considère les "lames" d'un appareil de voie.
Pour l'aiguille en Z5, quand les lames sont à 0 (= "L0"), on est "tout droit", de A à B.
Pour l'aiguille en Z5, quand les lames sont à 1 (= "L1"), on est "dévié", de A à C.
Pour la TJD Z2, quand les lames sont à 0, on va de A à B, en 1, on va de C à D, en 2, on va de A à D et en 3, on va de C à B.
Je n'ai ainsi qu'une seule variable à suivre pour connaitre la position des lames dans n'importe quel appareil de voie.

Evidemment, une section a les "lames" à 0…

Je veux aller de Z1, cote1 vers Z6, cote0.

J'ai 2 procédures dont le nom dit bien ce qu'elles font :
- connecteur_mitoyen(zone, connecteur)
- connecteur_suivant(zone, connecteur)

On démarre par connecteur_mitoyen(Z1, 1).

Les connecteurs d'une zone sont repérés par 2 variables : zone.connecteur[cote][lames]

Donc, on part de Z1.connecteur[1][0] et, en raisonnant sur les voisins, on trouve que le connecteur mitoyen est Z2.connecteur[0][0] (on démarre par lames à 0), c’est-à-dire A.
Puis on passe au connecteur suivant qui est le Z2.connecteur[1][0], c’est-à-dire B.
Connecteur mitoyen = Z3.connecteur[0][0]
Connecteur suivant = Z3.connecteur[1][0] qui est un butoir. Le mitoyen d'un butoir, c'est lui-même et on est dans le sens retour.
Connecteur suivant = Z3.connecteur[0][0] sens retour
Connecteur mitoyen = Z2.connecteur[1][0] sens retour, c’est-à-dire B
Connecteur suivant = Z2.connecteur[0][0] sens retour et comme on a mémorisé la première entrée dans Z2 dans une variable indépendante, on repart dans le sens aller, mais on avance les lames, ce qui fait qu'on repart de Z2.connecteur[0][2], c’est-à-dire A
Connecteur suivant = Z2.connecteur[1][2], c’est-à-dire D
Connecteur mitoyen = Z5.connecteur[2][1], c’est-à-dire C
Connecteur suivant = Z5.connecteur[0][1], c’est-à-dire A
Connecteur mitoyen = Z6.connecteur[1][0]
Connecteur suivant = Z6.connecteur[0][0] qui est le connecteur final.

Le Diable se cachant dans les détails, c'est, évidemment, plus compliqué que ça, mais on a là une bonne idée de ce qui se passe.

Calculer tous les itinéraires d'un réseau :

Avant de se lancer dans des boucles imbriquées, on va calculer combien de recherches d'itinéraires on va avoir.
Le réseau de Dominique comporte 47 zones.
A priori, on a 47 zones x 2 cotes x 47 zones x 2 cotes = 8 836 itinéraires.
C'est beaucoup, mais c'est gérable.
Première simplification : on part et on arrive sur une section. Il y en a 31.
Deuxième simplification : on n'arrive pas sur la même zone que celle du départ.
Donc 31 x 2 x 30 x 2 = 3 720 itinéraires.
On a gagné 60% des tests !
for (Zone zone0 : toutes_zones) {
    //-------------------------------- on balaie toutes les zone0----------------------------------------
    if (zone0.type == 99) {
        //---------------------------- on part obligatoirement d'une section ----------------------------
        for (int cote0 = 0; cote0 < 2; cote0++) {
            //------------------------ on teste les 2 cotés de la zone0 ---------------------------------
            for (Zone zone1 : toutes_zones) {
                //-------------------- on balaie toutes les zone1 ---------------------------------------
                if ( zone1.type == 99) {
                    //---------------- on part obligatoirement d'une section ----------------------------
                    if (zone1 != zone0) {
                        //------------ on ne peut pas avoir zone0 = zone1 -------------------------------
                        for (int cote1 = 0; cote1 < 2; cote1++) {
                           compte_ori_ext++;
                           zone_depart  = zone0;
                           cote_depart  = cote0;
                           zone_arrivee = zone1;
                           recherche_itineraires(zone0.connecteur[cote0][0], zone1.connecteur[cote1][0]);
                        }
                    }
                }
            }
        }
    }
}

Dans la pratique, on n'a que 579 itinéraires possibles et le calcul ne prend qu'une seule seconde. Et on ne fait pas que ça.

Je calcule également les itinéraires des gares, c’est-à-dire que je limite les sections de départ et d'arrivée : on part d'une zone en ap_g0 vers une zone en g0 (champ gare) ou on part de g0 vers so_g0. Et pareil pour g1.
On trouve 18 itinéraires sur 128 testés.

Enfin, on calcule aussi les itinéraires de la zone de manœuvres.
On trouve 30 itinéraires sur 288 testés.

A chaque fois, on obtient une table qui donne, en littéral, les itinéraires trouvés.

Maintenant, je pose deux questions :
- Ai-je bien trouvé tous les itinéraires possibles (surtout en gare et en manœuvres) ?
- Sous quelle forme doit-on les rentrer dans le JSON ?

Une autre question se pose :
A quoi cela peut-il servir de calculer TOUS les itinéraires d'un réseau ?

Cela sert à calculer où on doit implanter des RR (Rappel de Ralentissement) et, par la suite les R (Ralentissement).
On a vu dans mon précédent post que les limites de vitesse sont distinguées en "RR" et "TIV".
Donc, si, dans la liste de l'itinéraire, on a une vitesse "en RR", on remonte dans l'itinéraire jusqu'à arriver sur une section qui aura donc un signal RR.

Remarque :
Cela ne veut pas dire que, dans le même itinéraire, on pourra remonter jusqu'à trouver la section précédente.

Exemple : on est dans l'itinéraire Z25 -> Z28.
Aussi bien dans Z44 que dans Z26 en position déviées, on a une limite à 30 km/h.
Donc, il y a bien un RR affiché dans le signal de Z25.
Mais l'itinéraire n'est pas assez long pour qu'on puisse aller jusqu'à Z22 ou Z23 qui, eux, auront un R qui justifiera du RR en Z25.
Donc, dès qu'on sait que le signal de Z25 peut afficher RR, on sort de la boucle.
Et, à la fin de ces boucles, on a tous les signaux susceptibles d'afficher RR.
Et il faut repartir dans les d'autres boucles pour déterminer les R dans la section précédant la section ayant un RR.
Et c'est là que Z22 et Z23 auront un signal susceptible d'afficher R.

Remarque :
Il existe 2 types de R/RR : le R/RR30 et le R/RR60. Ils se gèrent de la même façon.

Auparavant, on a permis l'affichage de S, A, VL (Sémaphore, Avertissement, Voie Libre) sur tous les signaux. Puis on s'attaque aux C (Carrés).

On a deux types de C :

1°) Le C "d'impossibilité de continuer", lié au fait que les lames des appareils de voie sont dans une position qui ne vous permet pas d'avancer. Exemple : vous arrivez par la voie déviée d'une aiguille et les lames sont en position "tout droit".
Remarque : il existe à la SNCF une possibilité technique de continuer quand même si c'est prévu et que cette aiguille est "talonnable".
Je pense que ce n'est pas une bonne idée en miniature. Il y a déjà tellement de possibilités de dérailler que ce n'est pas la peine d'en rajouter…

2°) Le deuxième type de C est complètement différent : c'est l'aiguilleur qui gère la gare qui l'affiche ou le retire quand toutes les conditions (sécurité, horaires, …) sont remplies.
Exemple : Le train que vous prenez est déjà là, 20 minutes avant le départ. Il y a peu de trafic et e l'itinéraire est déjà "formé". Si le train avançait, il n'y aurait aucune impossibilité technique, toutes les aiguilles étant déjà "en position". Mais il n'est pas l'heure, ou d'autres raison peuvent être évoquées, et l'aiguilleur fait afficher le C au signal devant le train.
Quand il le décidera, il éteindra le C et le train pourra partir.

Remarque : (on l'a déjà dit dans un précédent post) un signal de gare gérée par itinéraires n'affiche pas le S. Donc, quand je donnerai à toutes les voies de gare la possibilité d'afficher le C, il faudra effacer le S. Cela vaut aussi pour les zones d'approche.

Signaux de manœuvres :

Il n'y a qu'un signal de manœuvre : le Cv (Carré Violet). C'est le seul qui ne soit pas un signal de cantonnement.

Dans la pratique, il y a moins de signaux que sur les voies principales car les trais roulent "à vue", à 15 km/h maxi.
Ils sont indispensables aux frontières zone de manœuvre/voies principales et pour les zones d'approche de la zone de manœuvre. Après, les règles sont floues…

Signaux au-dessus des butoirs :

Il s'agit obligatoirement de carrés ayant la particularité de n'avoir qu'un feu, au milieu du butoir.
En zone de manœuvre, ce sont des Cv (et donc violets) (Z18, Z19, Z20 et Z21) et des C (et donc rouges) sur voies principales (Z40 et Z41)


Voilà donc comment, en appuyant simplement sur le bouton "Analyse", on calcule tous les itinéraires et les signaux d'un réseau. Le tout en une seconde chrono !

Denis  :P
4
Vos projets / Re : ampoules "ballast"
« Dernier message par Dominique le Aujourd'hui à 02:04:06 am »
A mon avis, le plus simple et efficace est d’utiliser une alimentation 20v 4/5A protégée contre les court-circuits comme celle-ci :
https://amzn.eu/d/6IlonQU
5
Vos projets / ampoules "ballast"
« Dernier message par ElGringo le mai 22, 2024, 11:33:34 pm »
Bonjour, j'aimerais protéger mon installation des courts circuits. Je fais rouler les trains LGB (3loco, qlq signalisations et aiguilles). Le circuit consomme en moyenne 3A et le courant est 20v. A votre avis quel type d'ampoule (connectée entre les rails et la centrale)  je peux prendre pour me protéger des courts circuits. J'ai vu que les ampoules 12V21W étaient la norme. Cependant dans mon cas il s'agit des train LGB. Merci
6
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Dernier message par Brunotoutsimple le mai 22, 2024, 08:30:38 pm »
Bonsoir Laurent

Je pense que j'ai trouvé l'erreur qui expliquerait pourquoi les leds ont un fonctionnement dysfonctionnel. Comme je l'ai déjà dit je suis pas du tout expert en électronique, mais je suis quelqu'un qui observe et qui cherche beaucoup à comprendre. En regardant de prêt le schéma de "Block Occupancy Detector For DCC" de "Rpaisley" https://web.archive.org/web/20140825051230/http://home.cogeco.ca/~rpaisley4/DccBODvt5.html et j'ai observé ceci dont j'ai tracé sur le schéma ci-joint en orange.

Quand on regarde les sorties, les deux leds sont bien sur les sorties "OUT" du NE556 mais les sorties pour le microcontrôleur sont sur les sorties "DISCH" du NE556.
Donc en faisant le parallèle, j'ai appliqué ceci au NE555.
J'ai changer la porte par un inverseur de Schmitt "74AHC1G14SE-7" https://www.digikey.fr/fr/products/detail/diodes-incorporated/74AHC1G14SE-7/2639248

J'ai utilisé pour simuler ce schéma, un petit programme sur internet dont voici le lien:https://lushprojects.com/circuitjs/circuitjs.html.
Vous trouverez aussi ci-joint le schémas de simulations ainsi que le fichier de cette simulation.
il suffit d'ouvrir le fichier "Détecteur-simulation.txt" et d'appuyer sur le poussoir sur le schéma pour voir la magie s'opérer.  ;D
7
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« Dernier message par laurentr le mai 22, 2024, 05:17:28 pm »
Bonjour

Comme je l'ai explique sur le post de présentation des fonctionnalités des AVR avec les librairies DXCORE MEGATINYCORE et MEGACOREX, je poursuis les tests en vue de la mise en œuvre.

Quelques corrections de syntaxes ont été rendues nécessaires.

Quelques tests aussi ont montré une impossibilité de combiner certains éléments (sortie PA7 du CCL0 (LUT0) sur un ATTINY826. Pas de raison identifiée. Elle est cependant opérationnelle sur un autre bloc.

Ces tests très utiles sont la pour bien vérifier le bon comportement comme attendu.

A suivre donc...
8
Bonjour

Malgré un emploi du temps pro bien chargé les tests se poursuivent.

J ai d abord des corrections à apporter dans les exemples fournis sur la partie EVENT.

Il faut en effet utiliser set_generator() en lieu et place de assign_generator() dans la syntaxe fournie


#include "Event.h"

void INIT_EVENT()
{
  //Event0.set_generator(gen0::pin_pa1); // OK BUT USE NEXT LINE FOR BETTER EFFCIENTCY
  Event0.set_generator(PIN_PA1); //BETTER & FASTER
  Event0.set_user(user::ccl2_event_a);          //EVENT A OF LUT2

  Event0.start();

  Event1.set_generator(gen::ccl2_out);
  //Event1.set_user_pin(user::evouta_pin_pa2); //route on PA2
  //Event1.set_user_pin(user::evouta_pin_pa7); //route on PA7
  Event1.set_user_pin(PIN_PA7); //route on PA7

  Event1.start();
 
}




Il est recommandé lorsque cela est possible de "passer en dur" certains éléments comme les broches d'entrée ou de sortie. ( on peut mettre des alias si besoin de portabilité et des simplifications de modifications en volume)( sinon se tourner vers assign_generator() (se rapporter aux notices des librairies)

Les tests se poursuivent.

Notez que lors de mes tests sur un ATTINY826 je ne suis pas parvenu à utiliser la sortie "MUX" vers PA7 du bloc CCL0 ( LUT0). BUG? 
Attention peu de PIN sont utilisables pour ces usages. (PORTx PIN 2 et PIN 7 si présentes!)
(voir datahseet du composant)

De plus si vous utiliser 1 sortie EVENOUTx c est exclusif sur le port en question, vous ne pouvez pas utiliser la pin alternative sur un autre event. ( en gros c est dessert OU fromage MAIS PAS LES DEUX!)
Donc vigilance dans les usages d'attribution!!

Il est donc prudent de tester unitairement aussi chaque élément!...


9
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Dernier message par Brunotoutsimple le mai 22, 2024, 01:13:25 pm »
Merci, je sais mon schéma est faut c'était pour montrer à quoi je pensais
10
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Dernier message par laurentr le mai 22, 2024, 01:08:02 pm »
Attention dans le cas d usage du CPU vs le NE55X je ne suis pas certain de ton schéma

Voici la version de travail de laquelle j étais partie.( et qu il faut éprouver et reprendre au besoin)

Ltr

Pages: [1] 2 3 ... 10