alimentation retardée d'un relais

[Ambo73]

Bonjour,
Je suis en train de travailler sur un montage comme schématisé en pièce jointe. Ce montage fait partie d'un ensemble dont la description est sans intérêt pour l'instant.
Il se compose comme suit:
- 1 Arduino UNO dont une des sorties digitales, la D4, doit piloter le module relais
- 1 module relais 5V (périphérique classique d'Arduino) dont la particularité est d'être alimenté en permanence en 5V et dont le déclenchement est assuré en envoyant du 5 V sur sa borne S
- 1 module marqué ? objet justement de cette discussion et pour lequel j'aurais besoin de votre aide

Voici le fonctionnement que je souhaiterais avoir:
- la sortie D4 de l'Arduino peut passer de l'état BAS (0V) à HAUT (5V) en fonction d'évènements arrivant en amont de l'Arduino. Normalement, l'état HAUT peut durer plus ou moins longtemps, plusieurs minutes en général, et doit actionner le module relais sur son entrée S.
- de temps en temps, de façon aléatoire, D4 peut passer à HAUT très brièvement (<0.5s probablement). Cette "pulse" déclenche le relais tout aussi brièvement, ce qui est préjudiciable dans le fonctionnement en aval de mon ensemble général. Je pourrais considérer cela comme un "parasite".
- il faudrait donc intercaler un module (noté ? sur mon schéma) faisant en sorte que si D4 est à HAUT pour une durée <1s, le relais n'est pas actionné et si D4 est à HAUT pour une durée >=1s, le relais est actionné jusqu'à ce que D4 repasse à BAS. Le temps de 1 s indiqué ici devra pouvoir être ajusté pendant la phase de mise au point et sera figé ensuite.

Avant de faire appel à votre aide, j'avais imaginé deux solutions que je ne sais finalement pas mettre en oeuvre précisément:
- la 1ère: utilisation d'une cellule RC classique
- la 2ème: utilisation d'un NE555 ou autre CI logique (genre AOP ou autre). J'ai vu pas mal de discussions sur ce sujet mais il y en a tellement que je m'y perds un peu.

Qu'en pensez-vous?
Avez-vous d'autres suggestions?

Avec mes remerciement anticipés,
-----

[gienas]

Bonjour Ambo73 et tout le groupe

Bienvenue sur le forum.

… Qu'en pensez-vous?
Avez-vous d'autres suggestions? …

Avant de chercher la complication et moyennant quelques concessions sur respect rigoureux de ton chronogramme un peu "approximatif", il me semble qu’une seule cellule RC devrait convenir. Les valeurs sont imprévisibles par manque de certaines valeurs.

1- tu fais retomber ton relais exactement à la fin de la commande Arduino. Difficile à imposer où il
Faut un dispositif accélérateur de retombée pas forcément nécessaire.

2- on n’a pas la moindre idée de ce qu’il y a vraiment, entre la borne S du relais et le 0V. Il faut en connaître le schéma réel pour définir le courant de commande absorbé par la borne S. On peut penser que c’est un transistor mais rien ne nous le prouve.

Si ta structure Arduino fonctionne déjà, tu dois pouvoir tester un simple RC, avec un chimique pour C et procéder à des mises au point "pifométrisues".

Pour simplifier ta mise au point, tu devrais mettre dans ton Arduino, un programme qui ne génère qu’une impulsion périodique, par exemple une toutes les dix secondes. Tu donnes à l’impulsion une largeur par exemple deux fois la largeur de ton retard (comme ton chronogramme) et tu regardes le comportement réel.

[antek]

- il faudrait donc intercaler un module (noté ? sur mon schéma) . . .

De ce que tu nous montres, c'est faisable par logiciel.

[f6bes]

Bjr à toi,
Hum , C'est quoi QUOI que tu appelles...."signal de commande sur un...relais" !
Un relais pour sa COMMANDE, comporte une bobine qu'il faut alimenter (ou non).
Donc seulement... 2 Bornes....pas trois comme sur ton dessin !
Si tu veux retarder ton relais, c'est donc sur le retard de mise sous tension de la bobine
qu'il faut agir. C'est donc en " série" entre l'arduino et la bobine.
Il existe des modules (réglable en durée) pour de telle application.
Pum188 de chez Velleman...ou autre modéle. (sortie sur relais)
Bien sur le module de "gestion du retard" demande...une alimentation.

Bonne journée

[A voir en vidéo sur Futura]

[jiherve]

bonjour,

- la sortie D4 de l'Arduino .
- de temps en temps, de façon aléatoire, D4 peut passer à HAUT très brièvement

N'y a t il que moi pour sentir l'odeur fétide du bug soft ?
La sortie s'active donc toute seule par l’opération du saint esprit?
JR

[gienas]

… N'y a t il que moi pour sentir l'odeur fétide du bug soft ?
La sortie s'active donc toute seule par l’opération du saint esprit? …

Toi, tu as un sixième sens que nous n’avons pas.

Je ne sais rien de l’application, ni à quoi elle doit servir, mais je crois comprendre que l’Arduino d’entrée génère des "parasites" qui ne sont des parasites que tant qu’ils n’atteignent pas la durée tR.

L’objectif du "filtre" est de ne laisser passer que ce qui dépasse cette durée. C’est pourquoi je pense aussi que la simultanéité des retombées n’est pas un impératif, car c’est plus compliqué à garantir.

Autre problème: précision du retard. Si des parasites sont fréquents (rapprochés) ils vont avoir tendance à modifier le niveau de la commande du relais.

Il est évidents que la demande est encore trop vague sur tous les tenants et aboutissants. Il faut jouer cartes sur table en précisant à quoi ça sert.

[jiherve]

Re
Sur un Arduino utilisant donc un µC Atmel la modification de l’état d'un port peut se faire de 2 manières:
SBI/CBI PORTx,BITy qui ne modifie qu'un bit
OUT PORTx,REGy qui modifiera tous les bits du port, il faut donc faire un RMW pour tenir compte de l’état antérieur, bien sur en dehors de tout interruption susceptible de modifier l’état de ce port.
Pour les I/O contrôlées par un Timer elles ne peuvent pas être "surchargées"
Donc soft çà pue!
JR

[antek]

La sortie s'active donc toute seule par l’opération du saint esprit ?

A mon avis ce n'est pas un bug, juste un programme mal fait qui prend mal en compte le chronogramme.
Ou alors c'est un bug . . .

[jiherve]

re

A mon avis ce n'est pas un bug, juste un programme mal fait qui prend mal en compte le chronogramme.

définition classique d'un bug!
JR

[f6bes]

Remoi, C'est vrai qu'il vaut mieux TOUT lire....et ne pas s'arréter seulement au schéma.
(pour une fois que je regarde le shéma et le TITRE!!!) Ben c'est loupé !
Bonne journée

[gienas]

A mon avis ce n'est pas un bug, juste un programme mal fait qui prend mal en compte le chronogramme.
Ou alors c'est un bug . . .

… définition classique d'un bug! …

Je ne saisis pas bien ce qui vous permet ces "conclusions".

Nous ne savons rien de l’utilisation, ni à quoi ça doit servir vraiment.

Notre demandeur exprime un vœu pour une fonction très mal définie et aussi avec un "outil" inconnu. (En fait dont on ne connaît pas les caractéristiques réelles)

Je comprends que son véritable desiderata est le rectangle intermédiaire. Qu’est-ce qui peut nous permettre de décider que son Arduino est un bug? Il est une donnée du cahier des charges.

C’est sûr que des précisions "précises" sont indispensables pour éviter de s’enliser.

[jiherve]

bonsoir
oui et non il décrit un phénomène qui n'est possible que s'il y a un bug soft ou un hard tout pourri , on pourra toujours imaginer une solution pour le masquer mais comme en médecine il faut s'attaquer à la source du mal.
JR

[annjy]

Bsr,

Ma première réaction a été : mais pourquoi il ne fait pas ça en soft ?

piloter une sortie d'un processeur pour éviter des impulsions inférieures à une certaine durée, ça ne doit pas être insurmontable (je précise que ma formation informatique s'est arrêté à l'assembleur et au Fortran IV......). Cas classique où un patch de soft masque un bug......

Mais il est vrai qu'on doit se poser la question : pourquoi a-t-on ces impulsions parasites ?

cdlt,
JY

[Electron59]

Bonsoir,
Il veut faire quoi, en fait ?
Son exposé me parait bien mystérieux...
Veut-il s’affranchir d'éventuels parasites ?
Dans ce cas, déclencher 1 Timer et voir si tension "mystérieuse" toujours présente à l'expiration du délai...
1 Picaxe (je salue Mag au passage ) ou PIC devrait s'en sortir ....

[Ambo73]

Bonjour à tous,
merci beaucoup pour vos interventions et remarques pertinentes.
Je vais tacher de donner des réponses pour chaque intervention mais avant, je vais décrire rapidement l'ensemble dans lequel il doit s'insérer.
Il s'agit d'un système d'alarme de maison. Il est constitué par:
- deux lignes filaires périmétriques consistant chacune en plusieurs ILS câblés en série et accrochés aux diverses portes et fenêtres (réalisées par mes soins)
- un ensemble électronique dont l'élément principal est un ARDUINO UNO et dont le rôle est de gérer toutes les fonctions de l'ensemble (réalisé par mes soins)
- un boitier d'alarme complémentaire ETIGER dédié à des détecteurs volumétriques, à une liaison GSM (pour communiquer avec mon Smartphone) et connecté à une alarme extérieure (commerce)
- une alimentation 5Vcc sur accus rechargeables, alimentée sur secteur (commerce)

voir la vue #0 en PJ. synoptique général sch#0_2023-02-22.png

J'ai programmé l'Arduino de façon à assurer plusieurs fonctions dont la principale est d'envoyer une information au boitier ETIGER dès que l'un des ILS est ouvert, ce qui a pour effet de déclencher la sirène et d'envoyer un message GSM. En fait d'information, il s'agit de l'ouverture des contacts NF d'un relais (contact NF fermé: ETIGER en sommeil, contact NF ouvert: ETIGER déclenché)

Normalement tout marche très bien sauf que de temps en temps (sur des périodes plus ou moins longues) et de façon totalement aléatoire, l'alarme se déclenche. Elle se remet en veille automatiquement. Lors de ces déclenchements intempestifs, aucune ouverture n'a été actionnée. C'est très gênant car on ne sait plus distinguer l'intempestif d'une éventuelle réelle intrusion.

Selon moi, il peut y avoir plusieurs raisons:
raison 1: les lignes filaires périmétriques sont défectueuses. Les fils font tout le tour de la maison et il peut y avoir un mauvais contact quelque part. Probabilité estimée 1/5
raison 2: un des ILS est défectueux. Probabilité estimée 0/5
raison 3: le programme de l'Arduino a un bug dans une des routines. Etant donné le coté très aléatoire du pb, c'est difficile a estimer. Même si j'ai une certaine expérience de la programmation, je suis faillible. Probabilité estimée 3/5.
raison 4: il y a des parasites qui perturbent le programme de l'Arduino. Je ne sais pas comment détecter cela mais ça me semble peu probable: Probabilité estimée 2/5
raison 5: le module relais est défectueux. Plus exactement, les contacts NF sont dégradés et la continuité électrique est de temps en temps rompue. Probabilité estimée 1/5
raison 6: il y a une autre raison que je n'ai pas encore découverte. Probabilité estimée 4/5

Au final, il y a urgence pour moi de mettre fin à ces déclenchements intempestifs même si c'est par un bricolage pour l'instant, sachant que je pourrais par la suite en rechercher les raisons réelles.

Donc voici maintenant mes réponses à vos commentaires

@gienas
Merci pour ton accueil. C'est la 1ère fois que je poste ici mais ça fait longtemps que je lis FUTURA et ses forum en particulier.

Oui, mon schéma est approximatif mais c'est un peu volontaire. Je ne voulais pas "induire" une solution en étant plus précis. L'idée est de trouver un dispositif, à intercaler entre la sortie de l'Arduino et l'entrée du relais, qui fasse le job, peu importe les choix techniques. Quand je dis "peu importe", faut pas pousser quand même. Je ne souhaite pas pas installer une usine à gaz...
Ma 1ère idée a été, comme tu le suggères, d'utiliser une cellule RC. J'ai fait un prototypage sur un plaque d'essai et je n'ai pas trouvé de bonne combinaison RC. Voir schéma #1 en PJ. schéma #1.png
Comme tu l'as bien imaginé, l'entrée du module relais est un transistor.
Peut-être faut-il faire un peu plus qu'un seul condensateur et une seule résistance?
L'idée de faire un petit programme pour recréer des impulsions avec l'Arduino me plait bien.


@antek
Oui, je pressens bien que quelque chose doit être possible en programmation mais le coté aléatoire ne facilite pas la chose pour débuguer... Je vais regarder de plus près.

@f6bes
Ce n'est pas un relais "normal". C'est un module-relais, lequel comporte une partie logique en entrée (noté S) et un relais classique en sortie. Il faut donc bien l'alimenter en 5V puis le commander en appliquant du 5V sur l'entrée S.

@jiherve
J'ai bien rit en lisant ta remarque. Oui, ça sent pas bon et j'en suis conscient. Mon expérience en programmation me fait dire que dans le cas de phénomènes aléatoires de ce type, le débuguage peut être très long.... J'ai déjà connu ça dans ma vie professionnelle...
Tu écris un peu plus loin:

Sur un Arduino utilisant donc un µC Atmel la modification de l’état d'un port peut se faire de 2 manières:
SBI/CBI PORTx,BITy qui ne modifie qu'un bit
OUT PORTx,REGy qui modifiera tous les bits du port, il faut donc faire un RMW pour tenir compte de l’état antérieur, bien sur en dehors de tout interruption susceptible de modifier l’état de ce port.
Pour les I/O contrôlées par un Timer elles ne peuvent pas être "surchargées"
Donc soft çà pue!

He bien voilà, là, je suis lâché... mais je sens qu'il y a qqc à développer, avec ton aide éventuellement...


Personne n'a évoqué l'utilisation éventuelle d'un NE555 ou circuit similaire... Est-ce que c'est inadapté ?


Désolé pour ce post très long (trop peut-être...) mais j'aime bien donner le plus de détails possible et je suis sûr que ce n'est pas fini.
Merci encore de vous intéresser à mon sort.

[Electron59]

Idem sur PIC pour ne traiter qu'un seul port :
PORTx =%xxxxxxyx ou LATx=%xxxxxxyx

[jiherve]

re
là il y a un peu plus de grain à moudre.
as tu un filtre passe bas (hard et/ou soft) sur tes entrées ILS, si les fils sont longs, ce qui doit être le cas, ils peuvent ramasser des parasites et déclencher tes routines logicielles.
Comment ces entrées sont elle gérées : interruption, scrutation?
Relis bien ton code, n'y a t il pas de possibilité de conflits entre le programme principal et les interruptions sur la gestion du port?
JR

[Electron59]

Re,
Comme dit en #14 je parlais de Timer, il me semble bien que cela peut faire office de "Passe-Bas" logiciel, non ?...
Donc inutile d'ajouter composants (comme indiqué avec l'ovale en rouge) puisque traité par soft en amont par le µC
Si les interruptions sont bien gérées (pas toujours facile, en effet), il ne doit pas exister de conflits, en théorie...

