LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: Pilou3837 le octobre 15, 2021, 05:25:53 pm
-
Bonjour,
Completement débutant en Arduino, j'ai tenté de modifier le projet PN TIB de Christian Bezanger pour tenter de l adapter à mon projet .
* PN_2Feux_Barrieres_SortieSon_InitOuvert.ino
* *****************************************************************************
* Programme developpe pour le projet de PN Pierre.
*2 voies a et b double sens pn delimité par 2 zones Zone a et Zone b
*2 capteurs de detection de train en debut et fin de chaque zone
* Il prend en compte l arrivee du train, le clignotement des feux en simulant
* une ampoule a filaments, un delai avant mouvement des barrieres,
* le mouvements des deux barrieres sur 90° d amplitude (depend de
* la transmission adoptee).
* Le programme s'initialise barrieres ouvertes
* La LED_SON est allumee tant que sonnerie doit jouer ; cette sortie commande
* le module sonore.
Je vous poste mon sketch modifié pour contrôle et recommandation.
Je ne suis pas sur du tout confiant pour le void loop et la gestion des changements d'état .
Merci de votre aide et de vos conseils
-
Bonsoir,
Avant tout formalisez la logique du programme modifié.
ensuite, je vous suggère de vérifier le respect du langage Arduino et d'arriver à un sketch qui passe à la compilation.
Vérifiez les déclarations des variables que vous utilisez et l'usage qui en est fait ensuite.
Pour la mise au point de votre programme, placez des Serial.print sur les variables clés pour savoir où votre programme passe et quelles valeurs vos variables ont là.
-
Merci,
Je vais retourner bosser
Mais cela ne m avance pas beaucoup…
Je suis un vrai débutant je maitrise un tout petit peu
La où je coince entre autre c est sur les changements d état des zones occupées ou libres
Et donc comment un capteur devient soit entrant soit sortant
Et pas très à l aise avec les Isr
-
Bonjour,
En tant qu'auteur des articles, je vais essayer de vous donner un coup de main pour arriver au bout de votre projet.
Si j'ai bien compris, votre PN diffère du PN-TIB par le fait qu'il y a deux voies à protéger. C'est donc en comprenant bien le principe de détection décrit au chapitre 1 que vous arriverez à réaliser votre projet. Et déjà, j'aimerais savoir si vous y arrivez car le programme que vous donnez réalise l'ensemble de toutes les fonctions du PN y compris le son.
Or, je pense l'avoir dit, un projet doit se construire par étapes et pour vous, la première étape est déjà de détecter l'occupation des voies. Vous ajouterez le reste ensuite et vous verrez que si cette première étape est réussie, le reste coule de source.
J'ai un peu regardé votre programme ; vous voulez que le programme s'initialise barrières ouvertes. Dans ce cas, pourquoi initialisez-vous à true les variables etatZonePN ? (lignes 39 et 41)
Les capteurs n'ont pas besoin de passer de entrant à sortant : ils ne font que détecter un survol, donc le fait qu'un engin entre ou sort de la zone surveillée. Et ce sont justement les conditions d'initialisation qui font qu'on saura si l'engin entre ou sort. Ces conditions seront à respecter sur les deux voies.
Quant aux ISR, elles ne font que changer le statut de la zone. Et c'est le programme principal qui fait le reste.
J'espère vous avoir un peu aidé. Faites les choses progressivement, étape par étape. C'est à ce prix que vous maitriserez. Je dois encore étudier votre programme pour voir s'il est bien conçu et ceci peut prendre du temps.
Je vous propose donc pour la suite de partir du programme de l'article 1 et le transformer jusqu'à ce qu'il détecte bien les trains sur les deux voies. Le reste viendra en son temps.
Bonne programmation.
Christian
-
Je viens de me pencher sur votre programme.
Tout d'abord, il m'a fallu corriger plusieurs petites choses avant que la compilation puisse avoir lieu. La moindre des choses est déjà de nous donner des programmes qui passent la compilation sans problème. Dans votre programme, des variables n'étaient pas initialisées (old_top_debutISR_a et old_top_debutISR_b par exemple) et des erreurs de syntaxes comme Low à la place de LOW ou encore rising à la place de RISING).
D'ailleurs, pourquoi utilisez-vous RISING alors que mon programme utilise FALLING ? Vos détecteurs sont différents et produisent un signal HIGH au lieu de LOW ? Je ne pense pas.
Encore une fois, il faut y aller par étape. C'est aussi nécessaire pour que nous puissions vous aider car reprendre le programme de quelqu'un demande du temps et plus ce programme est court, moins il en faut et plus on trouve vite ce qui cloche. A partir de là, on vous donnera un programme qui fonctionne et vous le complèterez.
Vous y arriverez, d'autres y sont parvenus alors vous y arriverez.
Bon courage (et ne nous envoyez plus de programme qui ne compilent pas, corrigez les d'abord).
-
Merci pour tout ces conseils très constructifs.
Je vais tenter de reprendre le projet au niveau de la détection des zones uniquement.
J utilise des détecteurs de courant DCC qui bascule un relais, Viessman 5206 que j avais sur un vieux réseau j ai fait le choix high 5v si relais coller train détecté d ou mon choix de Rising , mais je pourrais inverser la sortie du relais et rester sur low 0v et donc falling au moment de la détection.relais non collé.
Je vais regarder tout cela tranquillement
Encore merci
Pierre
-
Je comprends mieux.
Commencez toujours par vous rapprocher le plus possible des conditions du programme donné dans un article (car il fonctionne et a été testé). Et si le votre fonctionne aussi, alors il sera possible de modifier.
Je vais vous laisser cogiter un peu et j'ai déjà une solution à vous proposer (que vous pourrez tester chez vous).
Partez de deux variables etatZone_A et etatZone_B dont la valeur est modifiée par les ISR ; dans le programme principal, commencez par déterminer ce que vaut la troisième variable etatZonePN (ceci était bien fait dans ce que j'ai lu). A partir de cette valeur de troisième variable, le reste du programme est identique à ce que j'ai publié.
Si vous progressez par étape, je suis certain de votre réussite.
-
Juste une dernière précision :
Puisque vous utilisez des détecteurs d'occupation, le programme que j'ai écrit ne peut plus convenir. En effet, ce programme est prévu pour traiter des événements de courte durée (déclenchement d'ILS) d'où la nécessité de recourir aux interruptions pour ne pas louper d'événements.
Or un détecteur d'occupation va délivrer un signal pendant une durée plus longue (tant que la voie est occupée). Ce signal, dans la mesure où il est ramené à une tension comprise entre 0 et 5V, peut être présenté à une entrée d'Arduino. Dans le programme principal, il suffit alors de commencer par lire l'état de l'entrée pour en déduire l'état d'occupation.
C'est donc encore plus simple.
Je n'avais pas percuté sur ce point car dans votre programme, vous continuez à appeler les entrées par 'ILS'. Il aurait mieux valu les appeler autrement, comme par exemple 'detecteur_A' ou bien 'signalOccupation_A'.
Cette fois, c'est à vous et j'attends de vos nouvelles.
-
Bonjour,
J'ai tenté de tenir compte de toutes vos remarques précieuses et j'ai drastiquement simplifié le sketch. cf pj
Pour les détecteurs de courant c'est effectivement une zone 20cm isolée qui sert de détection en amont du pn ( et en aval )
Par contre je n'ai pas déclarer de troisième variable zone Pn je n'en voyais pas l'interet, mais je peux me tromper !
En tout merci pour vos conseils
Pierre
-
Annule et remplace le precedent fichier.
Pierre
-
Bonjour,
J'ai tenté de tenir compte de toutes vos remarques précieuses et j'ai drastiquement simplifié le sketch. cf pj
Pour les détecteurs de courant c'est effectivement une zone 20cm isolée qui sert de détection en amont du pn ( et en aval )
Par contre je n'ai pas déclarer de troisième variable zone Pn je n'en voyais pas l'interet, mais je peux me tromper !
En tout merci pour vos conseils
Pierre
Je vais regarder le nouveau sketch.
En déclarant une variable etatZonePN, vous vous retrouvez dans la même situation que ce que j'ai publié. Mais vous avez raison, on peut s'en passer, donc à vous de voir. Cette variable a aussi l'avantage de donner un programme plus facile à lire et à comprendre.
Par contre, vos zones de détection ne protègent pas l'ensemble du PN comme je l'ai expliqué dans l'article 5. Il va donc falloir tenir compte de cette particularité pour faire en sorte que les barrières ne se relèvent pas trop tôt. Mais il y a une solution que vous trouverez plus facilement que moi parce que vous pourrez faire des essais. Un schéma de votre réseau me permettrait de me rendre compte.
Comme vous le voyez, ça avance.
-
merci, le croquis de mon reseau pour vous eclairer.
je pense que j'ai assez de place entre PN et detection sur mon reseau pour laisser passer les plus longs trains, ceci étant, je peux aussi rajouter un délais avant ouverture des barrieres dès fin de detection.
Pierre
-
Je viens de regarder le nouveau sketch. Déjà il compile, c'est un progrès ;)
Par contre, je l'ai essayé sur un simulateur Tinkercad et il ne fonctionne pas. Dès la mise en route, la LED_BUILTIN s'allume et en envoyant un signal de détection, rien ne se passe.
En modifiant les lignes 26 et 27, on arrive à le faire fonctionner.
Tout d'abord, je suppose que vos détecteurs envoient un signal LOW quand ils détectent puisque vous utilisez INPUT_PULLUP (le signal est HIGH en temps normal).
Ensuite, lorsque vous écrivez etatZone_A=digitalRead(CaptA); ce n'est pas orthodoxe. En effet, etatZone_A est un booléen (true ou false) alors que la lecture de l'entrée donnera LOW ou HIGH. Pour la beauté des choses et la compréhension par d'autres programmeurs, il vaut mieux écrire :
if(digitalRead(CaptA)==LOW) {
etatZone_A = true;
}
else etatZone_A = false;
Donc, en remplaçant les lignes 26 et 27 par ce que j'ai écrit, votre programme fonctionne sur Tinkercad et est plus facile à comprendre.
Bravo à vous tout de même pour ces changements. Je vous propose maintenant de tester en réel, sur votre réseau, ce fonctionnement pour voir si les zones de détection sont suffisantes pour protéger l'ensemble de la zone située de part et d'autres du PN. Une temporisation est peut-être une bonne idée. Et après cela, il sera temps de passer aux feux puis aux barrières. On en reparlera...
-
Vu le plan, votre montage équivaut à surveiller la frontière des zones, comme ce que j'ai publié.
C'est un peu dommage de ne pas avoir suivi le schéma que j'ai publié dans l'article 5 alors que c'était l'intérêt des détecteurs d'occupation. Mais je ne veux pas vous faire tout modifier. Il y aura d'autres solutions, logicielles cette fois : Arduino sait s'adapter à ce qui existe !
-
Merci beaucoup
j appreciie enormement vos conseils
Je vais potasser encore sur le sujet...
Pierre
-
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.
-
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 (https://locoduino.org/spip.php?article265)) concernant l'emploi de détecteurs d'occupation par consommation de courant.
-
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);
-
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.
-
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
-
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
-
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...
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
Bonjour Pierre,
Voici mon analyse, mais ne pouvant tester mes idées en réel, ça vaut ce que ça vaut...
Voici ton code :
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 :
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.
-
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. ;)
-
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...
-
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.
-
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
-
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.
-
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.
-
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
-
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 ?
-
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 …
-
......
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.