Commande automatique de groupe électrogène - machine à états et autres questions

Merci ! Super en plus je suis de Grenoble, donc je télécharge du local ! Lol

KiCAD. C'est libre, ça tourne sous windows, linux et mac, et c'est impressionnant de facilité de prise en main et d'efficacité. Je n'avais jamais touché un soft de EDA avant ce projet, et juste avec le fichier d'aide fourni avec kicad je m'en suis sorti, c'est dire !

Tu le trouvera sur ce site web (version linux, native) :

http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite

Et pour ce qui est des version windows ou mac, une recherche google te trouvera rapidement un installeur :wink:

EDIT : bon bah grilled. au moins je donne le bon lien, c'est déjà ça :slight_smile:

Bon sinon pour savoir de quoi on parle, voila le schéma de mon système (fichier joint)
(il manque dessus les capas de découplage que j'ai rajouté un peu partout)

groupe.pdf (71.9 KB)

Y'a tout ?

j'ai du mal a comprendre ton circuit d'alim. Normal je ne sais pas exactement ce que tu cherches a faire.

mais je m'interroge quand même sur le relai de gauche.
Commandé par l'Arduino (s_alim) ? Comment l'Arduino peut-elle se mettre en route toute seule ?

Si je comprend bien Q5 et le relai amène l'alim sur le LM317 conduit si e_ext OU e_local OU s_alim est présent.

Tes reboot ne pourraient-ils pas être liés à des problèmes de ce coté là ?

oui, y'a tout sauf les capas que j'ai rajouté en live

alors l'alim, en fait, c'est simple : quand j'ai une demande de démarrage, que ce soit via l'entrée EXT (contact sec) ou LOCAL (contact sec entre +(borne 1) et local), alors via les diodes D6 ou D7 cela charge le condensateur C4, Ce qui crée un courant dans R8 qui rends positive la gate de Q5, le relais colle et alimente la carte. Ensuite l'arduino prends le relais et alimente direct la gate de Q5, provoquant l'auto-maintien de l'alim. C4 est là pour faire une temporisation le temps que l'arduino boote et alimente lui même Q5.
R9 sert à décharger C4 en l’absence de EXT ou LOCAL, pour que le système refoncionne à la prochaine demande.

Le but de ça, c'est que quand le système est en veille il se coupe totalement de la batterie pour ne pas la décharger inutilement, vu que cela peut être amené à rester en veille plusieurs semaines, voire mois.

J'ai ensuite un timout dans le programme, pour que si aucune nouvelle demande n'arrive, l'alim se coupe. En l'occurence après 2 minutes en fonctionnement normal, et 2h si il y a un défaut grave à afficher.

Et non, le reboot ne vient pas de là, enfin plus maintenant que j'ai rajouté un condo de 10000µ et une diode sur l'alim.

Maintenant, ce n'est plus l'arduino qui reboote mais juste le FTDI (ou en tout cas la liaison USB coupe) ce qui m'empèche de voir ce qui merde à ce moment précis.
Je pense que j'ai encore à ce moment des impulsions qui se baladent suite à l'amorçage de l'alternateur ou un truc comme ça, et que mes capas n'ont pas court-circuité, et qui me provoquent les soucis.

En plus comme le matériel est chez le client, pour le moment je ne peux plus faire de tests avant d'avoir réalisé une nouvelle carte et l'avoir montée sur un autre groupe...

Je reposte ici le résumé de la situation que je viens d faire dans l'autre topic :

Bon alors il faut expliquer un peu à quoi sert tout ça : le but est d'avoir un fonctionnement automatique de groupe électrogène diesel. L'arduino doit donc sur demande externe (contact sec) faire démarrer le moteur, puis surveiller qu'il n'y a pas de défaut (calage, non démarrage, perte de pression d'huile) et réagir en conséquence.

Au départ, j'avais un reboot de l'arduino dès l'activation de démarreur Il s'est avéré que c'était dû à une grosse chute de tension de la batterie, ça s'est donc résolu par l'ajout d'une grosse capa (10 000µ) et d'une diode sur l'alim de la carte.
Ensuite, j'ai eu des détections farfelues au niveau des entrées, j'ai donc rajouté des capas de découplage un peu partout pour essayer de virer les pulses qui, je suppose, se baladent inopportunément, venant soit du démarreur, soit de l'alternateur de charge. Cela a semblé résoudre le problème, mais pas dans tous les cas.

Et c'est précisément le cas qui foire qui devrait être le mode le plus utilisé du système : la commande de démarrage externe.
Avec la commande locale, ça fonctionne (presque) à chaque fois.
Avec la commande externe, ça merde à chaque fois : le moteur démarre, puis l'arduino le coupe et signale "défaut calage" comme si le moteur avait calé de lui même. Comme le programme fonctionne quand je teste la carte sur le bureau avec des poussoirs pour simuler les capteurs, je suppose que le soucis vient du matériel et non du soft, mais je ne peux en être sur, pour une raison très claire : quand la prise USB est raccordée sur la carte, d'une part, ça fonctionne (ce qui tendrait à suspecter un soucis sur l'alim, mais pourtant sa surveillance à l'oscillo ne laisse rien paraitre de suspect), et d'autre part : au moment ou sans l'USB, ça déconne, la liaison USB se réinitialise, et donc le temps de relancer la console sur le nouveau port, j'ai perdu le log qui me serait utile.

C'est ce décrochage de l'USB qui me fait dire "perturbations EM", mais sans doute suis-je à coté de la plaque.

J'ai du coup essayé d'utiliser le FTDI d'une autre nano grillée dont j'ai supprimé l'atmega comme convertisseur USB/TTL, que j'ai raccordé sur les pins TX, RX, et GND de la nano en place. Et bien rien, ça ne communique pas. http://arduino.cc/forum/index.php/topic,129661.0.html

Et voila le schéma avec cette fois les modifs faites en live en pleine nuit. Je me rends compte en le dessinant à tête reposée que les capas de découplage ne sont pas forcément aux endroits les plus critiques, il en manque sur les entrées par exemple. Mais bon, en pleine nuit après 2 nuits blanches...

groupe1.3.pdf (77.9 KB)

Ok je crois que je vois un peu mieux. Y'a un une partie que je comprend pas vraiment, celle de gauche : le calage est bien détecté par cette partie (e_alim) ?

non. le fonctionnement du moteur et donc le calage est détecté par e_run. Quand le moteur tourne, l'alternateur produit du 220V, et active l'optocoupleur.

e_alim, ça sert à détecter si l'interrupteur général est sur on ou pas, pour couper l'auto-maintien de l'alim.

Ok alors je viens de reprendre ton code, bon y'a quelques points qui restent obsures pour moi mais je pense pas que ça vienne de la. Il me semble que ton code et ton hardware ne sont pas armés pour faire face à la mise en régime de l'alternateur : quand tu le mets en marche, l'laternateur ne va pas fournir directement du 230V 50hz, or ton circuit lisse le signal donc tu ne vois pas la fréquence. Il faudrait dans l'idéal ne pas le filtrer et rentrer sur un port digital, et faire en somme un système de détection de passage à zero. Ainsi tu pourrais suivre la phase transitoire.

Ben je ne vois pas en quoi cela poserait problème ? A partir d'un certain régime, la tension produite est suffisante pour activer l'optocoupleur, à partir de ce régime il n'y a plus de risque d'arret du moteur si le démarreur ne tourne plus, donc je coupe le démarreur.
En fait l'alternateur produit quasiment immédiatement du 230V mais c'est la fréquence qui augmente avec le régime moteur.
Le fait est que ça fonctionne parfaitement en mode "manuel" (démarrage depuis l'entré e_local) alors que ça ne foire que dans le cas du démarrage depuis l'entrée e_ext.

La seule différence entre ces deux entrées dans le code, c'est que l'entrée locale active un flag puis n'est plus lue, alors que l'entrée ext est lue tout le temps et que si elle tombe cela coupe le moteur. Mais dans ce cas ça ne devrait pas faire remonter un défaut de "calage moteur", ça devrait juste le couper puis redémarrer.

Du coup je me suis dit il y a peut-être une perturbation de l'entrée e_run qui me fait détecter un calage, alors j'ai rajouté une tempo sur cette détection de calage, ce qui n'a rien changé.

Je crois que tu n'avais pas la dernière version du code, je la joins à ce post. Attention, elle est passablement en vrac, c'est fruit de modifications dans tous les sens en désespoir de cause à des heures inavouables...

Sur la suggestion de barbudor, suis en train de re-dessiner une nouvelle carte en utilisant directement un atmega328 en boitier DIL, comme ça déjà je vais éliminer les soucis d'alimentation liés aux deux régulateurs en cascade, et le soucis de liaison série qui se perds, vu que j'utilisera alors un convertisseur USB/TTL externe.
Je crois que tant que ça n'est pas fait, il sera difficile de comprendre ce qui se passe, vu que je n'ai de toutes façons plus le matériel sous la main pour faire des essais.

En tout cas, merci de t'interresser à mon problème :slight_smile:

groupe.ino (29.7 KB)

bricofoy:
Du coup je me suis dit il y a peut-être une perturbation de l'entrée e_run qui me fait détecter un calage, alors j'ai rajouté une tempo sur cette détection de calage, ce qui n'a rien changé.
...
Sur la suggestion de barbudor, suis en train de re-dessiner une nouvelle carte en utilisant directement un atmega328 en boitier DIL, comme ça déjà je vais éliminer les soucis d'alimentation liés aux deux régulateurs en cascade, et le soucis de liaison série qui se perds, vu que j'utilisera alors un convertisseur USB/TTL externe.
Je crois que tant que ça n'est pas fait, il sera difficile de comprendre ce qui se passe, vu que je n'ai de toutes façons plus le matériel sous la main pour faire des essais.

bonjour bricofoy
reprendre une conception que l'on pensait bien aboutie , même si c'est "intellectuellement" difficile :grin: est souvent une bonne façon de reposer calmement les problemes et leurs resolutions, la suggestion de Barbudor dés lors que tu dispose de cette possibilité (intellectuelle et "matos dispo" est une excellente chose.

pour simple reflexion :
ce que tu appelle info de "calage diesel" est une info secondaire dérivée mécaniquement mais pas primaire ?

tu ne "lis" pas la rotation de l'accouplement, mais tu déduis que la rotation existe (moteur en etat "non calé" )parce que l'alternateur delivre "qq chose" ?

Oui, exactement. Si le moteur tourne, l'alternateur débite. L'accouplement est direct, il n'y a pas de courroie ou de flector.

À partir du moment ou je ne détecte plus la tension, c'est que soit le moteur a calé, soit il tourne à trop bas régime car la panne sèche arrive, soit l'alternateur a cramé.

Dans les trois cas il convient de couper l'alimentation du moteur et de passer en erreur.

Sinon ma conception, c'était fait en une semaine je ne considère pas vraiment ça comme abouti :stuck_out_tongue:

bricofoy:
Oui, exactement. Si le moteur tourne, l'alternateur débite.

À partir du moment ou je ne détecte plus la tension, c'est que soit le moteur a calé, soit il tourne à trop bas régime car l'alimentation en carburant est défectueuse, soit l'alternateur a cramé.

soit il tourne à trop bas régime parce qu'il est entrain de démarrer ? ou l'opto-coupleur n'a pas encore commuté

j'aurais tendance de mettre une petite tempo sur un problème de ce genre...

cannard:

bricofoy:
Oui, exactement. Si le moteur tourne, l'alternateur débite.

À partir du moment ou je ne détecte plus la tension, c'est que soit le moteur a calé, soit il tourne à trop bas régime car l'alimentation en carburant est défectueuse, soit l'alternateur a cramé.

soit il tourne à trop bas régime parce qu'il est entrain de démarrer ? ou l'opto-coupleur n'a pas encore commuté

j'aurais tendance de mettre une petite tempo sur un problème de ce genre...

Non, car pour passer à l'état suivant et couper le démarreur, c'est que la détection de tension a déjà été faite.

Et oui il y a la tempo, de toutes manières. Je l'ai justement rajoutée quand j'ai constaté le soucis, sans succès.

Je n'ai pas regardé le code mais dans ta reprise de carte/câblage, pense a bien repenser au propre le câblage des alims comme je te le suggérais dans l'autre topic : un seul point de masse et pour chaque alim, câblage en étoile.
Autant que possible bien séparer les parties logiques (Arduino) et puissance qui peuvent générer de forts courants et donc des parasites : alims séparées, et surtout câbles d'alims séparés.

Ben alims séparées, à part de ne pas mettre le relais de commande du démarreur sur la carte, je ne vois pas ce que je peux faire de plus ?
Pour le point de masse, c'est le moins batterie, repéré -batt sur la carte, qui donne sur un plan de masse. Est-ce que cette disposition n'est pas bonne ?

J'ai peut être encore pas tout compris ton câblage
Pourrais tu faire un schéma du câblage externe à la carte ?

Voila le schéma.

Il manque la borne "C" (pour relier l'alternateur de charge batterie) sur le schéma de la carte, car je l'ai oubliée... en fait du coup je me suis branché sur la borne d'alim du relais de commande du décompresseur, vu que ce relais n'est pas monté sur la carte.

groupe_diesel.pdf (24.9 KB)

Dans les relais, y a t'il des courants forts ?

Si oui, l'ide qui me vient ca serait d'avoir 2 signaux +BATT :

  • Un destiné à l'alim de la carte et qui va donc sur le circuit d'alim de la carte : bobine RL5 et et commun 2 de RL5 (broche 21)
  • Un destiné au circuit des relais RL1..RL4 et qui rentrerait par un point de connecteur différent et qui n'alimentarait que les relais au niveau des fusibles.
    Chaque entrée batterie serait relié à la batterie par un câble différent pour éviter que les courants forts qui traversent ces relais n'impactent l'alim de la carte.

C'est la seule idée que j'ai.