[Electron59]

Après avoir relu ton post #15, tes raisons invoquées ne me semblent pas pouvoir provoquer ces déclenchements car -justement- ils sont aléatoires (ou intempestifs comme tu l'indiques)
Je rejoins jherve qui suppute des "parasites" dus à des causes "humaines" ou naturelles ;
Relier chaque ILS dans ta boucle via un câble blindé ;
Découpler chaque ILS et leur ligne "d'alimentation" via capacité de qq dizaines de nF;
Filtre "Passe-Bas" Logiciel via Timers du µC / Arduino ;
Quelques pistes !...
Bon courage

[gienas]

Non! Ton message n’est pas trop long, et il méritait de figurer dans ton #1, ce qui n’aurait pas déclenché la "polémique" due à des termes inadaptés et trompeurs.

… Normalement tout marche très bien sauf que de temps en temps (sur des périodes plus ou moins longues) et de façon totalement aléatoire, l'alarme se déclenche. Elle se remet en veille automatiquement. Lors de ces déclenchements intempestifs, aucune ouverture n'a été actionnée. C'est très gênant car on ne sait plus distinguer l'intempestif d'une éventuelle réelle intrusion …

Voilà, très probablement, le vrai nœud du problème.

Beaucoup de possibilités peuvent se produire, et il faut assurer la fiabilité totale de ces lignes bien avant de s’en servir.

