Passage à niveau 2 voies double sens

[chris_bzg]

Le plus simple serait de voir s'il est possible de faire deux sections de voie, l'une allant de A à A sur le plan et l'autre allant de B à B. Vous n'utiliseriez que 2 détecteurs d'occupation au lieu de 4 et vous bénéficieriez des avantages de ce système. Le PN serait complètement protégé dès que votre matériel consomme (éclairage ou graphitage des essieux). Et le programme est plus facile à écrire.

Sinon, l'autre solution est de traiter ces détecteurs comme les ILS et modifier le programme initial, notamment les ISR (je peux vous proposer une solution qui a l'air de fonctionner, mais qui serait à tester en réel).

A vous de voir la solution la moins contraignante pour vous. Si j'ai d'autres idées, je vous en ferai part.

[chris_bzg]

Suite à ces discussions, je viens de faire une mise à jour de l'article "Passage à niveau géré par Arduino (5)" (https://locoduino.org/spip.php?article265)  concernant l'emploi de détecteurs d'occupation par consommation de courant.

[Pilou3837]

Bonjour,
J'ai tenter de prendre en compte vos reflexions et j'ai finalement utilisé une variable etatZonePN, pour pouvoir rebasculer sur votre code originel.

Ca donne ca :

 if(digitalRead(CaptA)==LOW) {
    etatZone_A = false;
    }
  else etatZone_A = true;
 
  if(digitalRead(CaptB)==LOW) {
    etatZone_B = false;
    }
  else etatZone_B = true;
 
if  ((etatZone_A== false) && (etatZone_B== false)){ //condition si aucun train sur zone A et B equivalent à zone PN libre
  (etatZonePN==false);
    }
if ((etatZone_A == true) || (etatZone_B == true)) { //condition si au moins un train sur zone A et zone B equivalent à zone PN occupée
   (etatZonePN==true);
    }
