Go Down

Topic: Commande automatique de groupe électrogène - machine à états et autres questions (Read 20 times) previous topic - next topic

barbudor

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à ?
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

bricofoy

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...
-tu savais que si tu passe le CD de windows à l'envers, tu entends une chanson satanique ?
-non, mais il y a pire : à l'endroit, ça l'instal

bricofoy

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

-tu savais que si tu passe le CD de windows à l'envers, tu entends une chanson satanique ?
-non, mais il y a pire : à l'endroit, ça l'instal

bricofoy

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...

-tu savais que si tu passe le CD de windows à l'envers, tu entends une chanson satanique ?
-non, mais il y a pire : à l'endroit, ça l'instal

B@tto

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) ?

Go Up