Il faut que tu mettes un testeur en auto maintien, sur chacune des lignes concernées, pour être sûr à 100% que ça ne coupe jamais. Les causes de coupure, si elles existent, peuvent provenir d’un choc sur l’aimant ou l’ILS parce que un choc a été fait sur le mur d’à côté. Ce peut être un des fils qui se coupe mais c’est peu probable ou ça a été mal fait.

Faire le test sur une durée telle qu’il soit sûr que le parasite se serait produit si c’était Arduino qui décidait.

Ce test rassurant assuré, il faut nous montrer le schéma des filtres intercalés entre ces lignes de détection et les entrées Arduino. Il faut savoir que tes détecteurs ce sont d’immenses antennes qui captent tout ce qui se passe à proximité en particulier les étincelles (redoutables) provoquées par les manipulations des interrupteurs et/ou les collecteurs de moteurs universels. Il faut filtrer tout ce qui n’est pas garanti LOW pendant une durée de 100ms.

Ce que je prnse c’est que c’est là que la détection parasite se crée.

[Pascal071]

Bonsoir à tous
En pratique, si la sortie passe à 1, c'est le résultat d'une commande dans le code.

Tu as bien les résistances de pull-up sur les entrées?
Tu peux filtrer l'entrée, en validant le "1" encore présent au bout de 150mS

