Passage à niveau 2 voies double sens

[Pilou3837]

Bonjour,

Oui je pense que le top millis() n 'est pas initialisé au bon moment.
Dans ta version ILS le top est pris au changement  d etat PN.
Dans ma version du fait des capteurs il y deux changement d etat sur zone A et sur zone B , l etat de la zone A et B donnant l etat de la zone PN .
A mon avis il faut que je creuse sur ce changement d etat zone pn
J avais fait une version avec biblio servo qui marche , mais sans la tempo fermeture . Je te la joint au cas ou .
La version avec Biblio Slowmotionservo marche bien aussi sans la tempo.

Je vais reflechir...

[chris_bzg]

Es-tu d'accord avec ce que j'ai expliqué dans mon deuxième message ? Pour moi, c'est la raison pour laquelle ça ne marche pas.

Dans ce cas, il faut prendre le top lors d'un changement d'état de la zone PN (peu importe les voies A ou B), bref tu verras que cela reviendra à quasiment copier ce que j'avais écrit tout en mettant SMS en plus.

Encore un peu de boulot de réflexion mais tu y es presque.

[Pilou3837]

Merci tout marche ... le fichier en piece jointe
Ceci etant J'ai repris ton code un peu betement  mais je ne comprends pas ce qui se passe lors du test if 
  if(etatZonePN != old_etatZonePN ){
      topAttente = millis();
      old_etatZonePN = etatZonePN;
Une explication serait la bienvenue .

Le code avec tempo pour  fermeture est maintenant :

if(etatZonePN == true) {
     if(etatZonePN != old_etatZonePN ){
      topAttente = millis();
      old_etatZonePN = etatZonePN;
     }
     digitalWrite (LED_BUILTIN, HIGH); // allume LED de controle de la zone PN
     feuPN.startBlink(); // commence le clignotement
     digitalWrite (sonPN, HIGH);
     
     if (millis()- topAttente > temporisationFermeture) {
      //Fermeture barriere
        barriere1.goTo(positionFermeeBarriere1);
        barriere2.goTo(positionFermeeBarriere2);

et le code tempo Ouverture  :
if(etatZonePN == false) {
    if (old_etatZonePN != etatZonePN){
      topAttente = millis();
      old_etatZonePN = etatZonePN;
    }
    digitalWrite (LED_BUILTIN, LOW);
    digitalWrite (sonPN, LOW);
    feuPN.stopBlink();  // arrete le clignotement
    feuPN.off();  // eteint les feux
    if (millis()- topAttente > temporisationOuverture) {
    // ouverture barriere
    barriere1.goTo(positionOuverteBarriere1);
    barriere2.goTo(positionOuverteBarriere2);
    }
 
    }// fin du test sur etat de la Zone du PN -> false PN Libre

   

[chris_bzg]

Bravo !

Bon, petite explication :
Les barrières doivent se fermer après une attente de quelques secondes. Si je teste uniquement l'état de la zone, je ne fais que relancer le démarrage du délai d'attente. Donc, je ne vais faire démarrer ce délai d'attente que lors de la première fois que je me rends compte que la zone est occupée. Pour cela, je regarde s'il y a transition de la valeur d'occupation sur la zone. C'est ce que font les quelques lignes de code que tu sembles ne pas avoir comprises. J'espère que maintenant, tout est clair.

Dans l'article, j'avais expliqué mais ce n'était peut-être pas aussi clair :
La fonction loop n’est pas compliquée à comprendre. Elle surveille l’état de la zone PN et agit en conséquence. Si la zone PN est libre, il suffit d’arrêter le clignotement des feux et d’ouvrir les barrières. Si la zone PN est occupée, son état passe de false à true et il faut alors faire l’inverse et fermer les barrières. Or on veut attendre un petit délai avant de fermer les barrières, c’est pourquoi on compare l’état de la zone avec son état précédent de manière à lancer l’attente que s’il y a eu changement d’état. Si on ne faisait pas cela, alors on relancerait indéfiniment le délai à attendre et il ne serait jamais terminé pour manœuvrer les barrières. Le mouvement des barrières est obtenu grâce à la méthode write(posServo).

Je vais regarder ton code mais il ressemble déjà plus à ce que j'avais publié.

Pour résumer, tout fonctionne comme tu le souhaites avec en plus ce petit rebond des barrières que permet SMS, c'est bien cela ?
Tu vas pouvoir tester les cas particuliers : refoulement, circulation dense, etc. mais je pense que tu ne devrais pas avoir de problème sauf cas très particulier qui serait par nature non réaliste.

Bravo pour ta persévérance.

[chris_bzg]

Je viens de regarder le dernier code que tu m'as transmis : à priori, il me semble OK.

J'ai tout de même une petite question : dans mon programme, le mouvement des barrières était obtenu par des itérations successives de loop. Entre deux itérations, on ne déplace les servos que de 1 degré, ce qui dure peu de temps pour ne pas perturber le reste du programme (surveillance, clignotement). Dans ton programme, le déplacement des barrières se fait par la méthode goTo où on donne directement la position finale et pas de position intermédiaire qui s'incrémente à chaque boucle.

La question est : pendant le mouvement des barrières vers la position finale, qui dure quand même un petit peu puisque c'est un mouvement lent, est-ce que le reste du programme n'est pas perturbé ? Pour cela, il serait intéressant d'avoir une petite vidéo et faire des essais de refoulement. Par exemple, en cas de refoulement, est-ce que la barrière se réouvre immédiatement, donc AVANT d'avoir atteint sa position fermée ou bien est-ce qu'elle attend d'avoir atteint cette position pour faire la réouverture ?

La vidéo permettra aussi de savoir si le fonctionnement de LightDimmer n'est pas altéré par SMS. Mais dans une utilisation normale, cela ne devrait pas être gênant.

[Pilou3837]

Merci pour les infos, c est beaucoup plus clair pour Top Attente et millis, je comprends maintenant  pourquoi mon code ne marchait pas.

Pour GoTo (direct) ça à l air de marcher sur Montage breadboard et boutons poussoir. meme si j'ai été obligé d augmenter drastiquement la vitesse du servo 2 pour qu il bascule a la meme vitesse que le servo1 ( le servo est parfaitement fonctionel) et je n'ai pas le probleme si je pilote les deux servos avec la meme sortie . cette lenteur du servo 2 serait elle liée a ce que tu decris, ou est ce du simplement a l alimentation de la carte Arduino qui rame pour 2 servo SG90 , en réel sur mon reseau ils auront leur alimentation dediée.
 
Je vais voir sur les exemples des sketchs qui utilisent SMS si je peux améliorer en se sens.
J'ai vu dans l article de Jean Luc sur "Comment concevoir rationellement votre systeme) qu' effectivement on peut determiner des etats intermediaires pour les barrieres (Se ferme, fermee, ouverte, s ouvre et tempo).

Mais l instant c est OK et je te remercie pour ta patience ,  je pense avoir bien progressé et appris plein de chose sur ce projet c 'etait très didactique de ta part.

Pierre

 

[chris_bzg]

J'ai pris du plaisir à me replonger dans le PN pour t'aider dans ton projet ; on n'a rarement de retours et je pense que beaucoup lisent nos articles par curiosité mais ne franchissent pas le pas de faire eux-mêmes. Alors, quand on tient quelqu'un qui veut aller jusqu'au bout, c'est notre devoir de tout faire pour l'aider. Et puis, contrairement à ce que tu écrivais dans un de tes premiers posts, tu n'es pas si débutant que tu le disais, bien au contraire.

J'ai un peu regardé le code (.CPP) de la bibliothèque SMS et je ne pense pas que cela engendrera de problème. Si tes deux servos ne vont pas à la même vitesse, on peut effectivement penser à une alimentation trop faible, sauf que je n'ai pas eu ce problème de mon côté (les deux servos SG90 sont synchronisés en étant alimentés par Arduino). Il faudra donc creuser un peu plus cette question.

La trajectoire que tu as choisie (SMSSmoothBounce) est plutôt faite pour des portes de remises. Voilà un nouveau challenge : définir ta propre trajectoire plus adaptée aux barrières manuelles qui rebondissent mais finissent ensuite par retomber dans le V qui les reçoit. Vois-tu ce que je veux dire ?

Et maintenant, d'autres projets ?

[Pilou3837]

Je vois très bien pour bounce….j ai vu que ca ne simule pas le rebond du V. J ai vu aussi qu on pouvait customiser ces propres trajectoires .avec sms à voir
 A part faire clignoter des led et suivit quelsues tutos c est mon premier projet . Mon Pn étant déjà fonctionnel sur mon réseau mais piloté par des actionneurs sous cdm rail et un decodeur d accessoires et des relais. Je me suis penché sur Arduino à cause de la non protection du Pn et le fait que les logiciels de train ne gère pas les automatismes .c est une démarche un peu intellectuelle et ça fait travailler mon esprit
C a prend du temps , je ne suis pas du tout informaticien. Après c est comme tout il faut un apprentissage personnel et de l aide extérieure quand ça coince .donc merci encore une fois
Prochain projet sûrement la sonorisation du réseau, église , marché, usine , forêt et rivière juste au début de ma réflexion …

[chris_bzg]

......
Prochain projet sûrement la sonorisation du réseau, église , marché, usine , forêt et rivière juste au début de ma réflexion …

Il y a plusieurs articles sur LOCODUINO qui en parle, notamment l'annonce en gare avec RFID mais aussi un article de Dominique (il est comme moi, il ne refuse jamais son aide) qui parle d'une animation sonore.
Et n'oublie pas qu'un projet se construit par étapes successives et que le faire ainsi n'est jamais une perte de temps, bien au contraire c'est l'assurance d'arriver au bout.