if(etatZonePN == false) {
    old_etatZonePN = etatZonePN;
    digitalWrite (LED_BUILTIN, LOW); // eteint LED de controle de la zone PN
   
  } 
  if(etatZonePN == true) {
    if(etatZonePN != old_etatZonePN) {
      old_etatZonePN = etatZonePN;
     
    } 
  digitalWrite (LED_BUILTIN, HIGH);

[chris_bzg]

C'est quelque chose comme cela, sauf que les entrées sont initialisées en INPUT_PULLUP, donc leur état normal est HIGH. Lorsqu'il détecte, le capteur devrait envoyer un sugnal LOW pour que ça fonctionne.

Si le capteur ne peut envoyer qu'un signal HIGH (limité à 5V), il faut initialiser en INPUT les entrées.

Voici un ZIP pour une solution avec détecteurs envoyant un LOW. Essayez la sur votre réseau et observez la LED_BUILTIN et le moniteur.

[Pilou3837]

Christian,

Merci pour le retour rapide.
Je vais testé la nouvelle version sur mon reseau .

Suite à tes remarques sur le nombre de detecteurs, determiner une Zone de consomation complete Voie A ou Voie B avec 2 capteurs, ou 4 capteurs entrant et sortant sur chaque voie.
Je suis plus favorable à 4 capteurs  parce que je suis en DCC et que la zone ou se trouve implanté le PN est  retro signalée et liée a un logiciel de gestion (CDM RAIL).
Je veux donc éviter de rajouter une potentielle perturbation de la détection et du signal DCC sur cette zone pour éviter les erreurs de détection. Meme si avec un relais bistable autoalimenté ou un optocoupleur ca doit limiter les perturbations. C'est la raison pour laquelle j'ai choisi d'installer mes détecteurs sur des zones neutres (non retro signalées).
Mais effectivement avec 2 capteurs et une zone complete detecté par voie ça parait encore plus simple.
De tout les projets  que j ai lu sur locoduino la progressivité de ta solution(s) 1,2,3,4,5 me semble la plus adapté pour un debutant, le seul defaut c est qu'elle configurée pour TIB, qui est un cas particulier (Un seul train , en place  sur la voie detectée, impliquant une initialisation PN fermé)  dans la realité un PN est plus souvent ouvert que fermé.
 Et pour etre complet je l ai implanté (La 5)sur mon reseau tel quelle en remplacant  juste les ILS par les detecteurs de courant et ca marche nickel, le seul probleme c est qu'avec deux trains le PN n est plus protégé.
Pierre

[Pilou3837]

Ca marche .
Je vais tenté de le secouer un peu au niveau des circulations  pour tester la securité (deux trains qui se suivent, refoulement...) 
je vais avancé sur signal, barrieres et son.
Merci de votre aide
Bonne soirée

[chris_bzg]

Content que ça marche, cela donnera une bonne base pour la suite. Mais il faut effectivement le pousser dans ses derniers retranchements ! Et tester toutes les possibilités.

Le PN a été adapté à TIB car c'était un défi lancé par le groupe LR-Presse, mais je l'ai aussi conçu pour n'importe quel réseau plus grand. Les petits réseaux ont plus de contraintes que les grands, mais un réseau de club peut par exemple reproduire la séquence exacte d'un PN SAL 2. De plus, j'ai expliqué comment faire avec deux voies, comment simplifier le programme avec des détecteurs d'occupation, et même comment faire un PN SAL 4.

Et si le PN a été conçu avec des ILS (pas très modernes j'en convient), c'est parce qu'il devait être installé sur n'importe quel réseau déjà terminé sans nécessiter de travail important comme des coupures de voies et des repiquages d'alimentation.

Voilà pour la petite histoire de ce PN. Si je devais faire un réseau avec PN, je choisirai d'installer celui-ci avec deux voies surveillées par des détecteurs d'occupation et je simplifierai le programme comme on en a parlé, et cela marcherait encore mieux. Mais ma loco a fait plus de 100 fois le tour du réseau TIB sans aucun problème sur le PN, c'est déjà pas si mal.

J'espère que ton travail aboutira et qu'il inspirera d'autres modélistes à réaliser et améliorer ce petit passage à niveau. Tiens nous informés...

[chris_bzg]

J'ai bien réfléchi et je ne crois pas que le refoulement sera pris en compte à tous les coups sur ton réseau. En effet, si le refoulement a lieu APRES que le détecteur a détecté, cela devrait marcher. Mais si le refoulement a lieu PENDANT que le détecteur détecte, alors on aura un front montant sur l'entrée qui ne sera pas pris en compte par le programme.

Le fait de passer de FALLING à CHANGING dans l'ISR ne fera qu'aggraver le problème car le détecteur fera fermer la barrière mais la fera aussi rouvrir dès qu'il ne détectera plus (le train continuant sa course vers le PN).

Je ne vois donc pas de solution simple à cela, alors qu'avec les ILS, le refoulement était pris en compte (je l'ai testé sur TIB).

La seule solution que je vois serait d'utiliser les détecteurs d'occupation comme décrit dans l'article 5, avec de grandes portions de voies surveillées.

Pourquoi penser que cela perturbera le DCC et CDM Rail ? A la limite, une isolation galvanique avec optocoupleur peut résoudre ce problème (si tant est qu'il y a bien un problème).

Tu as donc encore quelques essais à faire, mais il y aura forcément une solution ou alors un compromis à trouver.

[Pilou3837]

Bonsoir,

bien vu j'ai constater le problème hier soir.
Le refoulement en soit n'est pas un probléme , en fonctionnement normal (commande par CDM rail) mes trains ne sont pas sensés refouler sur ce canton ou alors ce sera en mode manuel.
Mais dans la meme logique si je comprends bien il y a un risque aussi à la poursuite, si un deuxieme train entre dans la zone A avant que le premier l'ai quitté...
Il faut que je teste avec une circulation dense. Donc pour l instant ce sera compromis.
Czci étant j'ai de nouveau reflechi  a une zone détectée complete par voie encafrant le PN,  je vais tester mais pas tout de suite. Ca implique sur mon reseau de détecter sur 3 zones différentes;2 retrosignalées differentes et une zone neutre et il y aura malgré le pont de diode sur la zone neutre pour compensé la chute de tension des zones retrosignalées une difference de tension non negligeable . Mais ca se teste !
Pour LED PN et Son j'ai  mis à jour la version: pas eu le temps de tester, mais je pense que ça doit etre OK je n'ai fait que reprendre ton code .Fichier Joint.
Je reflechis sur les barrieres, comme mon PN est un PN manuel avec garde barriere je vais tenté d'utiliser la biblio SlowMotionservo !
Challenge!
Pierre

[chris_bzg]

Effectivement, ce que j'ai dit pour le refoulement s'applique également aux circulations denses. Mais les trains ne se suivent pas à la queue leu leu comme les voitures sur l'autoroute !

La protection du PN comme décrit dans l'article 5 est à mon avis ce qui se fait de mieux et ressemble à ce que fait la SNCF. Mais je ne sais pas si cela peut ou non perturber la rétro-signalisation. Il ne devrait pas y avoir de raisons mais les tests grandeur nature que tu feras nous en diront plus...

L'idée d'utiliser SlowMotionServo est une très bonne idée car tu pourras simuler le rebond de la barrière. Dans un PN moderne, il n'y a pas de rebond des demi-barrières donc je n'ai pas jugé utile. Mais attends que ça marche tel quel avant d'introduire cette bibliothèque. En tout cas, comme tu dis, c'est un beau challenge.

J'espère que tu posteras une petite vidéo quand tout sera au point... Allez, bon courage.

[Pilou3837]

Bonjour,

Je touche au but , voici mon sketch  fonctionnel avec biblio SlowmotionServo.
par contre j ai un vrai problème avec les temporisations et la fonction  millis(). j'ai beau tourner le probleme dans tous les sens, des que je rajoute une temporisation rien ne se passe.
temporisation = 0 tout va bien .

Pierre

[chris_bzg]

As-tu déjà testé le programme SANS SlowMotionServo ?

En effet, la dernière fois, nous en étions restés au fait de déterminer avec succès l'occupation de la zone PN. Le cheminement normal aurait été de tester ensuite les feux (et uniquement eux), puis le mouvement des barrières tel que le programme le propose (sans rien changer), puis ENFIN l'ajout de SlowMotionServo. Là, tout est fait mais comment savoir ce qui ne fonctionne pas tant il y a eu des trucs rajoutés ?

En comparant ton programme avec le mien, je suis un peu perdu : quand actualises-tu topAttente ? Pourquoi avoir une temporisationOuverture qui n'existe pas dans la réalité ?

Donne moi quelques détails sur l'ensemble de ce que tu as fait.

[Pilou3837]

Bonjour,

Oui j ai tout fait dans l ordre...
Et ca marche , Cligno avec lightdimmer et declenche son sur carte ISD180.
J'ai testé un code avec biblio servo ( comme le tien) ca marche.
et la c'est le code avec biblio Slowmotionservo, qui marche aussi .
 le Top attente correspond au top millis // je prend le temps au demarrage de la boucle
j'ai rajouter un tempo ouverture correspondant  a une tempo ouverture apres passage du dernier train ( option au cas ou le plus long train soit encore sur le pn .
J'ai donc rajouter sur le sketch
if millis() >topAttente + temporisationFermeture  avant la fermeture des barrieres apres allumage feu et son si Zone PN  Occupée
et
if millis() >topAttente + temporisationOuverture avant ouverture des barrieres si zone PN  libre

en fin de sketch je remet le topAttente a la valeur millis
 Si temporisationFermeture  et temporisationOuverture= 0  le sketch fonctionne parfaitement
Des que je met une valeur  2000 par exemple plus de mouvement barriere

[chris_bzg]

Bonjour Pierre,

Voici mon analyse, mais ne pouvant tester mes idées en réel, ça vaut ce que ça vaut...

Voici ton code :

Code: [Sélectionner]

if(etatZonePN == true) {
     
     digitalWrite (LED_BUILTIN, HIGH); // allume LED de controle de la zone PN
     feuPN.startBlink(); // commence le clignotement
     digitalWrite (sonPN, HIGH);
   if(millis()  >  topAttente + temporisationFermeture) {
        barriere1.goTo(positionFermeeBarriere1);
        barriere2.goTo(positionFermeeBarriere2);
   }
   topAttente = millis();
  }  // fin du test sur etat de la Zone du PN -> true

Et voici le mien :

Code: [Sélectionner]

  if(etatZonePN == true) {
    if(etatZonePN != old_etatZonePN) {
      topAttente = millis();  // prend un top d'entree dans zone PN
      old_etatZonePN = etatZonePN;
    }  // fin du deuxieme if
    digitalWrite (LED_BUILTIN, HIGH); // allume LED de controle de la zone PN
    feuPN.startBlink(); // commence le clignotement
      // fermeture barriere après attente
    if(millis() - topAttente > delaiFermeture) {
      if(posServo < posFerme) {
        posServo = posServo + 1;
        servo1.write(posServo);
        servo2.write(posServo);
        delay(speedServo);
      }  // fin du test sur position des servos
    }  // fin du test sur delai avant fermeture
  }  // fin du test sur etat de la Zone du PN -> true

Pour ma part, avec des détecteurs ponctuels comme des ILS, je suis obligé (pour éviter des événements successifs et identiques) de comparer l'état de la zone avec son état antérieur et je n'agis que s'il y a changement d'état. Tu utilises des détecteurs d'occupation mais hélas (selon moi), tu les utilises comme des détecteurs ponctuels. Donc cela marchera si tu colles au plus près à ce que j'ai publié. Et ce que tu as écrit n'est pas tout à fait la même chose.

Voyons maintenant la variable topAttente. Dans mon code, je la réinitialise dès le début de la manipulation des barrièreS. Toi, tu le fais à la fin et pour un étatZonePN libre, tu ne le fais pas. Peut-être que le problème vient de là, la variable n'étant pas réinitialisée, la condition est toujours fausse et rien ne se passe. Tu peux vérifier cela en affichant cette variable sur le moniteur.

Pourrais-tu m'envoyer le programme SANS la bibliothèque SMS que je puisse comparer et d'ailleurs, est-ce que cela fonctionnait avec un retard à la fermeture ?

Encore une fois, ce n'est pas très facile pour moi de te donner un avis pertinent. Mais tu peux de ton côté faire les tests jusqu'à ce qu'on en sache plus.

Ne te décourage pas et bonne journée.

[chris_bzg]

Dans la boucle, tu fais topAttente = millis();
A l'itération suivante, millis() a un peu augmenté donc millis > topAttente + 0 (valeur où ça marche).
La condition est vrai, les barrières se ferment.

Par contre, si le délai est 2000 (valeur où ça ne marche plus) par exemple, à l'itération suivante millis() qui est égale à topAttente + epsilon n'est jamais supérieure ou égale à topAttente + 2000.
Condition fausse, donc les barrières ne se ferment pas.

Je suis donc persuadé que le problème vient de là et que le topAttente n'est pas réinitialisé dans les bonnes conditions. A toi de revoir ces conditions pour les mettre au bon endroit.