mais je vois mieux un ILS dont l'aimant est mal positionné et le circuit s'ouvre tout seul de temps en temps.

Le filtrage quel qu'il soit ne fera pas disparaitre ce défaut, qui peut empirer dans le temps.

Longue expérience d'alarme intrusion... les alarmes aléatoires !!!

[Ambo73]

@gienas
Oui j'aurais pu faire la description globale dès le début mais comme je l'ai dit, je cherche pour l'instant une solution "facile" et rapide à mettre en oeuvre, si ça existe.
Je connais un peu les pbs de "sensibilité" des Arduino et pour en avoir déjà rencontré il y a quelques années, je sais que ça peut être long à résoudre. Or, tant que je n'ai pas trouvé, mon alarme n'est pas très opérationnelle. D'où mon soucis de trouver une solution rapide en attendant.
Bien sûr je n'abandonne pas l'idée de trouver l'origine exacte du pb.
Mettre un testeur en auto-maintien, si j'ai bien compris, ça me bloquerait l'usage normal de l'alarme, le temps de faire les tests.
Or il peut se passer plusieurs mois sans que le pb apparaisse. D'autres fois, il peut y avoir deux fausses alertes en 1 semaine... Donc compliqué d'attendre...
Le choc sur l'aimant, j'y ai pensé. Je connais bien le montage des ILS. Ceux que j'ai installés sont des modèles pros, surmoulés, avec des aimants très puissants. Il sont positionnés au plus près de l'ampoule. J'ai fait des tests assez sévères en tapant très très forts sur les huisseries et les cloisons à proximité. Je n'ai eu aucun déclenchement.
Les fils coupés, oui, j'y ai pensé aussi. Il y avait des épissures de loin en loin que j'ai soudées à l'étain pour être sûr du bon contact. Je doute que ça vienne de là, mais je vais vérifier (c'est assez compliqué vu la config de la maison)
La ligne reliant les ILS se comportant comme une antenne, oui c'est possible. Je ne sais pas ce que tu entends par filtre, en tout cas, je n'en ai pas. Par contre, les deux entrées de ligne ILS sont en mode PULLUP sur l'Arduino. Peut-être n'est-ce pas suffisant?
Selon toi, que faudrait-il comme filtre sur les entrées?

[Ambo73]

@Pascal071
Tu as bien les résistances de pull-up sur les entrées? - OUI

Tu peux filtrer l'entrée, en validant le "1" encore présent au bout de 150mS - OUI, c'est ce que j'ai fait

mais je vois mieux un ILS dont l'aimant est mal positionné et le circuit s'ouvre tout seul de temps en temps - comme je l'ai dit en réponse @gienas, je ne pense pas que ce soit ça mais je vais revérifier.

[gienas]

Je comprends beaucoup mieux mais tes "révélations" nouvelles sont édifiantes:

… Or il peut se passer plusieurs mois sans que le pb apparaisse. D'autres fois, il peut y avoir deux fausses alertes en 1 semaine... Donc compliqué d'attendre... les deux entrées de ligne ILS sont en mode PULLUP sur l'Arduino. Peut-être n'est-ce pas suffisant?
Selon toi, que faudrait-il comme filtre sur les entrées?

Là, le filtrage est inexistant et tes deux antennes géniales pour capter tout.

Quant à la pull up interne, bien trop élevée pour être utile. C’est à toi d’en choisir une.

Les fils blindés sont très contraignants et leur mise en œuvre sensible aux erreurs de montage. Mieux vaut oublier. Comme "l’antenne" est branchée en direct sur les entrées il faut compléter par un Zener.

Je ne suis pas équipé pour dessiner un schéma, mais il faut arriver par une résistance série de protection à un point A par exemple 100Ω.

Entre A et la masse une Zener 5,1V. Cathode en A.

Entre A et +5V, une résistance de pull up par exemple 4,7k.

Là, introduire un ou deux filtres RC, par exemple arriver à un point B par R de 10k.

Entre B et masse un condensateur de 0,47μF film plastique.

Entre B et C une résistance de 10k.

Entre C et masse un condensateur céramique de 1000pF.

C’est ce point C que, dans les deux cas tu relies aux entrées qui doivent être sans PULLUP et répondre à des niveaux logiques.

Comme ça ne coûte rien, tu peux ajouter une résistance de 100k à la masse entre les ponts C et le GND.

Les participants qui ont des calculettes en main pourront peut-être t’aider à peaufiner des filtres plus actifs mais si mon nez ne me trompe pas, ces deux "schémas" devraient détecter et commencer à filtrer un peu.

[Seb.26]

> Passer à des signaux en 12v ou en 24v avec des optocoupleurs coté Arduino.
> Filtrer dans le soft pour virer les éventuels parasites, tu n'es pas à 100ms près pour détecter un intru

[Ambo73]

Je comprends beaucoup mieux mais tes "révélations" nouvelles sont édifiantes:
Là, le filtrage est inexistant et tes deux antennes géniales pour capter tout.

Bon, au moins ça fait un axe de recherche...

Je ne suis pas équipé pour dessiner un schéma, mais il faut arriver par une résistance série de protection à un point A par exemple 100Ω.

A la lecture de ce que tu as écris, j'ai fait un schéma. Est-ce que c'est bien cela ?

[Ambo73]

> Passer à des signaux en 12v ou en 24v avec des optocoupleurs coté Arduino.

A quel endroit ces signaux?

> Filtrer dans le soft pour virer les éventuels parasites, tu n'es pas à 100ms près pour détecter un intru

Oui, je vais essayer de revoir mon soft dans ce sens.

[Seb.26]

A quel endroit ces signaux?

Dans tes fils qui font le tour de la maison (ceux qui passent dans les ILS) ... par contre comme ton uCPU n'aime pas le 12v (ni les parasites), tu mets des optocoupleur

Oui, je vais essayer de revoir mon soft dans ce sens.

yep

[jiherve]

bonsoir,
pourquoi une entrée analogique ?
JR

[Ambo73]

bonsoir,
pourquoi une entrée analogique ?
JR

bonsoir,
Bien vu.
J'ai écrit "Analogique" car c'est bien physiquement sur une entrée "analogique" que j'ai branché les ILS mais en fait, par programmation, je l'utilise en "digitale".

Par exemple, c'est possible avec les lignes suivantes:

const int ils=A4; //affectation à la broche analogique A4 (utilisée comme numérique)
pinMode (ils,INPUT_PULLUP);